Support Jenkins CI

[serra]

See the comment thread in #288.

I'll see if I can get something to work in my environment. I'll open a PR then.

• Implement Jenkins.cs (compare: TeamCity.js), with tests. Check for existence of JENKINS_URL to confirm that we're running from within the context of a job in Jenkins. See wiki/Command-Line-Tool#directly-on-build-server
• choose parameter name to set see variables in wiki
• find out how to set parameter values from within a job

Current implementations write a message to the build output. This message should then be picked up by the build server. In Team City, this concept is called Service Messages.

AFAIK a similar concept is not available in Jenkins CI, which would mean the Jenkins implementation would be conceptually different. Before picking this up, I'll wait for some answers to my post to the Jenkins newsgroup.

Todo

There does not appear to be a similar concept to service message in Jenkins. There are however several Jenkins plugins that add similar functionality to Jenkins, e.g. environment script plugin mentioned in the comments thread. We require use of this (or similar) plugin:

• select a plugin - Going for EnvInject
  • Evaluate EnvironmentScript. Cannot be used; can only be run from .sh ish shells, which we cannot assume to be present on our .net build slaves IMO
  • Evaluate EnvInject, e.g. from sample here. This one would work.
• implement /buildserver with tests for Jenkins CI
• set up jenkins job that runs agains my fork, building the propertiesfile_output branch. Build steps:
  • 1. create gitversion binary
  • 2. run this binary to generate environment variables pipe to gitversion.properties file
  • 3. in the next step verify (by simply printing) the values of the environment variables set
• Update documentation
• Open PR

[JakeGinnivan]

Based on a quick search. Maybe something like this would work: https://wiki.jenkins-ci.org/display/JENKINS/Environment+Script+Plugin

From http://stackoverflow.com/questions/12924232/set-jenkins-prompt-variables-using-a-scripts-output

[serra]

I have not received any replies to my question on the Jenkins group. From my research thus far I concluded that this can only be achieved using an additional Jenkins plugin (e.g. the one you suggested).

Do you guys mind tying users to a specific Jenkins plugin? (I don't really mind - in a sense it appears to be the Jenkins way of things)

[serra]

@JakeGinnivan: Do you guys mind tying users to a specific Jenkins plugin? (I don't really mind - in a sense it appears to be the Jenkins way of things)

[JakeGinnivan]

Depending on how different the plugins are, we could pick the top two, pick a default then make it a config option to switch between.

Completely up to you though. I don't mind tying to a single plugin.

[serra]

Note to self: check out to a specific branch, because gitversion requires a current branch and jenkins default behavior is building in detached head mode.

[pvandervelde]

@serra Has there been progress on this? Any chance of getting this into the next release?

[serra]

@pvandervelde no progress thusfar; since Jenkins does not have a concept similar to Service Messages, this would mean a fundamentally different implementations than the current TeamCity and similar implementations.

I guess I could cook up a (IMO) hackish implementation similar to the current AppVeyor.cs implementation (which seems to be making http calls in the GenerateSetVersionMessage and GenerateSetParameterMessage methods). But that does not sit right with me and I don't consider it an improvement over my current solutions:

1. simply use gitversion in psake build script (works on all windows build machines)
2. json to java properties file and then us EnvInject (which I did use, but not anymore)

Best integration with Jenkins would be to be able to do something like:

gitversion /output props > envvars.properties

Which could then be injected into Jenkins using the EnvInject plugin.

[pvandervelde]

That's roughly what I'm doing currently. The main issue is that GitVersion behaves differently if it thinks it's on a build server than when it's on a dev machine. It normalizes branches on the build machine and not on the dev machine (as far as I know). The problem I have with Jenkins is that Jenkins doesn't pull all the history, just the commit and it doesn't even put that commit on a proper branch (uses a detached head instead) which stuffs up GitVersion.

[JakeGinnivan]

#507 could help with this. It would also be good to get the current approaches documented. Would either of you be up for submitting a PR with some info on setting up jenkins at https://github.com/GitTools/GitVersion/blob/master/docs/more-info/build-server-setup/jenkins.md ?

[pvandervelde]

I can probably have a look at the configuration we use at work when I'm back there next week. Mind you I haven't found a good setup to get the branch names to work out yet.

[serra]

@JakeGinnivan would you accept a PR for /output props that instead of

C:\dev\Gitversion\src>gitversion /output json
{
  "Major":3,
  "Minor":0,
  "Patch":1,
  "PreReleaseTag":"",
  // ...
  "SemVer":"3.0.1",
  // ...

writes out

C:\dev\Gitversion\src>gitversion /output props
gitversion.Major=3
gitversion.Minor=0
gitversion.Patch=1
gitversion.PreReleaseTag=
# ...
gitversion.SemVer=3.0.1
# ...

That output would be trivial to use with the EnvInject plugin.

[serra]

Or do you prefer a Jenkins Jenkins:BuildServerBase implementation that produces mentioned output?

I prefer the /output props because of it's clarity; the buildserver implies some sort of build server integration, which in fact is not provided, because users have to automate the use of the output themselves.