Ignoring some errors

[Stefan Lörwald]

Hi,

I'm designing a workflow where I create a new repository. I'm using octokit/request-action to make the request:

    steps:
      - uses: octokit/request-action@v2.x
        id: create
        with:
          route: POST /orgs/{org}/repos
          org: my-org
          accept: 'application/vnd.github.v3+json'
          name: repo-name
          description: This is an automatically generated repo. Ignore me.
          visibility: private
        env:
          GITHUB_TOKEN: ${{ secrets.GH_PAT }}

This works fine, but there are situations where the repo already exists. In that case the above will return the error Repository creation failed.: {"resource":"Repository","code":"custom","field":"name","message":"name already exists on this account"}. Is there some way to ignore this error such that dependent jobs continue to execute? After all, the goal of having a repo with that name is fulfilled.

Thanks
Stefan

[Gregor Martynus]

You could send a request first to check if the repo exists, then only create it if it doesn't? There are expressions for GitHub Actions step that will continue the workflow if a step has an error. And you could run the step to create the repository only if the previous step to check if the repo exists failed

[Stefan Lörwald]

True, I am aware of the situations in which the repo (should) exists, so I can run this step conditionally, which resolves the issue.

Technically, that can be a race condition though: if I test for "repo exists" first, and I get false back, it doesn't guarantee at all that the repo creation will not fail, because the repo might be created just in between.

[Gregor Martynus]

handling the possible race condition is out of scope of this action. You could use https://github.com/actions/github-script to a bit of custom code instead?

[Stefan Lörwald]

I disagree: avoiding the race condition is as easy as executing the action and ignoring the error, if the error is because of existing repo. The workaround to check beforehand is only introducing the race condition because the error cannot be ignored in this action.

[Gregor Martynus]

I could set outputs.error in case of an error (to an @octokit/request-error object), then you could check outputs.error.status to decide whether you want to continue despite the error or not.

[Stefan Lörwald]

That sounds like a good resolution. I think it would be a great addition to this action, if it always sets the error output and optionally ignores a non-zero exit code (to avoid GH reporting that step as failed).

[Gregor Martynus]

🎉 This issue has been resolved in version 2.1.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀