I am facing an issue where I notice in my organisation sometimes engineers make changes to the Jenkins file and they change the Jenkins job branch inside the Branch Specifier (blank for 'any') section. Now, the issue is engineers sometimes forget to merge their changes from their dedicated branch to the stable branches such as the master branch for example.
I want to track all those Jenkins Jobs and send it an alert on Slack if the Jenkins Jobs are running from non-master branches. It will help me and my team to trace out easily the jobs which are not running from the master branch.
Sending alerts via Slack is easy, I am more interested in tracing the non-master branches.
Basically you want to receive an alarm if Jenkins is building a branch other than 'master'?
Since editing Jenkinsfile does not make sense (as your developers can change the file to their taste), you need to think of something else. One of my thoughts was to make Jenkins run on Jenkinsfile2 which would send your alarm and then just build Jenkinsfile. But that is not fully thought through (I guess this is not a full match: How to invoke a jenkins pipeline A in another jenkins pipeline B)
Another, easier to implement option could be to have another Jenkins job monitoring the same repository. It runs a pipeline directly coded in Jenkins that just checks the branch name and sends the alarm if need be. The branch name should be available
Related
We are using Jenkins(v2.235.1) and BitBucket cloud combination. We have BitBucket Team/Project type job which has created multi-branch pipelines. Some of the jobs corresponding to individual branches are getting disabled even these branches in the Git repo are active. Not sure why this is happening.
Can you please share some insight on this and how we can prevent this from happening.
Below are my versions
Jenkins v2.235.1
Bitbucket Branch Source plugin v2.9.7
Bitbucket plugin v1.1.27
Thank you
If there is no Jenkinsfile at the root of the repository or if the name is misspelled or is with different letters casing, like JenkinsFile, the job will be disabled.
From https://www.jenkins.io/doc/book/pipeline-as-code/
Presence of the Jenkinsfile in the root of a repository makes it eligible for Jenkins to automatically manage and execute jobs based on repository branches.
Make sure you have only one jenkinsfile in your root directory. it is not a good idea to have more than one file with the name jenkinsfile which causes jenkins to disable the job. this could be one the reason why your job is getting disabled.
In addition to previous answers.
Jobs (branches/PRs/tags) also can be marked as disabled if you first start using all available discovering options (Bitbucket Team/Project -> Configure -> Behaviors -> Within repository -> Discover ...) and after that removed one or some of them. In this situation, a Child project of Bitbucket Team/Project indexes all branches/PRs/tags first (keep them active), and after the configuration was changed, it reindexes and disables unneeded items.
Also, jobs can be marked as disabled when Bitbucket Team/Project is configured in a way when both branches and PRs are discovered, but for branches configured the "Exclude branches that are also filed as PRs" strategy. In such a case, the branch that becomes a PR (a branch from which PR has been created) will not be tracked by Jenkins.
I think I'm missing something quite simple here so I thought I would ask.
I have a development branch that developers raise PR's against, when this occurs I would like my Jenkins pipeline to automatically trigger.
Then once a merge happens and a push goes to the development branch, I want to do some extra steps which I have configured in the pipeline successfully.
The problem is how do I get Jenkins to automatically checkout and build branches that have a PR raised against development?
Currently I'm using GitHub hook trigger for GITScm polling and I can see the triggers in github being fired but it just constantly rebuilds the master branch instead of the branch that the PR is being raised on.
We are using github-branch-source and this automatically builds PRs.
There is a nice documentation: cloudbees docu
I am currently using Cloudbees Jenkins Coreas my Jenkins solution.
I am using Jenkins Pipelines to write our Jenkins job configuration. These pipelines are stored in GitHub repositories. Each Jenkins job when created is connected to a GitHub Repository where the source code is pulled from, and that's where the Jenkinsfile is stored and Jenkins reads from.
Below are some high-level photos for how our Jenkins jobs are configured.
The advantage of the way these jobs are configured is the Jenkinsfile is always read from the master branch. Meaning if a rouge developer tries to remove stages from the Jenkinsfile from within there own branch, it doesn't matter because the Jenkinsfile is always read from the master branch (which is always protected).
However, the one massive drawback to this - is how do teams and developers who are devops engineerings make changes to the Jenkinsfile? For example, let's say a developer creates a branch called feature-jenkins-search and they edit the Jenkinsfile adding a new stage in the pipeline. Whenever they push these changes to GitHub to test - they can't test as it's always read from the master branch? Meaning devops engineerings have to work directly on the master branch? Surely this is not the best way to go and there is a better configuration to set?
We do want to still provide the security that if a developer is rougue and
You should really look into the Jenkins multi-branch pipeline feature. The Jenkins multi-branch pipeline allows to create a single configuration item in Jenkins (a bit like a folder) that can detect all the branches and pull requests in a GitHub repository with a Jenkinsfile and build them using automatically created jobs. Inside this multi-branch pipeline object when it is configured in Jenkins, you will find a number of jobs to build the various branches and pull-requests in the GitHub repository.
So your developers should maintain a Jenkinsfile in every branch they work on in GitHub to build that branch in your Jenkins server.
It is possible to make the Jenkinsfile do branch specific handling if required with conditional stages / when conditions in the Jenkinsfile pipelines in each branch.
You can lock down the master branch so that code and Jenkinsfile changes from other branches can only be merged with an approved PR (pull request). There is good integration between Jenkins and GitHub such that you can configure the master branch to only allow a PR to be merged if the PR is buildable in Jenkins. So if developers add new stages / processing to a Jenkinsfile on a branch being merged to master, it should be validated so that builds of your master branch are not broken.
There is a lot of configurability in the Jenkins multi-branch pipeline object for detection and handling of branches and it may be necessary to experiment to get it right for what you need with your team. If you cannot find this feature in Jenkins, it is probably because the correct Jenkins pipeline and GitHub related plugins are not installed.
You could also have a look at a similar Jenkins feature called the Jenkins GitHub Organization Folder which allows to detect and build all repos and branches at a GitHub Organization level. But when starting out, I would suggest to look into the multi-branch pipeline at the single repo level first.
These features are discussed in the Jenkins pipeline documentation. We use these features with our internal GitHub and Jenkins server and it works very well.
I think you will find the idea of using a single Jenkinsfile in the master branch to be used for building all branches is unworkable, as you have seen!
I recently made the transition from Subversion to Git for all my repos at work. However, with svn we had commit hooks in place so that our Jenkins job would run for whichever branch was checked into. Now, I'm trying to set this up using Gitlab and there appears to only be one place to add a web hook. It looks like any time something is checked into ANY branch, the web hook will run. Meaning if I have a branch_A associated with jenkins_job_A, something could be checked into branch_B and the commit hook for jenkins_job_A will still run. Is there a branch by branch way to configure these web hooks? Or is there some kind of script I can check into each branch that will act as a commit hook? Or (my fear) is this feature not supported in Gitlab?
I guess you set up GitLab to do a post commit request to http://yourserver/jenkins/git/notifyCommit?url=<URL of the Git repository>? In theory this should trigger the polling on all jobs that are configured with that URL, and in the polling step the jobs should decide whether they should build or not. In practice this will unfortunately cause all jobs to fire.
We worked around this issue by moving the Job configuration into a Jenkinsfile and then use a Multibranch Pipeline.
As an alternative you could also install the GitLab plugin for Jenkins and use the Jenkins integration in GitLab. This will allow you to trigger the correct jobs when commits are pushed on a branch. The downside is that it requires a per-job configuration.
To give some context the question is about GitLab and Jenkins setup.
I know how to setup a web hook, I know how to setup a job to be triggered by the hook. The problem is that I need to have multiple jobs and only a single entry-point (parent job) trigger for them.
The downstream jobs at the same time need to be git repo aware so I have to set repo url for them. This causes them to be triggered independently by the hook and I don't want that as this means that they are triggered twice.
On the other hand if I don't configure repo url on a downstream job and the parent job triggers it, it fails as it is not able to do a checkout.
I may try to hack around with some 'execute shell' build step, I believe it's not a valid way to go. Has anybody a good tip how to solve that?
For the reference here is the GitLab Jenkins plugin documentation according to which:
Plugin will parse the GitLab payload and extract the branch for which
the commit is being pushed and changes made. It will then scan all Git
projects in Jenkins and start the build for those that:
match url of the GitLab repo
match the configured refspec pattern if any
and match committed GitLab branch
I tried playing around with different settings, without a great result though.
For the project you want to get only local triggers, just enable Don't trigger a built on commit notification in the Additional behaviours of git plugin.
(https://github.com/elvanja/jenkins-gitlab-hook-plugin/issues/11#issuecomment-35385032, as you actually have discovered).
But a better solution could be to make your downstream jobs reference the repository locally cloned by main job (not sure if actually possible), so the plugin will never consider them for schedule a build, as the git url don't match.