Skip to content
This repository has been archived by the owner on Nov 11, 2019. It is now read-only.

add ability to add release phases that block the pipeline but don't trigger graphs #1772

Open
lundjordan opened this issue Dec 24, 2018 · 2 comments

Comments

@lundjordan
Copy link
Contributor

this will enable us to have customizable human signoff breakpoints for QA, relman, and releaseduty.

It would be great if some were permanently part of every release but also customizable on a per release basis. e.g. for custom release requests/tasks.

@lundjordan lundjordan changed the title ship-it add ability to add release phases that block the pipeline but don't trigger graphs add ability to add release phases that block the pipeline but don't trigger graphs Dec 24, 2018
@rail
Copy link
Contributor

rail commented Dec 24, 2018

Would the following a good example of this feature?

Let's say we add a new human phase and name it "ready to be pushed to CDN". This phase will require a signoff from QE and Relman. After both signoffs are done, the phase becomes ready and unblocks the next "Push to CDNs" phase, which can be run by anyone anytime, but not automatically.

Does it represent the idea properly?

@lundjordan
Copy link
Contributor Author

Sounds like you are splitting the sign-off from the action (submit a push graph). That's not something I have thought of and I suppose depends on the situation. For push to CDN, I imagine we want to those two to happen at the same time?

I was more thinking of supporting sign-offs that don't have an associated action. e.g. doesn't actually submit a task graph. Instead, it merely blocks the rest of the ship-it pipeline.

example:

Say relman want to add their checklist to a RC release. They have a item called "Make release notes live". This could be part of an RC ship-it pipeline. Only 1 relman is required to sign-off, and once they do, the next breakpoint can be signed-off (e.g. "publish the release").

The same would apply to releng, QA, and marketing specific checklists.

I think it be neat to add these to the templates of each release type so each release supports them but then, going further, also to be able to add them ad-hoc to a given release. An example of an ad-hoc breakpoint: say Releng have a "update bouncer version number for Election bundle" task for only a specific dot release but not all dot releases. This should really block the release but we track this manually right now.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants