Expiry token for type: approval jobs
J
Jessica Mowatt
Example:
- approve_release: type: approval requires: - checkout_and_build filters: branches: only: /master/ expiry: 24h
Reasoning:
Jobs with type: approval require manual confirm/cancel, and as such are a good control method for jobs that don't need to be run every build, or builds that require review before completion (e.g. releases).
One use we have for these job types is to build docker images from successful builds on the fly. We don't need docker images for every build, and there are many builds in a day, so the approval jobs pile up.
We don't need any builds older than 24hrs, so a suggestion to prevent a build up of on hold jobs (not sure what impact this has on a CircleCI cloud/personal server) is to introduce an expiry token as part of the workflow description.
CCI-I-181
Oran Wilder
Merged in a post:
Approval Timeout
S
Sumir Saini
An option where if a job manual approval step is not approved within a specific time frame the workflow is canceled.
Oran Wilder
Hi folks, Oran here from the CircleCI product team. I'm curious about the most helpful functionality here.
Would you expect to apply the same expiry timeframe to all projects? Or would you set different times for different projects?
What would you think if this were a project or org setting only accessible to admins?
Y
Yarden Sachs
Oran Wilder: IMHO the duration should be part of the config
F
François Bonnefont
Oran Wilder:
> Would you expect to apply the same expiry timeframe to all projects?
Not really but it could be considered to provide a default expiry time if none was specified at the "approval job" level.
> Or would you set different times for different projects?
Yes this seems more useful. We could specify it at the "approval job" level. And we could have different values depending on the situation.
> What would you think if this were a project or org setting only accessible to admins?
I don't think it would be practical but it could eventually be considered to provide a default expiry time at an org level. We could then override it at the "approval job" level if needed.
B
Bartłomiej Wójtowicz
Oran Wilder: Different projects = different timeframes and part of the config. Default could be X days of inactivity to cancel the workflow.
M
Mark Hansen
We do our static website builds which are 100,000+ pages w/ approved builds and I'm always afraid that our content editor is going to approve an old build. We're a very small team so non-technical teammates have to be somewhat using the technical tools. It makes me nervous they're going to deploy an old version, so I'd love to expire/cancel after a few hours
B
Benjamin Lizarraga
I really need this feature
L
Lisandro Dee
This orb https://circleci.com/orbs/registry/orb/azihsoyn/job-expiration does not help in the case of the authors ideas which i believe to be a good one. The approval remains on hold until its approved or workflow is cancelled. It only expires the next upcoming job and marks it as Failed instead of cancelled if the expiration check determines that the set time has expired.
S
Stepan Vrany
This is really needed. You really don't want to have dozens of suspended/waiting workflows in your dashboard. I can imagine possible aftermath. It hurts :D
Y
Yarden Sachs
This would be very helpful!
N
Naoya Yoshizawa
Hi, I published orb for job expiration.
Until official support, this may help you.
Thanks.
E
Eric Dahlseng
This has benefits beyond limiting the build up of jobs --> we use approvals to block deployments to production, but sometimes multiple builds will pile up. If someone were to accidentally click an approval on an older build, then that would deploy over our current production environment. Expirations on approvals would help prevent this behavior from occurring.