Jenkins has information about commits included in a particular build. I know this because Jenkins displays this (see the screenshot below).
How can I pull the information about commits included in the build during the CI execution?
This information is required to check what folders have files modified and, as a result, to determine what actions Jenkins should execute.
Thanks!
P.S. To achieve this in CI jobs for PRs, I use git command:
git rev-parse github/master
It returns the last commit made in master before current branch was branched off (to make it work I add 'github' remote). Obviously, it can't work in the 'master' branch itself. So I'm thinking, maybe Jenkins has some built-in information that I can use? Or some Jenkins plugins can help?
Apparently, there is a bunch of links, though I could not find any until I figured the keyword to google for it.
1st of all, there is a DevOps version of StackOverflow:
https://devops.stackexchange.com/
It might have more people active that can help with Jenkins related questions
2nd, the idea is to use jenkins variable currentBuild and further iterated through:
currentBuild.previousBuild
build.changeSets
items in the build
commit hashes are in the item.commitId
Links that helped me to figure out the solution:
What commits are pulled by Jenkins in the build?
https://devops.stackexchange.com/questions/2310/get-all-change-logs-of-since-last-successful-build-in-jenkins-pipeline?newreg=52d68c7ced584340988071cc72440ca1
https://blog.csdn.net/liurizhou/article/details/88236397
NotSerializableException thrown when accessing currentBuild.changeSets in Jenkins pipeline
https://gitter.im/jenkinsci/jenkins - public chat with jenkins community, not super active, but still helpful.
IMPORTANT NOTES:
Because of how Groovy works in Jenkins you need to put this logic into a separate function and add "#NonCPS" attribute to it
All variables inside need to be prefixed by 'def' (even though my prettier told me this is not required), without this you will have "java.io.NotSerializableException: hudson.plugins.git.GitChangeSetList" errors.
Hope this will help someone as well!
Related
Jenkins provides lengthy documentation regarding how to specify which branches it will build from. https://plugins.jenkins.io/git/
None of that though answers this specific question, or if it does, I cannot seem to achieve this.
How to specify that Jenkins will use whichever branch is normally checked out when cloning, such as the default branch specified in Github
Does this even make sense or is this even possible?
EDIT: specifically what should go in the red circle to checkout the default branch in Github
Jenkins respects the default branch over HEAD. Also, it depends how you configure you Jenkins job if it's a mulit-branch pipeline then you don't need to specify which branch it should build, by default it will scan you GitHub repo and build the changes made on branch and it will trigger the build.
If it's pipeline job then you can specify which branch it should built by editing the job configuration on Jenkins job and specifying the particular branch name in the section Branches to build
I hope this is what you are looking for.
I have a Jenkins Multi branch job that checks out and builds code from GitLab.
Until recently it was working without issue but now some (but not all) branches from the good master fail to build.
Master always builds without issue.
When I branch master either from the repo in GitLab or via a git checkout -b locally and push back to Gitlab and then allow the multibranch job to pick up the new branch it fails to build it.
I get the message from the pipeline plugin SCMBinder class: "Could not determine exact tip revision of [branch]; falling back to nondeterministic checkout".
When I do a git status in the workspace on either master or a slave the Head is detached.
When I git clone the code locally and checkout the branch everything is fine and the head is properly attached.
Additionally, when I create a simple pipeline job in Jenkins with the problem branch it builds ok and inspection of the workspace shows the head attached.
I have upgraded Jenkins and the plugins but this has not helped.
The confusing thing is that I have some other branches I created from the same master that builds perfectly fine in the same multibranch pipeline job.
Also if I branch a good branch then I get the same issue in the multibranch pipeline.
Can anyone suggest what is going wrong?
I also faced similar issue for multi branch Jenkins project.
When I clicked the option "Scan Multi branch pipeline now" in the left side menu, the problem got resolved.
Hope it might help some one.
I found the answer to this, so answering it here to help others and stop anyone from wasting their time on it.
Essentially this was caused by linux/windows interoperability issues/differences around the use of case in the branch naming which translates into a folder naming issue because windows does not care about case but GIT does.
Simply put, the first branches I previously created for the problem repo I was using a prefix lets call it "Prefix" with an uppercase "P".
These branches were pulled into a multi-branch pipe and built ok.
Then, I created a branch with the prefix "prefix" with a lower-case "p". This branch failed to build in the multi-branch pipeline.
As we know Windows does not care about case and so does not create a new folder structure in .git for "prefix" as it thinks it has one already called “Prefix”.
The appropriate HEAD and commit information is put under the original file structure under “Prefix”.
GIT however when it tries to checkout the code cannot find the head/commit information for the branch starting "prefix" as it is looking in .git for the commit/head details under "prefix" and not "Prefix" which does not exist hence results in a detached head.
I am going to start enforcing some syntax rules for branch naming in future so that this does not happen again.
I got this problem apparently because of a Jenkins upgrade. I had to (re)create the "Branch Sources" part of the configuration to fix it.
I had the same issue exactly , but with Bitbucket .
For me the issue happened due to a dev/ or Dev/ Prefix being used,
While the only prefixes defines on the Bitbucket side were :
bugfix/
feature/
hotfix/
release/
Tested the same branch with feature/ instead of dev/ worked perfectly ,
Also changing the prefix from feature/ to dev/ in bitbucket worked , but the issue there is that you cant add additional prefixed , only change one of the four already there , so i just ended up enforcing a policy to prevent people from using dev/ or any other abnormal prefixes in their branch names.
I would like to prepare 2 jobs in the same jenkins server that will read from a specific branch. I have to use the git tag for one of the jobs as to separate them somehow.
Please, could you paste some code containing the job trigger in jenkins using a git tag ?
Ok based on your comment:
jenkins changed lately and some of the old UI functions need to be placed into a groovy pipeline
I think this is a duplicate of this question: I pull the branch with tag in the groovy
The answer is perfect for what you are asking.
hope this helps.
I'm trying to add some very basic functionality that exists in every other modern ci product, but which unfortunately seems to be a completely foreign concept in Jenkins land.
I have the github plugin hooked up, and the git plugin set to build the "inverse" of "origin/master", so that pushing any branch except master triggers a build.
The problem is, if there's a flaky test and the build fails there's no way to restart it in jenkins. I added the Naginator plugin but it rebuilds the last branch that ran, not the branch of the build that you clicked "retry" on. Using the Naginator plugin, it seems that I need the git branch or sha to be a real parameter of the build. But, I can't find a way to set the git branch as a parameter of the build when a build gets triggered.
The only thing I can think of is to split it into two builds that link to the same git repo, and have the second one be a parameterized build that the first one triggers with the GIT_COMMIT value as the parameter. Then, retrying the second one with Naginator should retry it on the same SHA. This isn't a good solution though, it sucks to have to configure 2 builds for every one of my builds.
Does anyone know of a good way to accomplish this? I'm hoping I'm just missing something simple.
Unfortunately i'm unfamiliar with this exact setup, however the Git plugin documentation, section Push notification from repository, mentions that in the trigger url, the <commit ID is optional. If set, it will trigger a build immediately, without polling for changes.
If there is a built-in "button" in some plugin to issue this manually from inside jenkins UI i don't know, if not that could be a nice feature request.
So, if there really is no easy option aviable yet, as a workaround you could write yourself some script which builds and calls the url for a given branch + commit ID.
Trigger url format, as found in Git Plugin docs:
curl http://yourserver/git/notifyCommit?url=<URL of the Git repository>&branches=branch1[,branch2]*][&sha1=<commit ID>]
We are using Jenkins,GerritTrigger setup for CI and it will start build for each commit though all commits came from single push. Since all changes are dependent on each other its enough to make a single build with all changes, but I don't see that option in GerritTrigger plugin.
I believe many companies use Jenkins and Gerrit combination and I am curious to know how they are handling these cases.
Example:
If a developer pushes below 4 commits at once to gerrit it will create 4 changes accordingly in gerrit say 1,2,3,4 and it starts 4 builds in jenkins for all commit
git log --oneline
e3dfdwd CommitD
5fgfdgh CommitC
df34dsf CommitB
a23sdr3 CommitA
Here 4 commits as a whole will pass all tests in jenkins but individually they will fail. Now jenkins builds will fail for A, B, C and will succeed for D as it will checkout A,B,C as they are its dependencies.
In this case though Commit-D is successful it can't be merged as its dependencies are not passed in Jenkins.
It seems reasonable from development to expect jenkins verification for each push instead of each commit. But GerritTrigger can run for each commit only.
Question:
Is there a way to inform jenkins to start build only for commit-D as it will have all dependencies C,B,A ??
Or can we start a build for each git push from development instead of commits?
Sorry if I had any info
I found a way to start build only for commit-D.
I have introduced a gerrittrigger job which runs immediately after every commit, this job will not do any clone/build/verification.
It will just do some set of verifications like, check if given change has needed-by change, dependency exists and dependencies on same branch etc
This job will trigger another main job which does real clone, checkout change, build, verification etc only for changes which pass all validations.
So this will start job always for top commit and approve/reject all dependent changes based on job result.
Though it has few limitations, we found this method is suitable for our workflow
Most companies don't use git and gerrit :) Most companies don't even use git, unfortunately. And most of the ones that do, don't use gerrit. I've consulted for dozens of companies: two use git, and neither of them have even heard of gerrit.
I don't think it's possible to get gerrit to think of pushes as if they were commits. Since each commit in a push can be separately reviewed and rejected, each commit has to be considered and built separately. If you don't want it to work that way, gerrit might not be for you.
Instead, you should squash your related commits locally before pushing them to gerrit. This will achieve the desired results.