CircleCI Ideas

Specified persons only can approve the workflow

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?

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Apr 3 2018
  • Shipped
  • Attach files
  • Admin
    Nathan Dintenfass commented
    April 03, 2018 20:06

    We have something along these lines in the works. Stay tuned...

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    June 06, 2018 14:05

    @Nathan can you share any update on this? if any

  • Admin
    Nathan Dintenfass commented
    June 06, 2018 18:26

    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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    June 07, 2018 01:18

    That is good enough for our use case, thanks for the info, and looking forward to it.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    June 21, 2018 10:22

    Any news about this feature ?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    August 10, 2018 19:41

    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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    August 22, 2018 19:57

    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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    August 28, 2018 20:34

    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.

  • Admin
    Kunal Jain commented
    August 28, 2018 22:44

    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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    24 Jan 20:28

    @Kunal Do you have an update?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    08 Feb 17:07

    @Nathan any update on this?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    14 Mar 18:03

    @Kunal @Nathan
    Any additional information or update on the status of this feature?

  • Admin
    Kunal Jain commented
    18 Mar 18:30

    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. 

    Thanks!

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    18 Mar 18:57

    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.

  • Admin
    Kunal Jain commented
    29 Mar 20:49

    Using restricted context, you can control who has access to credentials for all the downstream jobs. 

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    24 Oct 17:10

    "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!