Gitea recommends a separate Gitea Plugin for Jenkins. I'm puzzled why two identical builds are triggered when a PR is created.
I'm trying to achieve the following:
Without a PR, a push to a branch should NOT trigger a build
Every time a PR is requested in Gitea, a build is triggered for the PR.
If a new revision pushed to the branch for which a PR is created, another check build should be triggered
It's kinda working... But for some reasons two builds are created. Could someone please explain, what are these pipeline/head and pipeline/pr-master builds, and why there are two of them?
Here is the relevant part of my Jenkins configuration. I understand that this selection is a "legacy" one, however it's the only one that allows me to build only on PR. If I select the "recommended" one, then every push triggers a build, which is not what I want.
Thanks!
Answering my own question. Awwww what a silly sausage I am. The only thing that needed to be done was removing the "Discover branches" behaviour. And, naturally, it stops discovering "just branches" :) For some reasons I did not realise I can remove the default behaviours.
Related
Problem: I need to get a list of merged pull requests (for a single git branch) from github, in jenkins pipeline. Only the ones since the last jenkins build.
This branch is checked out during the pipeline so below script works in simple cases:
def changes = currentBuild.changeSets
I then use this to loop and get all the commit ID's, make an API call to get the parent PR titles and use those for notifications "your PR 'title' was included in CI build 'name of job' ".
This works in simple scenario where I set up a test PR and merge it to the branch in between builds, but the following scenario is a problem:
branch from a 2 month old tag
make a change
merge the PR into main results in hundreds of changesets in currentBuild.changeSets during the next build. It looks like it picks up old merges which gives me useless, old, closed PR titles.
^above is a realistic dev scenario that need to be pre-empted
I dont fully understand how this works, the documentation isn't helping much: https://javadoc.jenkins-ci.org/hudson/scm/ChangeLogSet.html
It's just something you see suggested often here 'use currentBuild.changeSets' so I experimented with it. Im starting to think this doesnt give me enough control and I need to try alternative approaches.
Looking for suggestions and best practices. Guessing Im not the first person with this problem.
I have previously use Jenkins and BitBucket on premises and been able to have Jenkins notify bitbucket of the build condition of each individual branch (success, failed, in progress) however since I moved to bitbucket cloud it has started applying the condition of every build on every branch to every branch. For example if I have just a master and develop branch (to keep it simple) and the master branch failed because of some deployment configuration I am unable to merge a fix into it from develop even if develop is passing because it claims 1 of my 2 builds is failing on the develop branch.
This is tough to explain clearly in words so I've attached some pictures:
Two branches one build failing but both being marked as failed
Showing that develop branch is passing
Proof it wont let me merge
These notifications come from jenkins and have been set up using the standard cloudbees-bitbucket-branch-source:2.9.7 plugin to scan my bit bucket cloud.
Okay so this was a really obvious mistake but I thought I would leave the reason why this happened here in case any one makes the same mistake. cloudbees-bitbucket-branch-source:2.9.7 notifies bitbucket using the commit ID, when creating the branch structure for the repository I branched off main to make develop and both got built but both had the same commit ID and so both were notified of both builds. The problem fixes it's self on the first cycle of code to run through it.
I'm setting up a new Jenkins job using multibranch pipeline and I have noticed that when a branch is deleted, it only has a strikethrough and isn't actually removed on Jenkins. This is solved by re-running branch indexing. However, I cannot really use this as it will also cause every other branch to rebuild (a consequence of how the repository is updated). Is there some custom code or pipeline/script I can run to re-index without building?
I've already looked at various UI methods such as suppressing SCM triggers, but this also negates push events from Github which is something we want to use.
The deleted/merged branch build will disappear after a period of time (<24 hours). It is not removed immediately to show the recently deleted/merged branches and give a chance to review the prior build statuses. It is relatively harmless since the jobs for these branches are deactivated (read-only).
Note that the removal is based on the branch indexing job running at regular interval, so if you have this disabled, it probably won't do it (not sure the SCM webhook calls are enough).
I want to have Jenkins CI test every branch but not all existing one, solely the ones which received a recent push.
I have set up a GitHub web hook which triggers new builds. This works fine for the branch specifier set to master. Now I tried ** so every branch is built.
The problem: on the first push it tries to build every branch, which is simply too much and would take ages. Is there a way to limit this?
There is no configuration which supports the feature you are requested and since it looks like there is no plugin yet. Your best shot would be to implement your own plugin that can specify a certain date threshold for branches.
Having said that, to solve your problem I would simply:
Empty the shell script for your job
Trigger a new build
Set your shell script again
This way all remote branches get checked out, run and marked as successful within no time due to the empty shell script. After re-enabling your actual shell script you are good to go.
We just switched to using Hg Flow, but one of things that we still haven't quite yet figured out is how to best use Jenkins with it. Ideally we would have a job which builds and tests develop, one that builds and tests default and other jobs which are automatically created when a feature or release branch is created, and ideally also delete the job when the feature or release is finished.
Does anyone know if this can be done, and if so, how exactly to do it?
It would be extra nice if Jenkins was able to read from Hg who it was the created the branch and mark them as the contact person if/when the job builds, but this is really just a nice to have.
Thanks in advance
There is a Job Generator Plugin that could be used here. You'd create a job that watches the entire Hg repo for changes, and when it sees one, you run a task that parses the commit, and creates a new job with the new branch in place of templated fields.
If you can see a history of branch creation, you could use that information only in your job-creating task to fill out contact details too.
I haven't tried it myself, but I found this plugin (for GitFlow):
Jenkins Build Per Git Flow Branch
This script will allow you to keep your Jenkins jobs in sync with your
Git repository (following Git Flow branching model).
Also see the author's blog post on this plugin.