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

Ability to re-run/trigger a GitHub Actions Workflow #3113

Closed
notlmn opened this issue May 20, 2020 · 12 comments
Closed

Ability to re-run/trigger a GitHub Actions Workflow #3113

notlmn opened this issue May 20, 2020 · 12 comments

Comments

@notlmn
Copy link
Contributor

notlmn commented May 20, 2020

Explanation

GitHub Actions API has the ability to re-run a specific workflow, but the GitHub UI doesn't have any option to re-run a workflow unless the workflow has some failed jobs inside it.

(Well, GitHub doesn't exactly let you re-run the entire workflow, only specific failed jobs inside it, which is no exposed in their API).

The feature adds a button that should:

  • be available on workflow (example), preferably beside "create status badge" dropdown.
  • be enabled if the workflow is is not running.
  • be disabled if the workflow is already running.

Sample screenshots

Re-running workflows

image

Triggering new workflows

image

How can this be used?

  • Testing pull requests.
  • Triggering manual builds for publishing extensions, that we used to do on Travis for hotfixes.

People do seem to need this for their own reasons (GH forum).

Existing alternatives

These "tricks" work, but they do not work on specific run that we want to re-run or require adding new actions to handle them.

Things I'm not sure about

There are basically two "types" or "ways" of running a workflow (if you could call them that)

  1. "re-running" an existing workflow (which is previously failed or has passed), from first screenshot above
  2. "creating" a new workflow run, that is done on a per-branch basis, this is related to Travis' "Trigger Build", second screenshot above.

Option 1 can be easily done, now sure how we can tackle option 2 (which also may not be possible).

@fregante
Copy link
Member

fregante commented May 20, 2020

This is impossible, you can’t run random workflows like that, they have to be pre-setup with those specific listeners.

The only thing possible would be if you’re referring to running OUR ci, not as a feature of refined GitHub.

Adding empty commits isn’t great either way.

@notlmn
Copy link
Contributor Author

notlmn commented May 20, 2020

This is impossible, you can’t run random workflows like that, they have to be pre-setup with those specific listeners.

I'm assuming by me saying "creating a new workflow run" you are thinking of creating new workflow file, with a custom event, jobs and stuff. Yes, that's impossible.

What I'm referring to is a way to trigger a workflow is already configured by the user in the repo, let's say like "Deployment" which they would want to trigger on a specific branch. Feels like I'm explaining Travis' "Trigger Build" feature, but for a specific workflow that the user already has in their repo.

I understand that this might not be possible, but was just brainstorming that idea as it is similar to my actual feature request being able to re-run an already run workflow (example), using the API GitHub provides.


The only thing possible would be if you’re referring to running OUR ci, not as a feature of refined GitHub.

I'm referring to the feature that is actually possible using GH API be added as a feature of RGH.

@fregante fregante added the impossible Features requests that are impossible or impractical to implement label May 20, 2020
@fregante
Copy link
Member

Indeed that’s not possible.

A workflow only runs after the events specified in the workflow itself.

For most repos, where the events are on: push, the only way to trigger it is to push a commit, unsurprisingly. That can’t be worked around by us and, as I said, pushing a whole new (empty) commit for this is a no-go.

Users of each repos can configure their workflows to run one of the solutions you suggested, but RGH can’t.

@fregante
Copy link
Member

fregante commented May 20, 2020

... at least officially. Can you try hacking the “Re-run all jobs” to work on any run?

Edit: tried, GitHub responds with "What‽"

@notlmn
Copy link
Contributor Author

notlmn commented May 21, 2020

Can you try hacking the “Re-run all jobs” to work on any run?

There is an API for that, as mentioned above.

ezgif com-gif-maker


Edit: tried, GitHub responds with "What‽"

How were you trying to do that?

@fregante
Copy link
Member

There is an API for that, as mentioned above.

Like GitHub’s own UI, it only works if the run failed, like in your demo. Otherwise you get a 403

This is what happens when I try to rerun the latest (successful) workflow run on this repo.

@fregante
Copy link
Member

How were you trying to do that?

I found a failed run’s “Re-run all jobs” form, changed its URL to use a different run id, and submitted it. It failed either because their once is linked to the run or because the backend has the same limitation: only rerun failed runs.

@notlmn
Copy link
Contributor Author

notlmn commented May 21, 2020

or because the backend has the same limitation: only rerun failed runs.

That's a bummer!

@notlmn notlmn closed this as completed May 21, 2020
@notlmn
Copy link
Contributor Author

notlmn commented May 26, 2020

https://github.blog/changelog/2020-05-26-github-actions-re-run-successful-jobs/

@fregante fregante removed the impossible Features requests that are impossible or impractical to implement label May 26, 2020
@notlmn
Copy link
Contributor Author

notlmn commented Jul 7, 2020

@fregante
Copy link
Member

fregante commented Jul 7, 2020

Awesome! Can you open an issue on your repo to add manual deployment?

@notlmn
Copy link
Contributor Author

notlmn commented Jul 7, 2020

Awesome! Can you open an issue on your repo to add manual deployment?

fregante/browser-extension-template#32

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

No branches or pull requests

2 participants