Add a provider for scheduled pipelines #81
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It's required to run environment variable tests, so bail if unset.
M1kep
reviewed
May 23, 2022
| 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.
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.
|
…toring Add Snyk scanning & monitoring
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.