Allow restricted contexts within scheduled pipelines
A
Aaron Gajewski
As of right now, scheduled workflows only work with contexts configured with an "all members" security group. If any other security group is associated with a context, workflows will fail with unauthorized status. It would be great if there were a mechanism to control the scope of a context used within a scheduled workflow.
CCI-I-981
Oran Wilder
Merged in a post:
Select the Schedule workflow to a security group of contexts
T
Takayuki Ito
Currently, circleci can’t make a build with restricted context by scheduled workflows. If a job has a restricted context in schedule workflows, it fails as the UNAUTHORIZED error.To use a context in scheduled workflows, we currently need to set All members into that security group of the context.
CCI-I-1452
Nathan Fish
Just wanted to drop in here and let you all know scheduled workflows is being phased out in favor of scheduled pipelines https://circleci.com/docs/scheduled-pipelines. We are also exploring restricting contexts by project, branch, or tag. Which may be a better fit for solving your need.
B
Brett Rogerson
Or can there be a security group for the Scheduled "user"? That way just that security group can be added to a restricted context without opening the world.
J
James DelReal
Please Add this Feature Request
Roy Robinson
Any update here?
Maxime Belanger
We would like to use that feature for scheduled workflows. Any idea if that will be on the roadmap at some point.
Tom Artale
The workaround listed works great and functions correctly. The feature request would function better, however, for the use case I have:
On a timer, I want to kick off an integration test with a set of parameters at (e.g.) midnight, and with a different set of parameters at (e.g. 12:30). With the workaround, the trigger jobs always appear to succeed, however, the real "success" is recorded in their downstream jobs (which might finish out-of-order). For example, I might see:
pipeline: <project> status: failed workflow: integration-test
pipeline: <project> status: success workflow: integration-test
...
pipeline: <project> status: success workflow: param-2-test
pipeline: <project> status: success workflow: param-1-test
param-1-test and param-2-test are the "trigger" jobs; they're well-named, but they always succeed. I need to go look at the logs to figure out which trigger job goes with which downstream job, since their downstream job has the same name.
Ideally, param-1-test and param-2-test would block, and report success or failure inline, and would have inline logs for troubleshooting
M
Matt Van Stone
I figured out a hack to work around this that uses a scheduled job that runs a CircleCI API call to trigger another job using a CIRCLE_TOKEN variable configured in the project. The scheduled job runs as CircleCI but the job triggered by the API runs with the token so it will have access to the context.
D
Dima Kurilo
+1
N
Nnnnn
Any update on this? It's more than 1 year...
Load More
→