This may be unrelated to programming but does helps in it.
We use Jenkins with perforce plugin. Jenkins build is triggered by change. We can also see which files got affect in the specific changelist.
But I was curious if there is any option by which we can also see the diff between the files.
Say a changelist says : hello.cpp 2#2
So is there any way I can see the diff between 1st and 2nd version of hello.cpp file. As if there is such feature it will allow us to review the code and increase the usability.
Set up an scm browser server such as fisheye or p4web, and set up the perforce plugin to talk to it. That will provide links to the diffs for each file in the changelog.
Related
I have a preflight job using perforce in which I retrieve a branch, unshelve (apply) a given changelist on it and then build to validate that the change in question has not broken the build. Very similar to what you would do for a GitHub Pull Request type of CI.
I use the official checkout() pipeline call to get the branch as it simplify dealing with the perforce creds, and that causes the jenkins build to include the changelog of that branch in the build. Yet, those are of no interest to me, as my interest is on the changelist I am unshelving on top of that branch.
Can I, from the pipeline script clear and fill the currentBuild.changeSet? If so, would someone have an example and which fields I can set under currentBuild.changeSet.items?
Or doing is only possible by going through the plugin road in the same way the p4/git plugins are doing this?
My advice, don't play with the currentBuild.changeSet. It also contains the changeset of the shared libraries you are using. I personally don't rely on that anymore.
However, here is an article on how to update the changeSet
https://support.cloudbees.com/hc/en-us/articles/217630098-How-to-access-Changelogs-in-a-Pipeline-Job-
Here is an exemple on how to implement that in a pipeline
https://issues.jenkins-ci.org/browse/JENKINS-58441
Finally, in an ideal world, don't share your jenkins with management or non developers/testers, share only a dashboard that is connected to a database that you filled with the relevant information you need. I use influxdb+grafana to do that with the influxdb 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 have a strange use case here I know, but basically I have a CI / CD solution that starts be a developer creating a zip file of a set of resources. This zip is then sucked in to SVN via the tools internal programs.
Currently the solution works, using the FSTRigger to poll for an updated zip. When it see it, then the process kicks off and we're happy.
going forward I'd like the builds to be triggered by a Jira job reaching a certain status and have been looking at the Jira trigger plugin. It looks like it will help satisfy me with regards the triggering of the build and passing data from Jira to Jenkins to use for delivery notes etc. However it would still depend on the zip file being in a certain location to be picked up.
I'm wondering if it's possible to attach the zip to the Jira task and then as part of the task status hitting 'build' kick off the Jenkins job and copy the zip so it can be picked up by by the Jenkins build task.
for reasons to complex to mention, checking the zip into svn first won't really work.
When your Jenkins build is triggered via jira-trigger-plugin, you would be able to access JIRA_ISSUE_KEY environment variable that contains the JIRA issue which status has changed.
With the JIRA issue key, you can hit Get Issue JIRA REST API to retrieve the issue details. The issue details would contain the attachment information, which would then be able to be used for downloading the zip in Jenkins.
I am using Git as SCM, but I would prefer not to tag the code, so I'd rather use Jenkins to find out if one file has changed from one build to another , and read the content.
of course, I would want to do this from the current build.
You should try set up an scm browser server such as fisheye or p4web, and set up the perforce plugin to talk to it. That will provide links to the diffs for each file in the changelog.
Hope it help
I have a plugin in Jenkins for Checkmarx which scans the source code for static code analysis. Is there to make that plugin be compulsory for every job in jenkins?
For that matter any plugin.
The answer, that you probably don't want to hear, is: No.
The only way you can enforce something to happen at all times, is by writing your own plugin for your own "Project type" (instead of Maven or Free-style), and then enforce that everyone uses your project type.
Found a implicit way to do it.
Using jenkins rest api(batch,python,ruby) - run through all job
config.xml.
Download the jobConfig.xml
Update the xml with the plugin(checkmarx in this case) config
Upload(POST) it back to jenkins server.
Run this on a schedule and it shall force everyone to use it.
As I said its an implicit way of doing it.
Checkmarx plugin provides a build step, so it will run every time the job runs. No need to force, if I understand the question correctly. Just make sure the "Skip scan if triggered by SCM Changes" flag is unchecked, which is the default. See more info about the plugin here: https://checkmarx.atlassian.net/wiki/display/KC/Configuring+a+Scan+Action
Downloading the config.xml for the job and posting it back is a bad idea for several reasons. First checkmarx does not require the code to be compiled so you are wasting precious cycles on a build slave. Second Jenkins jobs can do more than compile and they could deploy to production accidentally. Just don't do it. The best way to do what you want to do is to download the config.xml file and then extract the repository url. You can use the Checkmarx rest api to perform a scan. You can probably name the program in checkmarx in some way to relate it back to the jenkins job.