GitHub Actions Manual Trigger / Approvals

It doesn’t work for the branch in which I added workflow includes this trick (the workflow isn’t in master), action doesn’t trigger.

This is my “ChatOps” for GitHub Actions solution. It may be suitable for some use cases.

    types: [created, edited]

    name: Build
    runs-on: macos-latest
    if: github.event.comment.body == 'build ios'
      - name: Fetch issue info
        uses: octokit/request-action@v2.x
        id: get_issue_info
          route: GET ${{ github.event.issue.url }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: Parse issue info
        id: parse_issue_info
        uses: gr2m/get-json-paths-action@v1.x
          json: ${{ }}
          pull_request_url: "pull_request.url"
      - name: Fetch PR info
        uses: octokit/request-action@v2.x
        id: get_pr_ref
          route: GET ${{ steps.parse_issue_info.outputs.pull_request_url }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: Parse PR info
        id: parse_pr_info
        uses: gr2m/get-json-paths-action@v1.x
          json: ${{ }}
          ref: "head.ref"
      - uses: actions/checkout@v1
          ref: ${{ steps.parse_pr_info.outputs.ref }}

This solution extracts the branch from the associated PR in which the comment was entered.


thank you for your help and your assistant appreciate all the things I should have done for me it looks tough I’m trying to achieve thank you and God bless

1 Like

Any news about this very important future?

The ability to rollback to a given tag or commit is a critical feature for any enterprise product IMHO.


All of these solutions does not satisfy the absolute need of feature available from GitHub itself.

Not only gateing we should be able to setup release pipeline separately from build pipeline.

Currently the “build” step and “release” step should be in the same action.yml file, boz they share the artifacts and we can not spit them.

This kind of tight coupling is limiting the ability to release different artifacts to different environments.

Most of the time “Canary” environment move faster than “Insider/Staging” and staging move fater than “production”.

The github action in the current form is best fit for someone who follows “commit to straight prod” paradigm.


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