Help
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Copilot Lvl 3
Message 1 of 6

New event type for Workflows: Merge

Solved! Go to Solution.

I've got a lot of private packages I work with and I've built out a automated package manager publish that iterates the version number after publish then updates the master branch. This is for like a docker image then it'll update the tag. This is workflow is a problem though because it enters an infinite loop. When my workflow which is looking for:

name: pusher-step
on: 
  push:
    branches:
      - master

As you can probably guess, after the publish happens we update the master branchs tags through a private action.... Which as you can guess, causes another run of this workflow.... rinse and repeat.

 

 

So, proposal:
Create a new event type: merge
This event type will run once on merge, but not push.

 

5 Replies
Highlighted
Copilot Lvl 3
Message 2 of 6

Re: New event type for Workflows: Merge

With a sober mind, what I meant to state was:

I have private packages & images hosted with GitHub. I've tried to build out the CD part of the CI/CD where after my PR is merged I trigger a publish and then update the tags & refs to the main branch. This causes an infinite loop because the workflow is triggered on a push to the master branch...

 

Proposal:
Create a new event type: `merge`

This event is specific to a PR being merged, and will run once. It's not associated to push.

Highlighted
GitHub Staff
Message 3 of 6

Re: New event type for Workflows: Merge

You could do this today with the something like

 

on:
  pull_request:
    types: [closed]

And then put a conditional on the job to see if the pull request was merged by checking the event payload.

Highlighted
Copilot Lvl 3
Message 4 of 6

Re: New event type for Workflows: Merge

So the action would contain a check to see if the PR was merged? How would the pull request merged part work I'm not sure I understand that? What event payload would I have to check?

 

The way my workflow runs: on closed run my private action. The action then publishes/builds image then updates the repo. I'm not sure what payload would be passed to the action that I could check. Is there a way to do something like that in the action.yml?

I originally thought about using the closed, but the issue with that is (I'm sure you've guessed it) that the PRs could be closed and not merged.

Also, question for the pondering mind:

Which is the better solution to implement?
1) For every repository exists where one would want to do a CD solution; you would have to implement a two step process. A workflow that listens for pull request closed, followed by some further filter to inspect the payload of event to ensure it was merged.
2) As all the other successful CD providers have done create a `merged` event that can be listened to specifically

as reference:
Gitlab's merged is called deploy

Highlighted
Copilot Lvl 3
Message 5 of 6

Re: New event type for Workflows: Merge

Comment not found: Old comment deleted to merge into single comment.

Highlighted
Solution
Copilot Lvl 3
Message 6 of 6

Re: New event type for Workflows: Merge

If anyone stumbles onto this, the solution is to do something like:

name: Node-CI-PROD
on: 
  pull_request:
    types: [closed]
    branches:
      - master

jobs:
  build:
    name: prd
    runs-on: ubuntu-16.04

    strategy:
      matrix:
        node-version: [10.x]

    steps:
      - name: use_node  
        uses: actions/setup-node@master
        with:
          node-version: ${{ matrix.node-version }}
      - testing the merged
        if:  github.event.pull_request.merged == true
        run: |
          node -e "console.log('HELLO WORLD!');"