Skip to content
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

Feature request: Allow octions not fail on non-2xx response #7

Open
jrencz opened this issue Oct 7, 2020 · 1 comment
Open

Feature request: Allow octions not fail on non-2xx response #7

jrencz opened this issue Oct 7, 2020 · 1 comment

Comments

@jrencz
Copy link

jrencz commented Oct 7, 2020

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):

  • 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@master
    id: find-branch
    with:
        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 output
    if: always() && steps.find-cf.outputs.status != 200
    uses: maxkomarychev/octions/octions/git/create-ref@master
    with:
        token: ${{ github.token }}
        ref: refs/heads/my-branch-name
        sha: ${{ steps.find-default.outputs.sha }}

It would be possible to do just this:

-   name: "Check if branch exists"
    uses: maxkomarychev/octions/octions/git/get-ref@master
    id: find-branch
    with:
        token: ${{ github.token }}
        ref: heads/my-branch-name
        expectedStatuses:
            -   200
            -   404

-   name: "Create branch"
    if: steps.find-cf.outputs.status == 404
    uses: maxkomarychev/octions/octions/git/create-ref@master
    with:
        token: ${{ github.token }}
        ref: refs/heads/my-branch-name
        sha: ${{ 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

@jrencz
Copy link
Author

jrencz commented Oct 7, 2020

What I tried to achieve can be done with continue-on-error: true applied on the step using git/git-ref

Yet still my request is a bit broader than just "not failing on 404" so I'll leave it open

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant