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.
Related
How is image promotion handled with 'dev' images?
Like many others, we have three environments for deployments – Dev, Stage, Production.
Stage always tracks the latest master, and production deploys are triggered when releases are tagged in Github. It's easy enough to promote images between stage and production.
Where I'm having trouble understanding this is with Dev. Dev images are built on pull requests in our case, but there's a good chance the branch behind the PR is some number of commits behind master, so promoting this image through the ranks would cause outdated code to end up on stage and prod.
What is the typical practice here? Are dev images kept separate, in a separate image repository and never mixed with the stage/production images? Is there some way to promote them that I'm missing?
Stage always tracks the latest master, and production deploys are triggered when releases are tagged in Github
Dev images are built on pull requests in our case, but there's a good chance the branch behind the PR is some number of commits behind master
This is all a bit confusing to me. I like to keep things simple, and I usually advocate for one branch per environment.
In this scenario, I would advise you to have the following branches:
dev
stage
production
This will allow you to make changes to one environment at a time, progressively. So first you would push your changes to the dev branch, and if they are successful, you would then push the same changes to staging; likewise, if the changes are successful in staging, you would then push the changes to production. The pushing to the branch can and should be done via merge requests.
Each branch would have its own pipeline associated to it, which would build, test and release the image to the environment specific registry. Keeping registries separate amongst environments may seem overkill but it would make your life easier when it comes down to permissions management.
Having one branch per environment also has the added benefit that you will be able to restrict access to certain branches, e.g. everyone should be able to merge to dev but not everyone should be able to merge to prod.
In Bitbucket, After a developers code is PR'd and ready to be merged, I want a build to be made when the developer requests to merge, and for the merge to fail if the build fails. I know I can trigger a build when a pull request is made, and then use the merge checks feature, but the developers code can change during the PR which could introduce build breaking bugs. Builds take quite a while too, so I don't want it to happen every time a developer updates their code.
Is there any solution to this? Perhaps via the Build Pipelines feature?
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.
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.
For our projects have Integration and Master branch. For deployment we cut a RC branch off Integration. Once deploy is complete we create Pull request for RC to Master.
However, now Master shows as 1 ahead because it has a commit that does not exist in Integration. I considered to create Pull request RC to Integration as well, but TFS does not allow it since there are no changes.
Is there a way to avoid this situation with Master? Can behind/ahead only check the code changes and not commits? To fix this I now have to create Pull Master to Integration, and that is a pain for all the projects we do.
Afraid not able to avoid this situation. It's also not possible to make behind/ahead only check the code changes and not commits. Since you are using Pull Request (which execute git merge --no-ff).
To be honest, it's not necessary to resolve Integration branch behind/ahead master.
you can have two mostly independent branches without any problems. The important measure of differences between branches is given by git diff. If this reports no differences, then it's Ok.
You could also take a look at this similar question: VSTS Git: Is it necesary to resolve dev branch behind/ahead master and if so how?
If you insist on avoid the ahead on Master, you may have to create Pull Master to Integration as you have pointed out in the question.