Archive for September, 2011|Monthly archive page
There are some articles out there about setting up Jenkins slaves on Windows. This is one more, with a bunch of information about configuring Git. The documentation for setting up Git to work well with Jenkins is surprisingly sparse and the process is extremely frustrating (in my experience). Hopefully this will help!
* This assumes some master Jenkins service is setup with the Git plugin and has network access to the Windows box that is becoming a slave.
Setup Jenkins Slave
- Goto Jenkins master.
- Select ‘Manage Jenkins’ > ‘Manage Nodes’.
- Select ‘New Node’.
- Give it a name that identifies the computer, select ‘Dumb Slave’, and ‘Ok’. Some example settings:
- Name: win7-thomas
- # of executors: 4 (one executor per cpu is not a bad ratio)
- Remote FS Root: c:\Jenkins\Slaves
- Labels: windows blackberry (this box is good for building the blackberry projects and is a windows box)
- Usage: Utilize this slave as much as possible
- Launch method: Launch slave agents via Java Web Start
- Availability: Keep this slave on-line as much as possible
- After saving the new node, open it from the ‘nodes’ screen, and select ‘Launch’.
- Save the slave-agent.jnlp in a decent folder (like c:\Jenkins).
- Open the slave-agent.jnlp. Double clicking worked for me, but you might need to use something like:
- javaws http://jenkins-hostname/computer/win7-thomas/slave-agent.jnlp
- Or, one of the other suggestions Jenkins shows.
- This should popup a window that says ‘Connected’. Goto ‘File’ > ‘Install as Windows Service’.
- Once you have completed this install, you should see ‘Jenkins Slave’ among the running services.
- It might make sense to change the user that runs the service to something other than the SYSTEM user. Once changed, you will need to Stop and Restart the service.
- Reboot. Make sure that ‘Jenkins Slave’ is started automatically at startup.
- When you create a new project, make sure that its labels indicate this slave’s name or labels.
- To run commands as the SYSTEM user, you can use psexec.exe from SysInternals.
- From an Administrator cmd.exe prompt, psexec -i -s cmd.exe will open a new shell as the SYSTEM user.
General Advice when Setting Up Git
- Define a HOME env var equal to %USERPROFILE%.
- Create passphrase-less rsa keys and put them in %HOME%/.ssh. These keys should be setup on whatever server hosts the Git repos. In GitHub, for example, you would need to add the keys to your account.
- Do an initial ssh [email protected] to add GitHub to the known_hosts.
- Get rid of any GIT_SSH env vars if using the default ssh client for auth (as opposed to plink.exe, etc). GIT_SSH=c:\…\plink.exe may exist if you have previously used putty/pageant/TortoiseGit/etc to access Git repos.
- ssh [email protected] (or wherever your repo is) is very useful for debugging. One to three -v flags (i.e. ssh -vv [email protected]) may be added to help debug the connection process.
- Set the %HOME%/.ssh/config to specify which authentication to use:
Host github.com User git Hostname github.com PreferredAuthentications publickey
- If you see the following error message and your files do have the correct perms (0600), then you are suffering from a bug in the msysgit ssh executable. Unix permissions (0644) don’t map to NTFS ACLs. Msys just fakes the behavior of chmod, but it can’t fake a chmod to a restrictive enough permissions set. Steps to fix are below.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for '/path/to/key' are too open. It is recommended that your private key files are NOT accessible by others. This private key will be ignored. bad permissions: ignore key: /path/to/key
- Assuming cygwin is installed at c:\cygwin and msysgit is installed at c:\progra~1\Git, this will replace the ssh executable in msysgit with the one from cygwin, which recognizes file perms:
@rem From an Administrator cmd.exe @rem This works for 32bit Windows. Adjust accordingly for 64bit. c: ren "C:\Program Files\Git\bin\ssh.exe" "C:\Program Files\Git\bin\ssh.bak.exe" copy "C:\cygwin\bin\ssh.exe" "C:\Program Files\Git\bin\ssh.exe" copy "C:\cygwin\bin\cyg*.dll" "C:\Program Files\Git\bin\"
I have been using python at work for the last year, and had fooled around with it for five years prior to that. I am by no means an encyclopedia of python knowledge, but here are a few pointers that were not obvious to me when I was getting started.
1. Use contextlib.closing to avoid leaking file pointers.
3. Use pickle to write/read data structures to/from file for easy persistent storage.
4. Use subprocess to make shell calls. This is especially useful when writing utility scripts that need to make bash calls (for example)!
5. Simplify unittesting with mock objects. Be careful about using the built in methods on Mock objects, though. A spelling error will get invoked as a ‘mock’ call to the object instead of throwing an AttributeError.
There are tons of other useful modules and third party libraries out there. Feel free to suggest them in the comments!
I found a cheap mid-week flight to New York City a few weeks ago on Kayak. I have used Kayak fairly often in the last year or two, and I have always been impressed! I am especially excited for the new Hacker Fares feature.
Enough about Kayak, though, I will be in the Big Apple! I already have a ticket to see Follies with Bernadette Peters on my first day. I also have a list of potential drag shows and gay bars to visit. Needless to say, this will be a vacation more of the adventure/extravaganza flavor (rather than relaxing).
Suggestions are welcome and encouraged.