GitHub Actions Manual Trigger / Approvals

Are there any news on this or is there a action available to have this functionality?

If GitHub Actions is going to compete with GitLab and Jenkins and everyone else, it needs this feature. It’s extremely helpful for certain types of workflows.

This is a really useful feature for approving changes to infrastructure pipelines, canary deployments and more.

Hey all! It’s been a while, but as we’re doing our Actions AMA, we were going over the board and found this discussion languishing.

This functionality has launched!! :tada:

Check it out:

2 Likes

Manual triggers are great, but they’re only half of what this discussion is about. Many of us are still looking for manual approvals within workflows. Environments accomplish this (in a roundabout and somewhat confusing way), but they’re limited to specific repositories. For example, they’re not available to private repositories on a Pro plan.

6 Likes

Environments look like they could be a good solution. I have the same problem as a few others have reported in that they aren’t available for private repos in any of the orgs that I belong to. It would be nice to see this available to plans other than Enterprise.

I don’t know why no one’s mentioned this, but the original post is about manual triggering, which has been part of github actions for a long time now, and building a new workflow file will even add this for you by default:

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run. 
on:
  # Triggers the workflow on push or pull request events
  # but only for the master branch
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

[...]

So: just add workflow_dispatch: to your yml file and you’re done, you can now run this action whenever you want by manually triggering it the “actions” section of your repo.

It can also can take a fair number of yml “arguments”, but none are required if you just want the ability to manually trigger a run.

Similary, manual approval has been part of the PR review process since PR reviews and branch protection was added, so the features originally request most definitely already work. Everyone else just seem to have tacked their own additional feature request on top: remember that if your feature request is similar, but not the same, you definitely want a separate post instead. Especially because that way others can find it and comment on it because it’s identical to what they would like to see.

That’s for manually running the entire workflow. What folks are looking for is to be able to manually trigger a STEP within the workflow. For example, on git tag you auto deploy to env1, within that workflow there are two other steps but are not automatically run. As a user, you would then click on that step and choose “run” and that would trigger the step to deploy to env2, and then same thing for env3 etc.

No. Scroll back up to the very first post, which is a feature request for manually triggering a workflow execution. To quote:

Feature Request: GitHub Actions Manual Trigger / Approvals

As far as I can tell, there is no way to manually trigger a workflow execution. If there is, how is it done?

If not, I would like to request an additional event trigger called “manual” that would allow one to arbitrarily trigger an exeuction from the Actions UI within GitHub.

That is entirely possible, and has been for a while, and the issue as posted got resolved ever since.

If you have different wants: file a new feature request. Although running a single step within a workflow, without any of the other steps around it, is pretty meaningless. That step will depend on every step before it, and you’d need too run all of those, too. And if it doesn’t, then there’s nothing stopping you from creating a .yml file for that step so it is a workflow that you can trigger like any other, because that step is not just “a step”, it’s a full action in and of itself, even if it’s also a useful step inside a larger workflow.

1 Like

You could use different jobs (with needs dependencies) for this and then use environment approvals to guard their execution.

Any update from GitHub on having this officially supported and integrated into the UI like GitLab has?