GitHub Actions Manual Trigger / Approvals

@seanfeldman wrote:

having no manual triggers/approvers is a step back

You can have manual approvers if you have a workflow that is attached to the issue_comment type.

For example, the following workflow would run whenever someone would comment “OK to test” in a PR (which is internally seen as a type of issue by GitHub):

name: Run on demand

on:
  issue_comment:
    types: [created, edited]

jobs:
  ondemand:
    runs-on: ubuntu-latest
    if: github.event.comment.body == 'OK to test'

    steps:
      - name: Hello world
        run: echo Hello world, I was run on demand by ${GITHUB_ACTOR}

Additionally, you can also restrict which users are allowed to trigger a workflow this way, by doing checks against the github.event.comment.user.login variable or the GITHUB_ACTOR environment variable.

14 Likes

does this still work for you? i’ve attempted to use this solution and my workflows are not being triggered by posting a comment anywhere - issue or PR, even while not including the “conditional” statement

e.g.:

name: deploy_to_channel_on_demand

on:
  pull_request_review_comment:
    types: [created, edited]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: logging
        run: echo "$GITHUB_REF"

Deliverybot (using github deployments) might be something that solves this issue. I let deliverybot automatically deploy to the staging server, check if everything is working and manually deploy to producting using deliverybot. 

1 Like

This definitely looks promising as a stop-gap, but I would love to see this as native GitHub functionality. Especially if DeliveryBot becomes a paid product once it is out of beta. I couldn’t find any information on the beta / pricing status for DeliveryBot though.

However, it does look like this will meet our requirements for triggering deployments in the meantime. However, from what I can tell, the approval gate use case is still not covered by this tool.

3 Likes

https://deliverybot.dev/docs/guide/6-promotion/
Documentation isn’t great, it also doesn’t work with caching yet, so I’m just using on: push again.

1 Like

Any news regarding this matter?

The manual approval/trigger functionality would be greatly appreciated, and we are sorry that this is lacking from your otherwise great product :slight_smile: Otherwise we would have started moving other build and deploy-pipelines to Github Actions right away!

11 Likes

This is very important.  We need GitLab’s when:manual stuff and it should come with list of approved users

19 Likes

Hi @uladkasach , you have to use issue_comment for posting a Pull Request comment instead of using  pull_request_review_comment  to trigger the workflow when there is a pull request comment. 

name: deploy_to_channel_on_demand

on:
  issue_comment:
    types: [created, edited]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: logging
        run: echo "$GITHUB_REF"
1 Like

As mentioned in https://github.community/t5/GitHub-Actions/repository-dispatch-not-triggering-actions/m-p/33845/highlight/true#M1677, repository_dispatch will only trigger on default (master) branch.

2 Likes

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.

https://github.com/peter-evans/slash-command-dispatch

2 Likes
on:
  issue_comment:
    types: [created, edited]

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

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

2 Likes

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.

2 Likes

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.

2 Likes

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:

https://www.actionspanel.app

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.

7 Likes

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.

6 Likes

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.

49 Likes

I kudo’d this, and I will observe I found this workaround: http://www.btellez.com/posts/triggering-github-actions-with-webhooks.html .  I just tested this and it did work:  https://github.com/edburns/arm-oraclelinux-wls/actions/runs/36535085

6 Likes

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

9 Likes