Where is there any documentation on what "Active" means in the top left of the Gerrit web interface when viewing a Change?
Source:
change status in Gerrit
The change status shows the state of the change:
Active:
The change is under active review.
Merge Conflict:
The change can’t be merged due to conflicts.
Ready to Submit:
The change has all necessary approvals and may be submitted.
Merged:
The change was successfully merged into the destination branch.
Abandoned:
The change was abandoned.
Related
I already merged a pull request in bitbucket. Can you all explain what is the difference between click Approve and don't click it?
Because I see that the merge commit still appears in git history/log even that I don't click Approve.
If your team has a Premium plan, repository admins can prevent pull requests that don't have a certain number of approvals from merging.
Other than that, it is a visual check only that the merge request was reviewed and approved prior to merging.
See: https://confluence.atlassian.com/bitbucket/pull-requests-and-code-review-223220593.html
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 want to prevent my users from logging work once an issue gets to a particular status. How can I accomplish this?
I have a post-function in my workflow that sets the Resolution, but the "Log Work" item in the More menu still shows up.
I don't see in the Project or System administration any options about it.
You can accomplish this by setting jira.issue.editable to false in the properties of the status in the workflow.
Find the active workflow that applies to the issues you wish change. This is most easily done by either: going to the 'Workflow Schemes' admin page, then clicking on the Workflow link in the row applying to the issues' project and issue type, or clicking View Workflow in the Issue View.
To edit the workflow, you will need to either create a copy of it (if using the default jira system workflow) or edit the draft of the workflow.
In the Workflow Editor, for the 'Closed' step, click View Properties (in Text mode) or Properties (in Diagram mode) to see the step properties.
Editing issues in the selected step is enabled by default, or you will see a jira.issue.editable property with value true. Either create the value or chang the property value to false.
Publish your draft workflow, or if editing a copy, activate the workflow by creating a new workflow scheme associated with the edited workflow, and then associating it with your project.
Reference: https://confluence.atlassian.com/jira/allow-editing-of-closed-issues-138704.html
Why is the default gerrit change-id commit-hook not a pre-push-hook?
The default Change-Id "commit-msg"-hook in gerrit adds a Change-Id to every commit. Why is in not implemented as a "pre-push"-hook? If it where it could add Change-Ids only to commits that are pushed to refs/for/...
With the current setup I get Change-Ids in commits that I want to push directly (without a review). It's ugly.
I think I know the answer now.
It would be bad practice for a pre-push hook to change the contents that is being pushed. It could block a push from happening but changing the commits and then automatically precede with the push without the user having a chance to review the changes is bad practice.
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.