I'm using following documentation: https://gerrit.googlesource.com/plugins/hooks/+/HEAD/src/main/resources/Documentation/hooks.md#change_merged which describes parameters passed to given hook.
At the moment I want to get commit message body based on commit that has been merged in Gerrit. Unfortunately there are two parameters which passing commit SHA, those are namely --commit and --newrev. I have also tried to print them out for single merged commit and value points to same commit (in my case both values are: bd2b60cccc9fba84ac66aa161ac07008b4803575)
I'm wondering which one should I use for my use case when I want to refer to commit that generated given instance of event that triggered the hook. Are there any case when those values can differ?
The "newrev" is different from "commit" when a merge commit is generated for that commit when the change is submitted to the destination branch.
See more info here and here.
Related
I have a pipeline whos job is to take attached submodules, bundle them up in a zip, and push them to an artifact repo only on a merge to the primary branch; all of this logic works fine.
However, because a merge event gets trigged for opened and merged for merge requests, for every merge into the primary branch there is always an effective "no op" build because it will receive the opened event.
From the documentation around option filtering in the generic webhook, it isn't clear to me if a no-match also won't trigger a build, or simply will product a value of "". Here is the documentation:
Value filter
Optional. Anything in the evaluated value, matching this regular expression, will be removed. Having [^0-9] would only allow numbers. The regexp syntax is documented here.
This simply leads to the javadoc on regex.
I would love to not trigger a build at all, even a no-op build, unless the state is "merged"
Yes, you can do it, but you need to add Optional Filter in another way.
In the end of GWT plugin configuration of your job, there is a global Optional Filter section:
We try to create a link to a selected line of code, but the code section where that line appears (and we what to show) is in a previous commit.
That section IS NOT part of the changes reflected in that commit, but is in the repository snapshot for that commit.
Is there a way to do that?
We found a way to do that, the trick is to reference your source code by using the commit whole hash as a branch name.
i.e. The following link gives you the source code of a public BitBucket repository in it's master branch:
https://bitbucket.org/teamsinspace/wally-learns-git/src/master/
but if you replace the "master" for the "<commit hash>" and more over, concatenate the "<file path>" and append "#lines-<the line number>", i.e.:
https://bitbucket.org/teamsinspace/wally-learns-git/src/6382d80b420b0a4e5aae204e2d9401021d2f677d/LICENSE.txt#lines-7
You get a link to the source code file, positioned showing the line, and this line remarked from the rest.
Notice that, if you look in that particular commit the LICENCE.txt file was not modified so not included in the commit changes display:
https://bitbucket.org/teamsinspace/wally-learns-git/commits/6382d80b420b0a4e5aae204e2d9401021d2f677d
I'm setting up a Gerrit server for the team. I've used Gerrit in the past, but I've never set one up.
One feature I know I've used in the past is, once I get a CL approved, I can rebase the branch without losing the approval. I assume this is a setting somewhere, but I can't find it.
You need to set the "Submit Type" of the repository (in the repository configuration page) to one of these:
Rebase If Necessary
If the change being submitted is a strict superset of the destination branch, then the branch is fast-forwarded to the change. If not, then the change is automatically rebased and then the branch is fast-forwarded to the change.
When Gerrit tries to do a merge, by default the merge will only succeed if there is no path conflict. A path conflict occurs when the same file has also been changed on the other side of the merge.
Rebase Always
Basically, the same as Rebase If Necessary, but it creates a new patchset even if fast forward is possible AND like Cherry Pick it ensures footers such as Change-Id, Reviewed-On, and others are present in resulting commit that is merged.
Thus, Rebase Always can be considered similar to Cherry Pick, but with the important distinction that Rebase Always does not ignore dependencies.
See more details in the Gerrit documentation here.
I think you are looking for the Copy All Score On Trivial Rebase labels.
The example below is from our project.config. For the Verified label the scores will be copied if there is a Trivial Rebase or a No Code Change patchset added, the No Code Change basically means an updated commit message.
[label "Verified"]
function = MaxWithBlock
value = -1 Fails
value = 0 No score
value = +1 Verified
copyAllScoresIfNoCodeChange = true
copyAllScoresOnTrivialRebase = true
defaultValue = 0
I am trying to create a utility tool for which I need to get the list of all commits that have been merged to master from the feature branch on Bitbucket. As you can see in the picture, the commit that has "M" label after the commit id is the one that I need. However, when I use the endpoint - https://api.bitbucket.org/2.0/repositories/user-name/repo-name/commits/master - it returns me a list of all the commits including the ones that do not have the label 'M'.
Is there any way I can get a list of only the commits that have been merged to master?
Click here to view the image
to get only the merge commits the parameter "merger is used".
https://api.bitbucket.org/2.0/repositories/user-name/repo-name/commits/master/merge=only
We are trying to find a way to download a single file from a Bitbucket project using the REST API at a specific commit. Currently, we have the ability to download a file at a specific branch:
https://stash.domain.com:8443/rest/api/1.0/projects/our_project/src/main/java/com/SomeFile.java?at=refs%2Fheads%2Fmaster
Note that the end of the URL, when decoded, contains the query parameter at=refs/heads/master, which refers to the master branch. This also works for specific tags:
https://stash.domain.com:8443/rest/api/1.0/projects/our_project/src/main/java/com/SomeFile.java?at=refs%2Ftags%2Ftesttag1
Here the query parameter at=refs/tags/testtag1 refers to the tag (commit) testtag1.
But because of the nature of our implementation, we would like to refer directly to a commit SHA-1 hash via the Bitbucket REST API. Is this possible?
Obviously, one ugly workaround would be to just add a tag to every commit. But this could bloat the repository and it also feels like an unnecessary hack.
With the help of this SO question, I found one of the answers which tipped me off to the correct syntax. Use this:
<URL>?at=commit_hash
For example:
https://stash.domain.com:8443/rest/api/1.0/projects/our_project/src/main/java/com/SomeFile.java?at=bed2dda5
Here is a table of three main endpoint types with the Bitbucket REST API:
query parameter | role
---------------------------------------------
refs/heads/master | specify master branch
refs/tags/someTag | specify 'someTag' tag
at=bed2dda5 | specify commit #bed2dda5