832979 - update release automation documentation for ship it!

Status: RESOLVED FIXED

(Release Engineering :: Release Automation: Other, defect)

Description

[[e-mail] (:bhearsum)]

doo eeeet

Comment 1

[[e-mail] (:bhearsum)]

Done:
https://wiki.mozilla.org/index.php?title=Release%3ARelease_Automation_on_Mercurial%3AStarting_a_Release&action=historysubmit&diff=503314&oldid=498021
https://wiki.mozilla.org/index.php?title=Releases%2FRelEngChecklist&action=historysubmit&diff=503319&oldid=503300

Note that the "run release runner" section will be removed after {{bug|810393}} is completed.

Comment 2

[[e-mail] (:bhearsum)]

From e-mail:
On Mon, Mar 11, 2013 at 11:24:46AM +1300, Nick Thomas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Thanks for writing up the docs, great to have.
> 
> My paranoid-o-meter is going off at using our own keys for release
> runner. Do we have any safeguards in place to prevent our higher
> commit privs from landing staging changes in the prod buildbot-configs
> and so on ? Looks like this could happen if the release-runner.ini was
> not pointed at user repos, which seems quite possible if someone takes
>  http://mxr.mozilla.org/build/source/tools/buildfarm/release/release-runner.ini.example
> as the basis for their own copy.
> 
> Perhaps putting staging ffxbld key on dev-master01 and running
> release-runner there would avoid this.
> 

That's a good point - it's definitely something that could happen in the circumstance you describe.

My original thought was to have things running on dev-master01 with our own keys, but that hit the trouble of the private key not being available. I'll give things a try with the stage-ffxbld key and see if that will work.

Comment 3

[[e-mail] (:bhearsum)]

Nick, I made the change to ffxbld and tested it. Would you mind reviewing?

https://wiki.mozilla.org/index.php?title=Release%3ARelease_Automation_on_Mercurial%3AStaging_Specific_Notes&action=historysubmit&diff=606353&oldid=547885

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

Much nicer. You could possibly avoid the authorized_keys change by having a separate account for release-runner, or by teaching fabric not to bother sshing if the local hostname is the same as the destination.

Comment 5

[[e-mail] (:bhearsum)]

(In reply to Nick Thomas [:nthomas] from comment #4)
> Much nicer. You could possibly avoid the authorized_keys change by having a
> separate account for release-runner, or by teaching fabric not to bother
> sshing if the local hostname is the same as the destination.

Not to try and be lazy, but I'm going to stick with what we've got now - I think it works well enough.