Fuchsia's Gerrit code review site supports an automatic change submission feature. Any change that is opted in will automatically be submitted after being approved and passing presubmit checks.
When adding reviewers in the Gerrit UI using the REPLY dialog, select the +1 for the Fuchsia-Auto-Submit label.
After your change meets all the submit requirements (generally a Code-Review +2 vote and owner approval of all affected files), the auto-submit bot will apply the Commit-Queue +2 label. Once all presubmit checks pass, your change will automatically be submitted.
If you want your change to land as soon as possible after approval, it's recommended that you set Commit-Queue +1 before (or at the same time as) sending your change for review. When auto-submit applies the Commit-Queue +2 label, it will skip rerunning any checks that have already passed within the last 24 hours, so submission often doesn't need to wait for checks to rerun.
How long does it take for auto-submit to submit my change?
Auto-submit is implemented as a cron job that runs every 10 minutes, so it may take up to 10 minutes for Commit-Queue +2 to be applied to your change after being approved.
How do I tell if a change has auto-submit enabled?
If the author of a change has opted into auto-submit, a Fuchsia-Auto-Submit +1 tile will appear under Trigger Votes in the left column of the Gerrit UI.
I'm a reviewer on a change with auto-submit enabled. Can I approve it without submitting?
If you leave unresolved comments at the time you grant Code-Review +2, the auto-submit bot will not submit the change until all comments are resolved.
However, the change author can still manually set Commit-Queue +2 to submit the change. If you think the change should not be submitted, then it's recommended that either you withhold Code-Review +2 or, if another reviewer has already approved the change, set Code-Review -2.
Auto-submit rebased my change and now I no longer have Code-Owners approval. Help!
This happens when the change had implicit Code-Owners approval as a result of you (the change uploader) owning the affected files. Either rebase your change locally on the main branch and re-upload, or click REBASE in the Gerrit UI.
Why does this happen?
When working with stacks of changes, Gerrit will sometimes incorrectly consider a change to have a merge conflict after its parent change is submitted, in which case it will not be submittable.
As a workaround, the auto-submit bot rebases a change on top of the main branch when it detects a spurious merge conflict. This fixes the conflict but also results in the bot taking over the change, removing the implicit Code-Owners approval of the change uploader.
When you upload a new patchset by rebasing you take back ownership of the change, restoring your implicit Code-Owners approval.