A Little Wondering

I installed Visual Studio 2015 the other night and was just poking around and stumbled upon the Cordova Project Template that is provided. This not necessarily that new, but is new to me as I spend most of my time these days working on a Mac doing iOS, Docker (for server-side stuff) and other projects. Though, I miss and still enjoy the benefits of Visual Studio for some projects.

While looking over the project template, I was surprised to see a familiar folder structure typings/cordova/* in the project.

Why is this folder structure familiar?

Because I created it almost 2 years ago when I threw together a PowerShell script that chucks DefinitelyTyped TypeScript definitions up onto NuGet.

Another example of the folder structure, while I can't say for certain, but I can only guess that when the winjs started converting over to TypeScript that they chose to put their type definitions into the same structure. I won't claim to have inspired it, but would be cool to say I did.

It was a bit surprising and humbling to discover Microsoft had in one of their default templates a reference to some TypeScript type definitions that (while I didn't have anything to do with the creation of the definitions, nor DefinitelyTyped) I did created the simple little utility that runs continuously up on TeamCity.CodeBetter.com and tirelessly updates NuGet packages as they change over on DefinitelyTyped.

This reminded me, that I hadn't checked up on the NuGet user account for DefinitelyTyped in quite a while so I decided to head over to the NuGet.org, take a glance at the account and check out how many downloads there had been?

** HOLY Typings **, there've been over 2 million DT type definitions?

This little ditty was neat to find. I haven't done a ton with TypeScript in a while, but it's quite amazing to see the traction it is starting to gain.

This means that the TeamCity over at CodeBetter has pretty much been cranking out new and updated DefinitelyTyped TypeScript definitions for almost the last two years, but it's time to re-visit...

Thanks TeamCity @ CodeBetter

Before all of the new, cool, and hip online continuous integration systems came to be, one of the only free options for open source was an instance of JetBrains TeamCity over at CodeBetter and I'd like to throw out a big thank you for those at CodeBetter who put the time and effort into hosting this service for many of the .Net OSS projects out there.

Hello AppVeyor

I recently ported this job to an AppVeyor build for the DT project and after a quick round of using their wonderful support to work through a hurdle, I completed a new build at AppVeyor that replicated the one originally hosted on the TeamCity server.

So a HUGE thanks to AppVeyor for creating such great product, and offering free builds to the OSS community.

I'll keep an eye on the new build for a while (before I forget about it) and hopefully it'll run for another long time to come.

Happy TypeScripting!

We recently migrated an older Jenkins C.I. server over to a newer one, and struggled to get XCTool or xcodebuild to run unit tests where the simulator was needed.

There are quite a number of blog posts out there that describe how to setup a C.I. Jenkins server on a Mac, but many of them don't include the last bit (that worked for me), so I hope this helps you...

Why Can't I run the Xcode Simulator on a Jenkins server?

Some Error Messages I Encountered Along the Way:

Tried to install the test host app 'com.myapp.test' but failed.

Preparing test environment failed.

-[TEST_BUNDLE FAILED_TO_START]

There was a problem starting the test bundle: Simulator 'iPhone 6' was not prepared: Failed for unknown reason.

Test did not run: Simulator 'iPhone 6' was not prepared: Failed for unknown reason.

2015-01-21 12:02:19.296 xcodebuild[35135:875297]  iPhoneSimulator: Timed out waiting 120 seconds for simulator to boot, current state is 1.

Testing failed:
Test target MyProjectTests encountered an error (Timed out waiting 120 seconds for simulator to boot, current state is 1. If you believe this error represents a bug, please attach the log file at /var/folders/yf/49df70js2xn524f9c3835zx0000087/T/com.apple.dt.XCTest-status/Session-2015-01-21_12:00:19-sXA35e.log)
** TEST FAILED **

Need to run a GUI user.

The Simulator needs to run in the context of an actual user where it can get a window handle and render it's U.I...

Below is a great resource to get you most of the way there.

iOS CI with Jenkins

Once you've followed the instructions in the above post and you still can't get the Jenkins CI server to run your simulator tests, then check this last item which got it working for me.

Open up your Jenkins plist file in the LaunchAgents folder. (If you don't have one in LaunchAgents, then go back to the linked blog post and follow that first).

The key for me to get it working was to remove the CreateSession key from the plist.

-       <key>SessionCreate</key>
-       <true />

Once I removed this key, restarted the server, everything started building/working correctly.

In summary:

1. Auto-login with a jenkins user
2. Get your plist moved over to the LaunchAgents folder (see post linked above)
3. Remove the SessionCreate key

We recently setup a new Jenkins build server for some iOS applications and I wanted to find a quick way to copy a couple Jobs from the old server to the new one.

Below are a few small options I found while working on the task.

Option 1: Copy jobs directory

One option (and seems to be the recommended one) is to just copy the jobs directory from the old server to the new one.

From the documentation Moving/copying/renaming jobs:

You can:

1. Move a job from one installation of Jenkins to another by simply copying the corresponding job directory.
2. Make a copy of an existing job by making a clone of a job directory by a different name.
3. Rename an existing job by renaming a directory. Note that the if you change a job name you will need to change any other job that tries to call the renamed job.

Those operations can be done even when Jenkins is running. For changes like these to take effect, you have to click "reload config" to force Jenkins to reload configuration from the disk.

For me, I skipped this option because I was having a hard time finding where the jobs directory was on the old server. (Or just too lazy to find it, and I only had a couple jobs to copy over)

Option 2: Try one of the plugins out there

There are some Jenkins plugins out there that provide some job export options. Here are a couple...

• Job Exporter Plugin Thanks to a comment below for pointing out this doesn't actually export jobs - but environment variables when the task runs...
• Job Importer Plugin

Option 3: Use Jenkins CLI

This is what I used, which worked nicely for only the few jobs we had. If you have a large number of Jenkins jobs, you may consider the first aproach above.

1. First download the Jenkins CLI jar.

• You can do this from your jenkin's CLI page within your installed Jenkins instance.

2. Next we can use the following command (pointing to the old server) to list the jobs.

java -jar jenkins-cli.jar -s http://<YourBuildServer>:<YourBuildServerPort>/ list-jobs

3. Using one job from the list above, let's copy the xml of a job to the clipboard. (I'm using a Mac which is were pbcopy & pbpaste come from below)

java -jar jenkins-cli.jar -s http://<YourBuildServer>:<YourBuildServerPort>/ get-job "NAME_OF_JOB" | pbcopy

This uses the cli get-job "NAME_OF_JOB" command to print the job's xml to stdout, which we pipe to pbcopy on the Mac to load the configuration into the clipboard. You could of course pipe the output to a file like ... > job.xml

4. If the above command placed a job's XML into the clipboard, you can use the below command to add it to the new server.

pbpaste | java -jar jenkins-cli.jar -s http://<YourBuildServer>:<YourBuildServerPort> create-job "NAME_OF_JOB"

This uses pbpaste to take what is in the clipboard, send it to stdin and pipe it to the Jenkins cli's create-job "NAME_OF_JOB" command.

Hope this helps...