Hi
In Circle Ci 1.0, I’m able to use the owner filter to make sure that only a specific owner triggers a deploy to our infrastructure. Is it possible to use the owner filter in Circle Ci 2.0?
1 Like
This is a duplicate of Owner filter, which got no answer, and I am also looking for the answer to this… This is a real problem CircleCI folks, one of the obstacles of moving https://github.com/openfisca/openfisca-core to Circle 2.0: we have 5-6 active forks, and it’s a pain to get deployment failure notifications that are not legit.
We’ve also been using the Owner filter in CircleCI 1.0 and haven’t been able to find an equivalent in CircleCI 2.0. Is there one?
I posted recently about barriers to enterprise adoption which included this very issue you’ve bought up, however as yet there is no response from the CircleCI folks.
This is a workaround that uses environment variables:
if [ $CIRCLE_PROJECT_USERNAME = ‘Owner’ ] && [ -z $CIRCLE_PR_NUMBER ]; then
fi
$CIRCLE_PROJECT_USERNAME is the name of the owner. However when there is a PR from a forked repo to the original repo, and a PR form the original repo $CIRCLE_PROJECT_USERNAME will have the same value.
To differentiate being triggered from a fork rather than within the original repo, you can check $CIRCLE_PR_NUMBER which will only have a value if its from a forked PR.
2 Likes
I just took about 20 minutes to read through some of the proposed ideas. There certainly are quite a few! I also may have made an incorrect assumption when I said that “the CircleCI folks” hadn’t responded. My boss has asked me to inquire further about this feature specifically. We can live without all of the other enterprise adoption issues I mentioned in my initial post but this one is non-negotiable.
I can draw a straight line from CircleCI implementing this feature to us buying more executors. I currently handle all of the development test runs and deployments to our engineering environment, which warrants us paying for a meager six executors right now. I could also handle deployments directly to staging and production if we could assign the head of QA and the head of Operations the exclusive rights to approve the continuation of workflows respectively.
The head of operations simply won’t let me set up pipelines deploying to staging and production using CircleCI because (currently) any user can manually approve a workflow, allowing it to continue to the deployment job. The final nail in the coffin is that whenever someone approves a workflow this way, there’s no audit trail on the hosted CircleCI environment.
That is just too much for the head of Ops as she is directly responsible for all production deployments and flatly refuses to let me use CircleCI for these deployments. As a consequence our Operations department has set up a custom Jenkins server in-house to deal with deployments to the QA and production environments. This is unfortunate, because I’ve already done all of the legwork required to deploy to those environments and my CircleCI configs work beautifully.
We use github for authentication and while CircleCI as an organization needs to think about all of their possible authentication methods when implementing a feature like this, I know that for our use-case it would be sufficient if the CircleCI administrator could assign one or more github users as owners of a particular workflow job. Only those owners would be allowed to move the job from “on hold” to running.
Implied in my suggestion is a large epic of ACL features that CircleCI is likely already considering or possibly even already implementing. It would make us very happy if we could get all of our CI jobs running in CircleCI so that we wouldn’t have to rely on Jenkins for some and CIrcleCI for others. As I already mentioned, I’m certain we would buy more executors if we could move all of our CI pipelines to CircleCI.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.