GitHub Actions Manual Trigger / Approvals

Hi all, I’m not entirely sure if this is appropriate or not to self promote here, but my buddy and I built an extremely basic MVP for handling this exact situation, because we wanted this feature as well:

We built it as fast as we could so it’s still very quirky, but we’d love feedback. There’s a contact email on that landing page.


Along the lines of some of the other comments, I’m experimenting with Actions and need a manual trigger for production releases.

While waiting for full internal support with approvals, I’m temporarily using a workflow that triggers on a published release or tag, so every time a release is published, it pushes that release to production, or every time a tag is created that matches a certain syntax, it will push that tagged commit.
This allows us to roll out and roll back production releases, but does not handle approvals.


Y’all; it’s a little disingenuous to purport that this is “solved” when it’s just a link to another conversation from a product manager confirming that GitHub is considering it.

I’m just saying.


I kudo’d this, and I will observe I found this workaround: .  I just tested this and it did work:


How can it be solved when you start considering it? Important feature which was overlooked. This makes the product unusable in production scenarios.


Just want to add my support to this issue. We have a Github action workflow to compile assets, but it’s annoying that it triggers on every push. My perfect setup would allow us to trigger that workflow from a pull request when it’s ready for review.


Adding my support in addition to Kudos’ing this post. The options in Travis CI and Azure DevOps for manual triggering are super useful to trigger builds especially when webhooks occassionally fail.

1 Like

Also “Kudos’ing” this post since it is a sorely missed feature. Unfortunately, as stated by others, marking it as solved probably isn’t helping it to get enough attention by Github. It’s been over 5 months since this simple yet essential feature request has been taken into account by the team.

1 Like

@peterhewat wrote:

It’s been over 5 months since this simple yet essential feature request has been taken into account by the team.

In all fairness, we need to look at it from GitHub’s standpoint as well.

  1. We already know that the GitHub team is not afraid to admit mistakes, and work swiftly to correct them - otherwise, we would have all been still stuck in the dark GitHub Actions v1 (HCL) days.

  2. Implementing this manual trigger thing may not be so trivial. Things that need to be considered:

    - What will be the commit that the action is attached to?

    - What about allowing also manual input of fields - like other build servers.

    - How will this manual trigger look like in the API.

    - And I am sure there are many more things to consider.

I am sure some will agree with me that GitHub Actions has quickly risen to become a great replacement for both CI and CD solutions out there. It is not yet perfect, but it is already better than most others, and 95% feature complete.


I have removed the previously marked solution in hopes that this topic will receive more attention from GitHub. There have been a few decent workarounds in the meantime, but ultimately this is still a huge need to have native functionality in GitHub.


pls github i just want to test my actions without spamming commits and tags and merges and prs and 


I definitely need this to setup my CD production pipeline using Github workflows.

Maybe adding to what was already said before: It would be totally fine for me, if a manual action would trigger a new (dependent) job in a workflow. I suppose it could be more difficult to implement resuming a workflow on a step level, where the current container state has to be saved and restored somehow. This would not be necessary when the manual action triggers a new job.

A sorely missed feature that would greatly help us


Use case: Our scheduled nightly build failed because something external to GitHub changed.  We think we’ve tracked down the root cause and fixed it.  We don’t want to have to wait until the nightly build time comes around again to test it.

I’m thinking there should be a “Retrigger” button attached to each run in the Actions tab.  It could be an option in the “…” drop-down (which currently only contains “View workflow file”).  There should probably also be an equivalent button on the run’s page (the page you get when you click on the run’s workflow name in the list of runs on the Actions tab).

1 Like

I don’t know what else can be done for the GitHub Actions team to take this into account, so I’m spamming this thread saying that this feature is direly needed, especially now when GitLab CI is not longer free for external projects.


FWIW, I used the following somewhat hacky workaround to implement manual triggers: I use issues as my trigger. Here’s my example:

name: Manual Deployment

    types: [opened]

    name: Deployment
    runs-on: ubuntu-latest
    # Only run this deployment if the newly opened issue's title starts with 'DEPLOY project'
    if: startsWith(github.event.issue.title, 'DEPLOY project')

  - name: Checkout project
    uses: actions/checkout@v2.0.0
      repository: myorg/myrepo
      # note here I use the body of the issue to say which tag or branch to pull
      ref: ${{ github.event.issue.body }}
      token: ${{ secrets.GITHUB_TOKEN }}

  ... do all my deployment steps

  - name: Close deployment triggering issue
    uses: actions/github-script@0.9.0
      GITHUB_RUN_ID: ${{github.run_id}}
      github-token: ${{secrets.GITHUB_TOKEN}}
      script: |
        await github.issues.createComment({
          issue_number: context.issue.number,
          owner: context.repo.owner,
          repo: context.repo.repo,
          body: '🚀 Successfully deployed my project in production.'
        await github.issues.addLabels({
          issue_number: context.issue.number,
          owner: context.repo.owner,
          repo: context.repo.repo,
          labels: ['released']
        await github.issues.update({
          issue_number: context.issue.number,
          owner: context.repo.owner,
          repo: context.repo.repo,
          state: 'closed'

The important parts about this are:

  1. You can use the ‘if’ statement at the top to only run particular workflows based on the title of the issue. So think of the issue title as essentially the ‘name’ of the workflow to run.
  2. For me I use the body of the issue to state which branch I want to release. But you can do anything else you want in the issue body and then parse it in your workflow.
  3. You can see at the end where I close the issue upon successful release. You could also do other things if you wanted like add a ‘deployment’ tag to the issue at the top of the workflow if you also use issues for other things in your project.

The reason I don’t mind this too much is because I’m essentially using issues as a request to run a deployment, which my workflow handles, and when all is done successfully my workflow closes the issue, so I have a nice log of all my deployments with issues.


Is there a way to have an extra if condition to check if the issue author has repo write permissions?

This may help you in the meanwhile

1 Like

Nice approach, but I really don’t want any lengthy, hacky, brittle, … workarounds for a basic, much needed feature.


I have not personally tried this, but:

  1. The octokit API has the ability to check the user’s permissions on a given repository:

  2. You should be able to use the github script action, , to call the octokit API (the API client is passed in as the ‘github’ variable to your script’) to check the permissions of the user who created the issue.