We use Jenkins to verify patch sets. Sometimes Jenkins needs do some changes on the patch set. So it commit --amend the changes and then uploads the new patch set.
It work nicely besides the fact, that all manual reviews made to the original patch set get erased.
How can I push a new patch set (from Jenkins) without loosing all existing reviews/votes?
Be aware that, in the situation you have described, you have a new patchset and, excluding in special situations, you don't want votes of the old patchset copied forward to the new patchset. For example: if someone have approved the patchset1 and Jenkins pushes the patchset2, probably he/she doesn't want to have his/her vote automatically copied to patchset2.
Said that: you can control how votes will/won't be copied forward to new patchset setting the label.LABEL-NAME.copyXXXXX options of the project. See more info in Gerrit documentation here.
Related
The problem:
I'm using bitbucket stash (server) API in a script for my project with the {path} api method:
/rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/browse/{path:.*}
The idea was to save versions of config files in a repository (version01-versionXX for every config). But those configs have the same structure with different names and parameters,
so when I push a new config with a commit message like 'version01' without specifying any sourceCommitId, bitbucket automatically adds a parent commit from the last file with the same structure (if it exists). As a result, in this new file's history I'm getting several 'version01' commits, which is not what I was intended to have.
What I've tried:
If I do specify sourceCommitId as the initial or the last commit on the branch, I get an error message since the file doesn't exist on this commit.
I've tried to experiment with empty sourceBranch parameter, but still some parent commit appears.
The only idea I came up with is to create a new branch for every config, but this seems like overkill to me.
All attempts to find a method for editing file commit history via API also failed.
At the moment as a work around I create every config file with its name as the only line of its content and then change it to the structure I need. This works so far, but doesn't look like a good solution to me and requires 2 API requests instead of one.
Is there a better way to prevent BitBucket from treating those new files as copies of old ones?
Is there a way to delete a patch set in Gerrit? I accidentally pushed a file with a password in it to my change. I removed the file in another patch set but the file is still visible in the patch set history. I attempted to find a way to delete that particular patch set but the only thing I could find on how to do this was the following documentation...
https://gerrit-documentation.storage.googleapis.com/Documentation/2.8/cmd-review.html
which shows a delete option but that option is no longer available in later versions.
I ended up just checking out the latest patch set, creating a new branch, deleting the current change in gerrit and pushing the change from the new branch which removes the old patch sets but it seems a bit cumbersome.
No, you can't delete a patch set in Gerrit, but it's possible to delete the whole change. If you do not see the "Delete change" option, it's because you don't have permission to do that.
There are two permissions to control this, see the Gerrit documentation:
Delete Own Changes
Delete Changes
Last but not least, in these cases, it's better to simply change the password instead of trying to remove it from the repository. It's better safe than sorry.
A colleague sent me a Gerrrit code review "draft" (I suppose via "refs/drafts/master" instead of "refs/for/master") and then left on holiday. Without downloading the patch and submitting it myself, how can I promote his draft to a full regular code-review so I can approve it & submit it for merging?
I think this is a similar question, but it's for git-review, not Gerrit. Also I'm interested in doing it from the Gerrit web GUI if at all possible. And I don't see a "Publish" button on my Gerrit web GUI for that draft. (And currently it doesn't say anything about merge conflicts, as long as I hurry....)
If I click on the "Patch Sets" link in the top right of the GUI, this is what I see:
In the top left it says "Change 58358 - Draft", and in the middle of the window it shows this:
Only the change owner can publish a draft patch set. Using the UI's cherry-pick option as described in other answers won't work because the cherry-pick implementation preserves the draft status on the new change or patch set.
As far as I know the only way to force the change into NEW state is to manually download the commit and push a new patch set using refs/for/master instead of refs/drafts/master.
Note that if you're not rebasing the change onto a new parent at the same time, you might need to slightly edit the commit message to make gerrit accept it. Otherwise it'll reject with no new changes.
If your colleague add you as reviewer, you can. You can cherry-pick this commit.
Click on download link at the right-top corner, and there are aliases for commands above.
But as you updated your question, you don't want to check out and manually push or cherry pick to master branch. You can use cherry-pick\merge button on ui, if you are confident in this mr, and it should be on master branch. Also you can publish this commit for other reviewers.
p.s. updated (you can cherry-pick, merge, publish via UI)
Do the following procedure:
1) Go to the draft change page
2) Click on Cherry Pick button
3) Write "master" in the Cherry Pick to Branch field
4) Adjust the Cherry Pick Commit Message if needed
5) Click on Cherry Pick Change button
It'll be created a NEW CHANGE cherry-picked from the draft change. Go to the new change page and follow the regular Gerrit process (review, approve, submit). The original draft change can be abandoned or deleted.
I have accidentally pushed a change to gerrit that should have been pushed as a draft. Now I'd like to unpublish the change back to a draft.
Pushing it again to refs/drafts/* doesn't work as it isn't changed.
Update:
I followed the suggestions of mvp and HiB; I abandoned the change, amended the commit message (removing the change-id, letting the post-commit hook generate a new change-id) and pushed it again. This resulted in a 'new' draft change. At first it looks OK, but history etc. isn't preserved of course. Not a big issue, but not the clean solution I'm looking for.
Once a change is published you cannot set it back to draft, but you may create new draft patch sets for a published change.
If I have multiple patch set versions for one change in Gerrit, it seems like I can only submit the latest patch set version (because only that one has the necessary button). Is there an easy way to instead submit one of the old patch set versions of the same change, using only my web browser on that Gerrit instance?
I know that I can fetch the wanted version of the patch set from my git client and push it as yet another new patch set version on top, but I would like to avoid having identical patch set versions multiple times in the review and discussion around it.
No, sorry, this is not currently possible. The design assumes that the most recent patch set is the one developers will review and test, and as such older patch sets can not be submitted. They also can not be reviewed/verified. If you want to use an older version of a patch set, you must re-submit it to make it the most recent patch set. To avoid no new changes error do git commit --amend and git will create a new sha1, which will be happily accepted by Gerrit as a new patch set.
There is no proper way to do this using only Gerrit UI. Cherry-pick the specific "patch set" of the "change list" (e.g. if there are 15 patch sets in a Change List and want to revert back to patch set #8). Get the cherry-pick command from Gerrit UI for the required patch set.
Run that cherry-pick command, and use git commit --amend, then push your change. It will generate new patch set (for above example #16).
The only way I could do this was as follows (from the change refspec assuming you are in Gerrit revision "<change-no>/3" and want to go back to "<change-no>/1").
git review -d <change no>,1
git commit --amend # modify something in the commit message
git review # resubmit the changes, will submit to rev 1