I have a requirement to deploy the release branch only by a particular user or group and the user should see only the release branches in bitbucket pipeline....
I am using bitbucket as CI.
Could you please help in this regard
BitBucket allows a lot of customization for the actions to prevent by branch protection. To protect a branch:
Go to a repository in a project.
Choose Settings > Branch permissions.
Click Add permission.
In the Branches field, select either Branch name, Branch pattern, or Branching model.
Branch name - select an existing branch by name.
Branch pattern - specify a branch using branch pattern syntax for matching branch names.
Branching model - select the branch type to restrict access to.
Select the type of actions you want to prevent.
Branch deletion - prevents branch and tag deletion.
Rewriting history - prevents history rewrites on the specified branch(es) - for example by a force push or rebase.
Changes without a pull request - prevents pushing changes directly to the specified branch(es); changes are allowed only with a pull request.
All modifications - prevents pushes to the specified branch(es) and restricts creating new branches matching the specified branch(es) or pattern.
Optional: Add exemptions for any of the selected restrictions. Adding a user or group as an exemption means that it will not apply to them. This is not required; not adding any exemptions means the restriction will apply to everyone.
Click Create to finish.
Related
I would like to push build tags to a non-standard location on gerrit, mainly to avoid them from showing up as an official tag and also to avoid polluting users with a bunch of build tags.
On old versions of gerrit, I was able to grant myself permissions to create refs and tags in, say, refs/builds/tags/*, and then do
git push origin refs/tags/BUILD-123:refs/builds/tags/BUILD-123
The beauty of the scheme is that this way, the build tags don't pollute ordinary users' git repos, but if someone is interested in the build tags, they can run:
git fetch origin 'refs/builds/tags/*:refs/tags/*'
and then all the build tags appear and become usable as tags.
It seems that on newer versions of gerrit (2.16?) direct push is limited to the standard locations.
It also appears as if one can only push tags of commits which are direct ancestors an existing branch, so if my build does anything unusual (for example rebase to the tip), it fails.
Is this configurable anywhere?
It turns out there is no such restriction, you just have to grant yourself all the required permissions, like so:
[access "refs/builds/*"]
create = <me>
createSignedTag = <me>
createTag = <me>
delete = <me>
read = <me>
I forgot to give myself read permissions...
The restriction that does exist is where you cannot push a tag that is not for a commit that is an ancestor of an existing known branch. The reason this restriction exists is because access to commits is controlled via ACLs that feature wild carded refs as primary key to permissions. If someone knew a "forbidden" sha and was allowed to push a tag, this scheme can be bypassed.
The trick is to give up on pushing tags and to push branches instead. Branches can be pushed to non-standard locations just like tags, and if someone fetches them into refs/tags, they also act like lightweight tags.
I have configured a Jenkins Pipeline that correctly receives webhooks push notifications from GitHub, on push events.
The authentication is done through a deployment key.
Jenkins configuration seems to rely a lot on the concepts of branches and pull requests.
Given my workflow, which consists mostly of creating branches for any needs, and merge changes back onto master once things would look fine on the CI, I do not really care about seeing my builds categorized by branch or PR.
I would prefer to see builds based on commits' hashes. I do not see the need to tell Jenkins what branch I want it to match.
My current configuration is not selecting the commit revision I desire. I do not understand how it decides which branch or commit to build, once it receives a push notification. In Jenkins I have set the branch to **.
Checking the webhook payload, I noticed that it contains both the list of commits but also something called head_commit, with its id property being the commit's hash I want to see being built.
I would like Jenkins to do the following:
Check what's the head commit in the webhook notification (head_commit.id in the payload)
Build that precise commit, no matter the branch it is part of
Setting a green tick or a red cross beside the commit's hash on Github
Is this possible?
We plan to have only admins able to make changes to our repo’s master branch. Developers can clone the repo and then create their own dev branch off of master to work on. When developers feel ready, they can merge their development branch onto the master branch using a pull request. However, they will not be able to merge their dev branch into master until the admins have approved the changes.
On Bitbucket, I set branch permissions as:
+ Write Access: Rachel and Jamie.
+ Merge via pull request: Rachel, Jamie, and team:developers.
+ Merge checks: check for at least 2 approvals.
Next, we had a developer (not Rachel or Jamie) make changes on their own dev branch. They then committed and pushed the changes to their remote dev branch--worked as expected.
Last, they initiated a pull request to merge the remote dev branch into master. A warning that two approvals was needed popped up, but the developer was still able to just click "Merge" and the dev branch merged into the master branch, despite 0 approvals.
I expected that the developer would not be able to merge with 0 approvals. How do I set permissions so that this is the case?
Two things:
You explicitly granted "merge via pull request" access to the developers. They're therefore able to merge pull requests. If you never want them to merge PRs to that branch, then revoke that. (They'll still be able to create PRs, just not merge them.)
You didn't mention whether you've enabled "Prevent a merge with unresolved merge checks", under the premium features.
We've created a plugin to prevent this situation. You can inspect it on marketplace:
https://marketplace.atlassian.com/apps/1219882/prevent-merge-when-needs-work
I have a multi-branch pipeline that has been configured to use branch auto-discovery. However I don't want Jenkins to automatically start a pipeline job when it discovers a new branch. I instead want the pipeline job to be started by another means (e.g. using a timer or via a REST API call).
Is this possible?
Yes, add the Suppress automatic SCM triggering property in the branch sources of your multibranch project.
You might revert to explicitly naming the branches you want to include
with auto-discovery using Filter by name (with wildcards).
The documentation states: Space-separated list of name patterns to consider. You may use * as a wildcard; for example: master release*
So, adding any new branch to the list of included branches will ensure any changes after such addition will trigger processing as usual.
Any new branch will not be processed until it is explicitly included with the list.
We use Gerrit 2.5-rc1) ACLs to manage access to our git projects & branches. We try to keep the rules simple for developer groups; refs/heads/* allow Push, Create Reference, Push Merge Commit.
There is a need to mark a specific branch, call it foo, as read only. I have tried adding a new rule for refs/heads/foo/*, allowing READ, but DENYing Push, Push Merge Commit, etc. (both with and without "Exclusive" tickbox ticked). In any case, developers are still permitted to push to that branch.
Any idea how to do this without writing server hooks, etc?
For your Gerrit version I think the following set should do the trick:
refs/heads/* ALLOW
refs/heads/foo/* BLOCK