I would like to use http://maven.apache.org/plugins/maven-checkstyle-plugin/ as part of a project build with an intent to fail the build on a violation. However, since some of the projects already exist and it contains a lot of existing code, i would prefer to customize the checks in a way that it is only applies to modified files (svn/git) and not the whole project. Is there a way to achieve this?
You could set up a pre-commit hook on your repository to run checkstyle on file add/update,that way there is no need to fail the build, you can just block the commit. Refer to this use case: http://saturnnetwork.wordpress.com/2012/11/26/ultimate-architecture-enforcement-prevent-code-violations-at-code-commit-time/
Related
Is there any way to avoid triggering build on certain file commits which are not directly related to source code?
e.g. I don't want to trigger a automatic build when anyone make changes to README.md file or some reference document file.
I don't know that it's described in the plugin page or the Wiki, but at least according to the Advanced Features/Additional Behaviors, the git plugin can be configured to do what you're looking for in multiple ways.
eg: Polling ignores commits in certain paths lets you specify an Included region or Excluded region" The help (?) says:
Each exclusion uses java regular expression pattern matching, and must
be separated by a new line.
myapp/src/main/web/.*\.html
myapp/src/main/web/.*\.jpeg
myapp/src/main/web/.*\.gif
The example above illustrates that if only html/jpeg/gif files have been committed to the SCM a build will not occur.
You'd have to try them out. One less plugin - KISS!
After searching for quite a while I finally found a Jenkins plugin which can skip the build when there is keyword "[ci skip]" in the commit message.
This allows to skip a build on any file commit which has this keyword [ci skip].
only disadvantage is, it will skip the build even if somebody puts [ci skip] in a code file commit
Github: jenkins-ci-skip-plugin
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.
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.
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.
I'm facing the following issue. We have a Gated Check-In setup which means changes are not directly checked-in, but a Shelveset is created and a build is run against that shelve. Only if the build is successful, the changes are checked in.
Now we setup the build definition to only map as few things as needed to build, as we want to keep the time it needs to run at a very minimum. The problem now is that if you include in your change anything that is not mapped, the build will fail in the GetSources task, as it fails to unshelve and gives a folder mapping error.
For a better understnanding, imagine the following structure:
- MyRepository
-- Sources
--- MyCodeFiles
-- Documents
--- SomeDocuments
So in the BuildDefinition we only map the Sources directory, as this contains the files we need to build. You now have to make sure to never include any change outside of Sources, for example within Documents, otherwise the Build will immediately fail.
I already searched and found the description of the unshelve command: https://learn.microsoft.com/en-us/vsts/tfvc/unshelve-command?view=vsts
According to this description it should be possible to specifiy the itemSpec that
Identifies the file or folder revisions to unshelve into the current workspace
So it seemes like the unshelve command would actually support to "partially" unshelve. However I did not see any way on how to achieve that with a vNext build, as I could not find any infos on how the GetSources task is working.
Is there something I missed or is this with the current implementation simply not possible to achieve?
I'm afraid to say you haven't missed anything, it's just not possible in the current implementation. There is a more detailed discussion here:
https://github.com/Microsoft/vsts-agent/issues/1087
Having real problems creating artifacts in teamcity 6.5 (using TFS & MSBuild as the buildrunner if it makes any odds, which it probably does as any examples I find seem to use SVN...).
The Build works, so long as I enter no checkout rules.
If I understand it, I'll need to set up some artifacts, that themselves rely on checkout rules(?).
I have two builds that are identical other than the way they are kicked off.
One is initiated on check-in
One is initiated manually from within TC. This build is the Test Build
Assembly version numbers come from a single versioninfo.cs file that is a linked file in all projects in the solution. This method is detailed here : http://www.codeproject.com/Articles/328977/The-Right-Way-to-Version-Your-Assemblies and holds the version number thus:
[assembly: AssemblyFileVersion("9.1.0.0")]
Ultimately, I'm unable to copy the output of the test build to another location.
As it stands, the only output of a build is in the teamcity data directory, for example :
C:\TeamCity\buildAgent\work\ceaaf65dc87ff856\Project1\bin\Debug
C:\TeamCity\buildAgent\work\ceaaf65dc87ff856\Project2\bin\Debug
etc
I'd like to copy the output files (exes and DLLs) to an output folder which has the build number of the build on it
For arguments sake, lets say for the version number above, this would be to
c:\BuildServer_Output\SolutionName\9.1.0.0
Currently I have not been able to create artifact paths that actually do anything - i.e. to copy anything anywhere.
For instance I have acoupe of artifact paths, but nothing ever gets put into C:\BuildServer_TestBuilds -
+:Accounts\bin\debug* => C:\BuildServer_TestBuilds
+:BackOffice\bin\debug* => C:\BuildServer_TestBuilds
Am I getting no artifacts (and my artifact paths therefore ignored) because I have no checkout rules?
Any help would be appreciated.
I am pretty sure artifacts and checkout rules are completely independent. Artifacts just deal with what has been built. Checkout rules tell teamcity how to react to and checkout changes in the VCS.
It looks like your artifact paths are beginning with absolute paths. I have always found it easier to use relative paths with wildcards. That way I don't need to worry about where teamcity put the build. We use the following to get all dlls and exes to one folder
**\bin\Debug\*.*=>deploymentdir
Our build configuration page has an artifacts link and when we open it it will have things like
deploymentdir\common\bin\debug\common.dll
deploymentdir\common\bin\debug\common.pdb
deploymentdir\runner\bin\debug\runner.exe
In one of our other builds we use an msbuild script to flatten our output before putting it through the artifact process.
We do use checkout rules but we have not had to change our artifact paths to accommodate them.
Our C# solution has a couple of folders that are populated via post-build events (i.e. they are initially empty).
The solution builds fine locally, however when using the TFS build agent, the folders don't show up in the published websites folder.
Any suggestions on how to force TFS to copy the folders over?
This is addressed here: publish empty directories to a web application in VS2010 web project
TFS does not execute the AfterBuild target of your proj file. I believe it will execute the AfterCompile target but this still might not do what you want.
I have used the approach of including dummy files which is simple enough even though its lame.
I've tried the approach of including a powershell script to do some post-publish tasks which works.
More recently I have adopted a convention of including a supplemental MSBuild file that ends in ".package.proj" and added an additional MSBuild execution activity to my Team Build Template that looks for it after the files are dropped to the drop location and then executes it. This provides a simple hook into the Team Build workflow without getting you deep into changing the workflow for a particular build. It's just a single additional activity wrapped in a conditional that looks for the file. If found, execute it.
You could also make a custom build template and use the Workflow activities to perform various cleanup tasks, but it's probably overkill and will increase maintenance on the build templates. Better to keep the customization simple if you can and have it function in a way that doesn't require "opt-out" configuration on builds that don't require the customization. Existing vanilla builds should continue to work as expected after the customization to the template.