When we have a deploy job to production, we need only Managers to approve the workflow. Currently anybody following the project can approve the workflow. Better still can you trigger a email with the approval link?
We have something along these lines in the works. Stay tuned...
@Nathan can you share any update on this? if any
The first feature that will allow something like this will be the ability to protect contexts to be executed only by certain people in a group -- this will locate the restriction on the downstream job rather than the approval itself, however, so we may also provide approval-level restrictions later.
That is good enough for our use case, thanks for the info, and looking forward to it.
Any news about this feature ?
I am also looking forwards to this feature. We want to allow only a group of user to approve a job in workflow before the next job of deploying to production.
The holds feature is nice. I don't think we have a use case as is. If we can limit who can approve the holds we will start using it as soon as it is available.
We can't use CD on CircleCI until something like this is implemented. Restricting to users named in the contect or an option to restrict approval to github repo admins would either be OK. But we have new developers and we have consultants who have write access to the repo, so we need to be able to have production deploy trigger restricted.
We are currently testing this feature internally. I will update this thread when we are ready to roll it out. Thank you so much for your patience.
@Kunal Do you have an update?
@Nathan any update on this?
@Kunal @NathanAny additional information or update on the status of this feature?
Thank you so much for your interest!
We are in process of rolling out `restricted contexts` feature that will help with this particular use case. Please free to review the docs PR if you are interested.
Sweet. My managers have been bugging me about this. We want to restrict who can deploy to prod but let everybody deploys to QA/staging. We have different contexts with same keys for credentials. This will let us control who can trigger job with credentials for productions.
Using restricted context, you can control who has access to credentials for all the downstream jobs.
"Using restricted context, you can control who has access to credentials for all the downstream jobs. "
It makes more sense to avoid the execution of the job instead of failing with unauthorized!
You won't be notified about changes to this idea.