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?
Any update on this? This is a highly coveted feature.
"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!
Using restricted context, you can control who has access to credentials for all the downstream jobs.
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.
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.
@Kunal @NathanAny additional information or update on the status of this feature?
@Nathan any update on this?
@Kunal Do you have an update?
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.
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.
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.
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.
Any news about this feature ?
That is good enough for our use case, thanks for the info, and looking forward to it.
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.
@Nathan can you share any update on this? if any
We have something along these lines in the works. Stay tuned...
You won't be notified about changes to this idea.