ReleaseEngineering:Autoland: Difference between revisions
| Line 1: | Line 1: | ||
Autoland is a system of tools running on a virtual machine that polls bugzilla for a whiteboard tag requesting autolanding. Upon finding the whiteboard tag, the module will pull either all the non-obsolete patches attached to the bug or any attachment ids (must be attached to the current autoland-specified bug) you request in the whiteboard tag and then it applies those patches to the tip of mozilla-central and pushes to try on your behalf. The results are tracked in the bug where autolanding has been requested. | Autoland is a system of tools running on a virtual machine that polls bugzilla for a whiteboard tag requesting autolanding. Upon finding the whiteboard tag, the module will pull either all the non-obsolete patches attached to the bug or any attachment ids (must be attached to the current autoland-specified bug) you request in the whiteboard tag and then it applies those patches to the tip of mozilla-central and pushes to try on your behalf. The results are tracked in the bug where autolanding has been requested. | ||
=What does it do?= | |||
Working in a single bug, the autolanding system can pick up a custom whiteboard tag and make an automated landing to try for you. It will keep details in the bug about the try push and the results are reported back to the bug when complete. | |||
=How does it work?= | =How does it work?= | ||
Insert a whiteboard tag that informs our scripts that you have patches you'd like landed. Our tools will do all the work of pulling tip of mozilla-central, importing your patch(es), pushing to try on your behalf, and your results will be posted back to the bug when the run completes. At the moment you will not receive an email about your try push, instead a comment will be inserted to the bug that gives the tbpl link for your push. | |||
==Tag syntax== | |||
Our system looks for three separate components in your whiteboard tag. The most important is 'autoland' which is how the bug will get queued up for autolanding in the first place. | |||
If you put nothing other than 'autoland', the automation will grab all non-obsolete patches attached to the bug and import them to tip of mozilla-central and push the changes to try. | |||
To provide more customization the whiteboard tag can include two other sections, one for try syntax and one for a specific list of attachmentIDs (patches) to import. | |||
Valid tags | ===Sample Valid tags=== | ||
[autoland] | [autoland] | ||
[autoland-try] | [autoland-try] # as eventually there will be autoland-$branch capabilities | ||
[autoland:$attachmentID] | [autoland:$attachmentID(,$attachmentID)] # several attachmentIDs should be comma-separated | ||
[autoland:-p linux -u none] # try syntax will get put in the commit comments to control what builds your push gets | |||
[autoland:$attachmentID:-p win32 -b o] # specifying both attachementID(s) and try syntax (use : to separate) | |||
=Can I still use try syntax to customize my builds?= | =Can I still use try syntax to customize my builds?= | ||
Revision as of 19:03, 26 January 2012
Autoland is a system of tools running on a virtual machine that polls bugzilla for a whiteboard tag requesting autolanding. Upon finding the whiteboard tag, the module will pull either all the non-obsolete patches attached to the bug or any attachment ids (must be attached to the current autoland-specified bug) you request in the whiteboard tag and then it applies those patches to the tip of mozilla-central and pushes to try on your behalf. The results are tracked in the bug where autolanding has been requested.
What does it do?
Working in a single bug, the autolanding system can pick up a custom whiteboard tag and make an automated landing to try for you. It will keep details in the bug about the try push and the results are reported back to the bug when complete.
How does it work?
Insert a whiteboard tag that informs our scripts that you have patches you'd like landed. Our tools will do all the work of pulling tip of mozilla-central, importing your patch(es), pushing to try on your behalf, and your results will be posted back to the bug when the run completes. At the moment you will not receive an email about your try push, instead a comment will be inserted to the bug that gives the tbpl link for your push.
Tag syntax
Our system looks for three separate components in your whiteboard tag. The most important is 'autoland' which is how the bug will get queued up for autolanding in the first place.
If you put nothing other than 'autoland', the automation will grab all non-obsolete patches attached to the bug and import them to tip of mozilla-central and push the changes to try.
To provide more customization the whiteboard tag can include two other sections, one for try syntax and one for a specific list of attachmentIDs (patches) to import.
Sample Valid tags
[autoland] [autoland-try] # as eventually there will be autoland-$branch capabilities [autoland:$attachmentID(,$attachmentID)] # several attachmentIDs should be comma-separated [autoland:-p linux -u none] # try syntax will get put in the commit comments to control what builds your push gets [autoland:$attachmentID:-p win32 -b o] # specifying both attachementID(s) and try syntax (use : to separate)
Can I still use try syntax to customize my builds?
Yes! In your whiteboard tag you can include the try syntax (minus the 'try:' part)
Examples:
# no attachmentIDs listed [autoland:-p linux -u none] # with attachmentIDs listed [autoland-try:409589:-p all -u mochitests]
Can I land to a branch other than try?
Not yet, but that feature will be coming soon
Can I land automatically through an API instead of through bugzilla?
Not yet, but that feature will be coming soon