I have a bamboo plan with two branches, br1 and br2.
currently, bamboo launches automatically every time there is a commit on the master branch, branch b1 and br2.
I don't want bamboo to launch automatically when there is a commit on branch br1 and br2, but I do not want bamboo to launch automatically when there is a commit on the master branch.
How to achieve this?
(bamboo allows to disables branches, but I don't see how to disable the master branch)
ps: I am aware that bamboo is a bad choice, and we are eventually moving to jenkins. however we still need to use bamboo for a while.
The same question has been asked on the Bamboo Q&A forum.
The current selected answer there is:
Andy Davidson:
"Ok so the answer that i found that works (in case anyone else is interested) is to insert the regular expression ^((?!master).)*$ into the "Only Create Branches that Match" field on the branch configuration tab"
Related
When working on a branch together with colleagues, I find it useful to limit IntelliJ IDEA's Git Log view to the local branch I'm working on plus the remote tracking branch. This way, I see all the commits that are relevant to working on this branch.
Every time I switch branches and want to get that filter, I manually select HEAD and the remote branch. I found no way to tell IDEA to always select the current branch and its remote tracking branch.
Is there a way to let the Git Log view select "the current branch's remote tracking branch" once, and have it automatically pick the right remote branch when I checkout another local branch?
I'm currently using IntelliJ IDEA 2019.3.4, but will likely update to 2020 soon.
You can update to 2020 and check new Branches Dashboard under Log tab in Git tool window.
Then you can select local and remote branches and you will get log filtered.
Please see what's new in 2020 here:
https://www.jetbrains.com/idea/whatsnew/#version-control
Also please see and vote:
https://youtrack.jetbrains.com/issue/IDEA-233730
Back in the days I've seen on a demo (can't recall now where) where after every push, the Gitlab CI automatically created a pipeline for this commit in an appropriate branch, but without running it automatically.
This allowed user to run pipeline on any branch without having to manually select branch from "new pipeline" button.
Can't find such information in the documentation. Perhaps it was a hack but nonetheless it worked.
I was running a project with test automation on CI/CD and suddenly I got a question.
Is test automation on CI/CD really trustable?
The reason why I get this question is below.
For example, let's assume that I edit some codes on branch A and other codes on branch B and I make PRs.
As I made a test automation, The codes on branch A and branch B would be tested automatically and let's say two tests are passed.
However what if do the two parts of edited codes have no merge conflicts but interact each other and make bugs?
Then how could I trust the test automation and click the merge button?
A good question here, or, at least a situation that I have seen before. Branch A works fine, Branch B works fine but the combination of Branch A and B does not work.
I am going to assume that the automated tests catch the issue. So essentially flow of builds looks like this:
Tip of master passes.
Branch A passes.
Branch B passes.
Branch A is merged and tip of master passes.
Branch B is merged and the tip of master fails.
In this case the automation in CI/CD is trustable. As it accurately reports that the problem was caused by merging B. You can quickly return to a working state by:
Reverting the changes from B (at which point master is now passing).
Then you can get branch B ready to merge again.
Rebasing branch B on the current master.
Fixing the issue.
Testing / Reviewing and Merging branch B.
I am sure you are thinking that if you are the owner of Branch B then this is a lot of work for something you hoped would be caught prior to merge. However, typically in this environment you are trying to protect the state of the master branch. I.E. above all else the master branch is in a working state. The inconvenience to one developer is outweighed by the rest of the team being able to use the working master branch.
In terms of should you trust the automation and click the merge button. I personally avoid clicking the merge button late in the day. I trust that the automation will report issues, however, I don't trust that it is perfect. I prefer to merge in the morning where I have time to react if the build after the merge fails.
I have a dev branch with many changes (files added, deleted...). The dev branch is very different from the main branch.
I want to make my dev branch be exactly the same as the main branch in current state (as if I just created it).
Integrate do not fully match the branches. added files in the dev branch are not being deleted.
What is the best way to do it?
Delete the dev branch and re-create it?
Thanks in advance
Delete the dev branch and re-create it?
If you do this you will probably regret it; Perforce will see that you deleted all those files and try its very best to preserve the apparent intent behind that delete by doing things like propagating the delete back to the mainline at the next opportunity.
The command you want is p4 copy:
p4 copy //depot/main/... //depot/dev/...
or
p4 copy -b dev-branch
(or whatever)
Unless you want the history to be exactly as if you'd just created it. Then:
p4 obliterate -y //depot/dev/...
p4 populate //depot/main/... //depot/dev/...
We use a dev-test-prod branching scheme with bzr 2. I'd like to setup a bzr hook on the prod branch that will reject a push from the test branch. Looking at the bzr docs, this looks doable, but I'm kinda surprised that my searches don't turn up any one having done it, at least not via any of the keywords I've thought to search by. I'm hoping someone has already gotten this working and can share their path to success.
My current thought is to use the pre_change_branch_tip hook to check for the presence of a file on the test branch. If it's present, fail the commit.
You may ask, why test for a file, why not just test the branch name? Because I actually need to handle the case where our developers have branched their devel branch, pulled in the shared test branch and are now (erroneously) pushing that test branch to production instead of pushing their feature branch to production. And it seems a billion times easier to look for a file in the new branch than to try to interrogate the sending branch's lineage.
So has someone done this? seen it done? or do I get to venture out into the uncharted wasteland that is hook development with bzr? :)
your approach should work and the plugin will be quite simple: just raise an exception if the file is present.
(For some sample code you can look at a plugin I wrote that can prevent commits on some conditions https://launchpad.net/bzr-text-checker)