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.
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.
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.
I would like to have Github releases created automatically from the code of Jenkins-job. Ideally, I would like that these releases have also the generated release-notes in description that might be manually edited afterwards if necessary. Is it possible to write the Gradle-task or code (in Jenkinsfile) which make it work?
We use Gradle as a build tool. Already have Git plugin installed on the Jenkins server. I guess that the Github API should be used (https://developer.github.com/v3/repos/releases/#create-a-release ), but as far as I see a release can be attached only to ONE commit (with its tag), while I would like to see eventually ALL commits that come along with this release (and since the previous one), not only the latest commit.
I would like to achieve the following setup in Travis CI.
Do a build whenever commits are pushed to dev or release branches only.
Disable builds whenever commits are pushed to any other branch apart from dev or release but build pull requests.
If a developer is really interested to know if his commits are good, then he should be able to kick start a build on Travis CI explicitly by choosing a branch/commit.
From reading the documentation on Travis CI and some blog posts, I see that I can achieve "1." and "2."
Does anyone know how to make "3." work?
Update-1:
The reason I want scenario "3." is because the developers in our team (or in general any other team) make several commits and push them even before they send out a pull request. Building for every single commit of a private branch even before it goes for a pull request is causing lot of requests to queue up in the Travis CI queue which unnecessarily blocks developers who really care to verify a particular commit to check if everything is good or not before sending out a pull request.
Having the following is just fine for us:
Build on every commit push to dev and release branches
Build on every commit pushed to a pull request
You can easily achieve 1 and 2 by whitelisting the branches you want to see push builds for:
branches:
only:
- dev
- release
For reference, see https://docs.travis-ci.com/user/customizing-the-build/#Whitelisting-or-blacklisting-branches.
You can achieve 3 only if your developers open a PR against one of the whitelisted branches.
I'd personally recommend to open a PR as early as possible (after the first commit), as it makes work in progress visible to everyone who is interested.