Cannot re-run a successful workflow run using the REST API

Hi!

I’ve recently came across what I believe is a limitation of the REST API for managing workflow runs (https://docs.github.com/en/rest/reference/actions#re-run-a-workflow).

I’ve tried re-running a successful workflow run using this endpoint, but I get this message

{
    "message": "This workflow run cannot be rerun",   
    "documentation_url": "https://developer.github.com/v3/actions/workflow_runs/#re-run-a-workflow"
}

I know it’s possible to re-run a workflow run directly from the GitHub UI, but it would be very nice if we could re-run workflows runs from the REST API too. Are there plans to remove this limitation?

3 Likes

Hi @tiagobento
We can re-run a workflow run directly from the GitHub UI, this is a new feature introduced on May 26, 2020. Currently the REST API does not support re-run a successful workflow, so i recommend that you could submit a feedback here. Thanks

1 Like

If the reason is that I cannot rerun a successful one, then at least the message should state that, instead of just saying “cannot”.

2 Likes

Just retested today and unfortunately nothing changed. The message is still the same, and successful Workflow Runs cannot be re-run using the API. I’d really love to hear from GitHub staff why they decided to add that limitation so I can stop thinking about creating a custom Workflow that prevents semantic conflicts when merging PRs.

1 Like

:wave: @tiagobento - Hey! Thanks again for pointing me here from the other topic. I can confirm that it’s not possible to re-run successful workflow runs using the API, though I’m not able to share more about why it was designed this way.

Would you mind submitting this through our official product feedback form so that our product team can track your request? That’s the best place to share requests like these in consideration for future iterations of GitHub features.

As far as your specific use case goes, I am curious to learn more because I think there could be an opportunity to explore alternative approaches in lieu of that feature’s existence.

Let’s say anyone could run a successful workflow run again. Coming back to your example, in what way(s) would that help with preventing semantic conflicts in a pull request?

1 Like

Hi @francisfuzz, thanks for the reply!

Well, actually the whole goal is to re-run my Workflows every time a commit happens on a PR’s target branch. I was able to achieve that by pushing a new commit to that branch using a Maintainer GitHub Token. It’s not an IDEAL solution, since there will be additional empty commits on the PR’s branch, but it works well enough that I’m giving it a try.

Semantic conflicts can happen when two features together cause a faulty behaviour but do not cause conflicts on the text of the code. It’s better explained here: SemanticConflict.

Since on my project we use feature branches, we needed a way to prevent semantic conflicts from happening, and the way I figured would be enough was to automatically re-run the checks on all open PRs targeting a branch when a commit happens on this branch. This way, we won’t ever be merging PRs that are green but would’ve turned red had we re-ran their checks.

Hope that makes sense! Also, I created a GitHub Action to solve that using these empty commits if you want to take a look :wink:

1 Like

Also, sorry, forgot to reply about that. I already sent a message on the “product feedback” channel! :slight_smile:

2 Likes

:wave: Actions Engineer here

There was a bug in our code where re-running a successful workflow via the API did not work. It should now work!

2 Likes