I have a training Gerrit box running:
change id required
strategy = merge as required
commit-msg hook installed and working
Regular commits work just fine, but after a merge commit made by Gerrit, pushes fail as the merge commit has no change ID
Asking around I've heard most people say they have strategy = rebase as necessary.
A similar question (Why does Gerrit not include the change-id into merge commits?) has a work around for the same issue using another hook.
My conclusion then is that merge as necessary and change-id required are incompatible but I can't find any confirmation of this
Related
In bitbucket when I go to the 'commits' page to see my list of commits for a branch, I see that some commits are full brightness, but others are faded/greyed out. What is the meaning behind this?
I've seen one other answer regarding this on the entire internet (no mention in official Atlassan documentation), but the answer was confusing.
These commits are likely merge commits, where BitBucket looks for a specific format in the commit comment:
This behavior is based on the commit comment. It must contain following lines:
Conflicts:
src/app.cpp
If bitbucket detects this pattern in the commit comment, the merge commit will be highlighted in commits view. Otherwise, it will appear as greyed-out.
Source: bitbucket web: highlighted or greyed-out merge commits?
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.
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
Is there a way to implement a commit message policy on BitBucket Cloud?
From my understanding, the webhooks only work as commit notifications and can not intervene with the commits (to deny the commit if the commit message does not follow the set regex). For pre-commit hooks you would need BitBucket Server, right?
If that's the case, what about checking commit messages on a Jenkins build to fail the build if it contains a certain message that does not match the regex? Is that a viable option?
Another option, is there a local git config file where I could set the rules locally (even if they could be bypassed)?
I think you're confusing pre-commit hooks (which determine whether or not a commit can be made) with pre-receive hooks (which determine whether or not a specific remote will accept pushes). Bitbucket Cloud does not currently support custom pre-receive hooks, but Bitbucket Server does. Pre-commit hooks would need to be installed on every system where users make commits; those are not currently replicated, so you'd need everyone to manage them manually.
It sounds like Jenkins tests would be your best bet - check the commit message for the desired regex, and fail the test if the regex isn't there. That won't prevent people from making bad commits in the first place, but it will keep those bad commits out of the final product.
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