You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to suggest a feature for octions: let there be a flag which would prevent the oction from reporting failure if it gets a non-2xx response from the API.
Use case:
I'm building a workflow that creates new branch named conventionally (with oction git/create-ref):
use git/get-ref to figure out the head of default branch
use git/create-ref along with the sha from previous step to create new branch on that commit
And it works like a charm until someone creates the same branch some other way (e.g. manually). Then it fails.
So I figured out a way to work this problem around:
use git/get-ref to figure out the head of default branch
use git/get-ref to check if branch I'm trying to create in this workflow run exists or not
if it doesn't exist - use git/create-ref along with the sha from first step to create new branch on that commit
But then it stops on 2nd step when branch doesn't exist because it gets a 404 and gets reported as failure.
This can also be handled by adding if: always() && steps.find-branch.outputs.status != 200 to the third step.
This is rather inconvenient because the job will anyway be marked as failure even if it did what I wanted it to do.
I think a manageable way to go would be to add another input to each oction: expectedStatuses: Array<string> and teach either the request util or each of octions to handle promise failure according to expectedStatuses.
This way Instead of doing this:
- name: "Check if branch exists"uses: maxkomarychev/octions/octions/git/get-ref@masterid: find-branchwith:
token: ${{ github.token }}ref: heads/my-branch-name
- name: "Create branch"# always() needed because either of branch existence checks in previous steps may (and often will) end up in a 404 which is reported as failure.# `!= 200` is here instead of `== 404` because failing oction (due to response with status 404) has no outputif: always() && steps.find-cf.outputs.status != 200uses: maxkomarychev/octions/octions/git/create-ref@masterwith:
token: ${{ github.token }}ref: refs/heads/my-branch-namesha: ${{ steps.find-default.outputs.sha }}
Maybe even 200 could be omitted in this case since it won't make the request util reject the promise it returns but on the other hand if the only expected status is 404 then it's needed not to imply 200 as success and fail if 200 is not on the list.
So: if there's no expectedStatuses let the default value be [200, 201] (maybe other 20x, IDK if they happen) and if the input is fiven then user is explicitly responsible for passing all statuses considered not to be step failure
The text was updated successfully, but these errors were encountered:
Hi!
I'd like to suggest a feature for octions: let there be a flag which would prevent the oction from reporting failure if it gets a non-2xx response from the API.
Use case:
I'm building a workflow that creates new branch named conventionally (with oction git/create-ref):
And it works like a charm until someone creates the same branch some other way (e.g. manually). Then it fails.
So I figured out a way to work this problem around:
sha
from first step to create new branch on that commitBut then it stops on 2nd step when branch doesn't exist because it gets a 404 and gets reported as failure.
This can also be handled by adding
if: always() && steps.find-branch.outputs.status != 200
to the third step.This is rather inconvenient because the job will anyway be marked as failure even if it did what I wanted it to do.
I think a manageable way to go would be to add another
input
to eachoction
:expectedStatuses: Array<string>
and teach either therequest
util or each of octions to handle promise failure according toexpectedStatuses
.This way Instead of doing this:
It would be possible to do just this:
Maybe even
200
could be omitted in this case since it won't make therequest
util reject the promise it returns but on the other hand if the only expected status is 404 then it's needed not to imply 200 as success and fail if 200 is not on the list.So: if there's no
expectedStatuses
let the default value be[200, 201]
(maybe other 20x, IDK if they happen) and if the input is fiven then user is explicitly responsible for passing all statuses considered not to be step failureThe text was updated successfully, but these errors were encountered: