-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a provider for scheduled pipelines #81
base: master
Are you sure you want to change the base?
Conversation
It's required to run environment variable tests, so bail if unset.
matches := strings.Split(slug, "/") | ||
|
||
if len(matches) != 3 { | ||
return "", "", "", fmt.Errorf("Splitting project-slug '%s' into vcs/org/project failed", slug) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this error message counters itself. Maybe something along the lines of Extracting vcs, org, and project from project-slug '%s' failed
? As it stands now it seems to imply that it's being split INTO vcs/org/project
rather than the values being extracted
This works structurally mostly like environment variables, but uses schedule IDs as internal IDs. Some hackery has been performed to make organization ID inheritance from provider settings work. It does work correctly for the most part, though local state can get a bit confused if the provider setting gets changed. Explicit organizations on schedules work just fine though. The scheduled actor ID in this is one of several magic IDs that we have at CircleCI, and I can guarantee to remain stable. CRUD operations have been verified to work off the local tree, and import of existing schedules works as well. Some provider-side validation is being performed, though it's much easier to just let the operation fail and print out the API error message, rather than duplicating all validation we perform in the API here. An example here is the project<>schedule-name uniqueness constraint, which is not checked in the provider. Similarly the requirement for either a branch or tag to be set as part of parameters, which is actually due to change soon.
Would love to see support for scheduled pipelines. Any ETA on this? |
On Wed, 31 Aug 2022, at 22:35, Mark Johnson wrote:
Would love to see support for scheduled pipelines. Any ETA on this?
This currently depends on @mrolla. We have been thinking about publishing an official terraform provider as well, but we’re still in a discovery phase on that, so that might take a while.
|
This works structurally mostly like environment variables, but uses
schedule IDs as internal IDs.
Some hackery has been performed to make organization ID inheritance
from provider settings work. It does work correctly for the most part,
though local state can get a bit confused if the provider setting gets
changed. Explicit organizations on schedules work just fine though.
The scheduled actor ID in this is one of several magic IDs that we
have at CircleCI, and I can guarantee to remain stable.
CRUD operations have been verified to work off the local tree, and
import of existing schedules works as well.
Some provider-side validation is being performed, though it's much
easier to just let the operation fail and print out the API error
message, rather than duplicating all validation we perform in the API
here. An example here is the project<>schedule-name uniqueness
constraint, which is not checked in the provider. Similarly the
requirement for either a branch or tag to be set as part of
parameters, which is actually due to change soon.
Fixes #59.