-
Notifications
You must be signed in to change notification settings - Fork 220
fix: pass workflow inputs to success and failure actions #2796
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
base: main
Are you sure you want to change the base?
Changes from 14 commits
5649bbd
7646ee8
c46b071
613e9a3
6b7e963
a41e2aa
e057bd1
f218352
28c0ac1
c3223dc
f3ffcdd
db9eb6b
83a27cb
ffd8f5a
a0470a4
ba3b600
667cf82
af9e4be
8b47027
d0fc683
50a990e
f7deff3
03b6896
c095135
1ff644f
b12d4c7
a58b507
41b8546
ce4f733
a14a54b
a1443a6
e1820da
64f339e
ae9e4c7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| --- | ||
| "@redocly/openapi-core": minor | ||
| "@redocly/respect-core": minor | ||
| "@redocly/cli": minor | ||
| --- | ||
|
|
||
| Added the `spec-parameters-in-by-context` Arazzo rule, which validates that a parameter's `in` field is specified when the parent workflow, step, success action, or failure action does not reference a `workflowId`. Extended success and failure action objects to accept a `parameters` property that maps to workflow inputs. | ||
|
|
||
| Note: because this rule is part of the `spec` ruleset (and is set to `error` in `recommended-strict` and `all`), linting Arazzo descriptions that omit a required `in` field, or that specify `in` when referencing a `workflowId`, may now report new errors. | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,133 @@ | ||
| # spec-parameters-in-by-context | ||
|
|
||
| Requires the `in` field on a parameter to be specified or omitted based on the parent context. | ||
|
|
||
| | Arazzo | Compatibility | | ||
| | ------ | ------------- | | ||
| | 1.x | ✅ | | ||
|
|
||
| ## Design principles | ||
|
|
||
| The Arazzo specification states that when a step, success action, or failure action specifies a `workflowId`, all parameters map to the referenced workflow's inputs and the `in` field MUST NOT be specified. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @harshit078
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I’d also like to clarify whether step-level parameters that don’t include an in field should be merged into the success and failure action objects.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think I got confused on my end a bit but I agree, I assumed that step was included along with success and failure. I read the docs but couldnt open the slack archive as account was not there in that community and I have made changes to only keep to success and failure and revamped my verbiage in arrazo rules and also spec-parmaters context.ts
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here is my question to the community, in case you were not able to join => I will add more details here after the reply. |
||
| In every other case (for example, when a step specifies an `operationId`, `operationPath`, or `x-operation`, or for parameters defined at the workflow level), the `in` field MUST be specified on each parameter. | ||
|
harshit078 marked this conversation as resolved.
Outdated
|
||
|
|
||
| This rule additionally enforces that success and failure action `parameters` are only valid when the action references a `workflowId`. | ||
|
|
||
| ## Configuration | ||
|
|
||
| | Option | Type | Description | | ||
| | -------- | ------ | ------------------------------------------------------- | | ||
| | severity | string | Possible values: `off`, `warn`, `error`. Default `off`. | | ||
|
|
||
| An example configuration: | ||
|
|
||
| ```yaml | ||
| rules: | ||
| spec-parameters-in-by-context: error | ||
| ``` | ||
|
|
||
| ## Examples | ||
|
|
||
| Given the following configuration: | ||
|
|
||
| ```yaml | ||
| rules: | ||
| spec-parameters-in-by-context: error | ||
| ``` | ||
|
|
||
| Example of a **correct** step referencing an `operationId` (each parameter declares `in`): | ||
|
|
||
| ```yaml | ||
| # Correct example - operationId | ||
| workflows: | ||
| - workflowId: get-museum-hours | ||
| steps: | ||
| - stepId: list-hours | ||
| operationId: listMuseumHours | ||
| parameters: | ||
| - in: query | ||
| name: startDate | ||
| value: '2024-01-01' | ||
| ``` | ||
|
|
||
| Example of a **correct** step referencing a `workflowId` (parameters map to workflow inputs, no `in` field): | ||
|
|
||
| ```yaml | ||
| # Correct example - workflowId | ||
| workflows: | ||
| - workflowId: buy-tickets | ||
| steps: | ||
| - stepId: reuse-hours-workflow | ||
| workflowId: get-museum-hours | ||
| parameters: | ||
| - name: startDate | ||
| value: '2024-01-01' | ||
| ``` | ||
|
|
||
| Example of a **correct** success action transferring to another workflow with mapped parameters: | ||
|
|
||
| ```yaml | ||
| # Correct example - success action | ||
| workflows: | ||
| - workflowId: buy-tickets | ||
| steps: | ||
| - stepId: purchase | ||
| operationId: createTicket | ||
| onSuccess: | ||
| - name: continue-to-hours | ||
| type: goto | ||
| workflowId: get-museum-hours | ||
| parameters: | ||
| - name: startDate | ||
| value: '2024-01-01' | ||
| ``` | ||
|
|
||
| Example of an **incorrect** step referencing a `workflowId` while declaring `in` on a parameter: | ||
|
|
||
| ```yaml | ||
| # Incorrect example - workflowId with `in` | ||
| workflows: | ||
| - workflowId: buy-tickets | ||
| steps: | ||
| - stepId: reuse-hours-workflow | ||
| workflowId: get-museum-hours | ||
| parameters: | ||
| - in: query | ||
| name: startDate | ||
| value: '2024-01-01' | ||
| ``` | ||
|
|
||
| Example of an **incorrect** step referencing an `operationId` while omitting `in`: | ||
|
|
||
| ```yaml | ||
| # Incorrect example - operationId without `in` | ||
| workflows: | ||
| - workflowId: get-museum-hours | ||
| steps: | ||
| - stepId: list-hours | ||
| operationId: listMuseumHours | ||
| parameters: | ||
| - name: startDate | ||
| value: '2024-01-01' | ||
| ``` | ||
|
|
||
| Example of an **incorrect** success action defining `parameters` without referencing a `workflowId`: | ||
|
|
||
| ```yaml | ||
| # Incorrect example - action without workflowId | ||
| workflows: | ||
| - workflowId: buy-tickets | ||
| steps: | ||
| - stepId: purchase | ||
| operationId: createTicket | ||
| onSuccess: | ||
| - name: end-with-params | ||
| type: end | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems like parameters also won't make sense when action type is
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes I agree, I'll remove it. it is redundant to have it. |
||
| parameters: | ||
| - name: startDate | ||
| value: '2024-01-01' | ||
| ``` | ||
|
|
||
| ## Resources | ||
|
|
||
| - [Rule source](https://github.com/Redocly/redocly-cli/blob/main/packages/core/src/rules/arazzo/spec-parameters-in-by-context.ts) | ||
Uh oh!
There was an error while loading. Please reload this page.