-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Enable workflow validation against JSON spec #13125
Conversation
|
||
actions: | ||
- id: "an-action" | ||
- id: "an-action@1" | ||
config: {} |
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.
IRL workflow scenarios seem to always have a config, hence why this is a required field rather than a nullable one. It does look at little odd when we're using fixture workflows though
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.
It does look at little odd when we're using fixture workflows though
Could this fixture be made more realistic, then?
@@ -23,15 +23,15 @@ import ( | |||
|
|||
const hardcodedWorkflow = ` | |||
triggers: | |||
- id: "mercury-trigger" | |||
- id: "mercury-trigger@1" |
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.
So we have some version redundancy/conflict now that the ID contains the version. The capability info struct needs to be refactored such that the version is derived from the ID rather than being a separate entity.
This is tracked in:
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.
@HenryNguyen5 I think that means that the hardcoded workflow will be broken if we merge this PR right? Since the spec will require versions, but that won't have entries in the capability registry
Is there anything we can do to ensure that these changes don't break things in the meantime?
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.
You're talking about staging, right?
I think the non-breaking change would be to update the staging env such that the id entries in staging contain the version too. WDYT?
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.
Yes, but I'm also talking about the various CapabilityInfo objects kicking around. By modifying this without modifying those, aren't we ensuring that we won't be able to fetch existing capabilities (since new workflows will fail validation without a version?)
I would love for us to make these changes in a way that maintains functionality -- my main concern here is ensuring that what is on develop is always in a working state.
Quality Gate passedIssues Measures |
557ef06
to
416f8d0
Compare
No description provided.