0

I am not using ANT at all so the proposed duplicate does answer this question about Jenkins.

I am working on a build script that will increment the version number of the program. To do this the version file will be checked out, next version number computed and written back, and then checked in.

It occurs to me that this will trigger yet another build in an endless cycle. When we used TFS builds we could put a string in the check in comment like ***NOCI*** or something and that check in would be ignored and not trigger a new build.

Is there any such option for Jenkins or a technique I can apply myself to solve this?

I am using the TFS plugin to access my SCM.

Matthew MacFarland
  • 2,413
  • 3
  • 26
  • 34
  • Possible duplicate of [Use ANT to update build number and inject into source code](https://stackoverflow.com/questions/3439876/use-ant-to-update-build-number-and-inject-into-source-code) – AussieJoe Oct 19 '18 at 22:16
  • I am not using ANT at all so the proposed duplicate does answer this question about Jenkins. – Matthew MacFarland Oct 19 '18 at 22:22
  • Does, or does not, answer it? – takendarkk Oct 19 '18 at 22:24
  • can you post an example of your build script? I have never seen Jenkins working without Ant...extra checkins for this, seems redundant...I think you need to look at this: https://stackoverflow.com/questions/22678616/how-to-increase-jenkins-build-number-automatically and I highly suggest you make use of Ant...its the glue for Jenkins. – AussieJoe Oct 19 '18 at 22:52
  • @AussieJoe I am using a PowerShell script in the particular case that prompted my question. I have over a hundred Jenkins jobs doing builds without ANT so that's never been an issue at all. Really my question is about configuring Jenkins to ignore certain check ins when polling the SCM. This is before the build script is ever called so it's not related to any particular build script technology. – Matthew MacFarland Oct 20 '18 at 12:48
  • @csmckelvey Does not. – Matthew MacFarland Oct 20 '18 at 12:49
  • @MatthewMacFarland what SCM are you using? Can you update that in your question? – AussieJoe Oct 22 '18 at 15:05
  • Have you considered using a Global Assembly Info "link" throughout your project, instead of stamping a file? Do you version your .NET assemblies? You may want to check it out: https://stackoverflow.com/questions/2732155/c-sharp-project-global-assemblyinfo/2732273#2732273 In your build step, you simply stamp the version of the global assembly, build it, and it will then reference the new version throughout your solution projects. – AussieJoe Oct 30 '18 at 16:34

2 Answers2

1

The Subversion SCM plugin allows you to specify paths that will be excluded when polling for new versions. Git SCM also can be configured to exclude some regions.

By excludng the file that contains the version number you will be able to avoid the vicious circle that you observed.

Alex O
  • 7,746
  • 2
  • 25
  • 38
  • I saw some options like that for other SCM plugins. I am using the TFS plugin which has no such options. It could be that the only way is to code up the behavior in the script itself or switch to a different SCM. This does not appear to be a core Jenkins feature. – Matthew MacFarland Oct 23 '18 at 19:03
0

Since you cannot cloak or .tfignore your versioning file...you can use the NOCIOption property, and pass in the flag for it, in your comments.

You would setup the NOCIOption property of the SyncWorkspace workflow activity in TFS, and during your version change, pass "****NO_CI***" flag in the comments of the checkin. This is kind of hackish and could be avoided if you used GlobalAssemblyInfo.cs versioning, linked throughout your project instead.

I suggest not using your "versioning" file, as it's fundamentally wrong for the reason of cyclic checkins. I would suggest using the GlobalAssemblyInfo.cs linked throughout your .NET solution and stamping that prior to calling MSBuild. It works like a champ for setting and linking versioning throughout your .NET projects in your solution. You implement Global Assembly Info in your solution as described in this answer here.

You can understand more of it here, at "What are the best practices for using assembly attributes". You could simply stamp this file (via Powershell or whatever) and call MSBuild and your version will be present in all .DLLs.

AussieJoe
  • 1,285
  • 1
  • 14
  • 29
  • I read about the NOCIOption. We used to use that when we ran the builds on the TFS server. I could not see that it has any affect in Jenkins. We are already using the global assembly info file like the one described in the article. That works very well but it's still in the solution folder so it's check in still triggers a build. – Matthew MacFarland Nov 06 '18 at 21:43
  • I ended up using a versioning algorithm that sets the last 2 segments of the build number based on dates and times. We just change the first 2 manually prior to check in when needed. So I check in 1.1.* for example and then replace the * before calling MSBuild. – Matthew MacFarland Nov 06 '18 at 21:44