I'm currently using GitHub with a basic Jenkins integration (with the GitHub plugin): each time I push something, my Jenkins tests are triggered and the status is reported to GitHub.
For some dirty reasons (and I know the root cause is here), my tests could randomly fail and then report a failed status to GitHub (which blocked the possibility to merge the PR: and that's the expected behavior).
Do you know if it's possible to relaunch the tests without pushing a new commit? Because I know if I relaunch the tests, they will pass.
Update: you can also push an empty commit to your branch to re-trigger status checks: git commit -m "retrigger checks" --allow-empty and then git push <branchname>
You can do this by closing and then re-opening the Pull Request. This will cause all status checks to run again on the same commit.
Doing git commit --amend and force pushing makes github retrigger all checks. Not perfect but better than closing then reopening the PR.
There's now a button in the Github UI to rerun checks. Not sure if it works for Jenkins, but it worked for my situation.
If you open a PR that failed, under Checks tab you will see the list of all checks that were performed on your PR. Next to the failed ones, there will be a clickable text that says "Re-run"
Depending on how you have integrated Github with Jenkins and what plugin you have have used, the method might vary. But usually you have support for "magic"-sentences that will retrigger Jenkins if added as a comment on Github.
For example commenting "test this please" or "retest this please" in Github might retrigger Jenkins.
Seems like closing and re-opening the PR could be an option.
Related
Bitbucket's Pipelines can take a while to set up. I have them build on every Pull Request and Branch but by the time they get around to it, the branch can be gone.
I want Bitbucket to fail silently when it cannot find the branch. It doesn't matter to me if it aborts happily if it cannot find the branch. I do not want to receive messages of the following form:
Attempt 3 of 6 failed.
Retrying in 4 seconds
Cloning into '/opt/atlassian/pipelines/agent/build'...
warning: Could not find remote branch important_assert to clone.
Essentially, I would like to edit the "Build Setup" section to prevent Bitbucket from warning me at all in this case.
Context for why
If I make an edit to a README.md in the repo, I'm not going to hang around to see if the pipeline works. I am going to make the change, someone is going to read it, and then I'm going to merge it before Bitbucket gets around to building it. Once I've merged it, I'm going to delete the branch because it's not of much use to me lying there.
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.
Here's the first fail build. I forgot to configure file. So I added it again and recommit. Now it won't fire again.
Do I have to get a CI (using Travis CI) to first successfully test it first?
You can press the refresh button in the top right corner on your repo.
Support got back to me and told me it was a problem on their end.
Sorry that your repository got stuck in that weird "limbo" state.
Currently, we don't automatically install our webhook for open-source
repositories and without that we don't see any subsequent commits if
the first analysis errors. Our dev team plans to improve this
experience, but in the meantime, I'd recommend installing our webhook.
This hook is what notifies us of certain events happening in your
repository including commits made to your default branch.
To get that installed you'll need to run through steps 5-7 in this
help doc here: https://docs.codeclimate.com/docs/github#pull-requests.
For at least several weeks I've been using tags to deploy releases to github. I commit some changes, travis builds cleanly (or not, in which case I push some more changes :-) ), I decide it's ready to release, I create and push a tag. Travis builds again and the deploy script puts the release artifacts on github. It's marvelous.
If you look at the build history here, for example: https://travis-ci.org/ndw/xmlcalabash1-xmlunit/builds you'll see what I mean.
Yesterday afternoon, I decided to release so I pushed a 1.1.1 tag. You can see that on github: https://github.com/ndw/xmlcalabash1-xmlunit/releases but travis didn't see the commit of the tag or didn't react to it or something.
I did this on several repositories and the result was the same in each one (and had also previously always worked). I deleted and repushed the tag, but that had no effect either.
I don't think I changed "anything else". The only difference I can think of is that several hours elapsed between the last code checkin and the tag checkin.
Clues most humbly solicited.
It appears to be the case that if the last non-tag commit push used [ci skip] then pushing the tag won't cause travis to rebuild. That was...confusing.
When I use Egit to push something to a team in Bitbucket (we are all admins), the previous post from any member is deleted. The same thing happens with the other members if they push something too.
I use this configurations:
Everything works well but this, there's any idea to solve this?
Why do you have "Force Update" checked?
Normally (when "Force Update" is not configured), in a situation where you would discard other people's changes, the server rejects the push with a "Non fast-forward" message. In that case you have to first merge the remote changes into your local branch, and then push again. With this, the other changes are preserved.
But when you have "Force Update" checked and push a branch, what happens is that the branch on the remote repository is updated to point to the same commit that it pointed to on your local branch. That happens even when your branch is behind or has diverged from the remote branch, causing it to effectively overwrite/discard the other people's commits.
So what you want is to disable "Force Update" for refs/heads/* (head is another word for branch). See also Note about fast-forwards in the help for git push.
As a note: In some server software it's possible to configure the repository so that such "non fast-forward pushes" are denied (regardless of the force flag of the client). But that doesn't seem to be supported by Bitbucket yet, see this issue.