Actions Reporting Wrong Branch on Merges

I’m having issues where my actions are firing on the correct branches (based on the filters/triggers in their yaml files) but are showing the incorrect branch as the source

This gave me concern initially when my feature/bug branches were firing off staging deploys, and my develop/master branches were running quality checks meant for feature/bug branches.

When I dug into it, it seems to be tied to merges.  If I merge develop into a feature branch and make a push to the feature branch, actions will report the branch that activated the action as “develop”.  And if I merge a feature branch into develop, the action will report being triggered by “feature/name-goes-here”.

It might be a small edge case, but it effects filtering as well.  Is this a known issue, or should I be doing something to work around this?

You can see it below, the first commit was done directly into develop, and the second triggered when I merged that commit into my feature branch and pushed it

CI-Quality only runs on feature branches, and deploy staging only runs on develop, but both report being generated by develop


Can you share your CI-Quality and deploy-staging workflow yml file here? According to your screenshot, these two workflows are triggered by the same commit. Can you share us how do you make CI-Quality only run on feature branches, and deploy staging only runs on develop?   

CI Quality Workflow

name: CI-Quality

      - '!master'
      - '!develop'
      - '**/*'

    runs-on: ubuntu-latest

      - uses: actions/checkout@v1
      - uses: sergioramos/yarn-actions/install@master
          frozen-lockfile: true
      - name: Setup
        run: yarn global add @angular/cli
      - name: Lint
        run: npm run lint
      - name: Test
        run: npm run test -- --no-watch --no-progress --browsers=ChromeHeadlessCI
      - name: Build
        run: npm run build

deploy-staging workflow

name: deploy-staging

      - 'develop'

    runs-on: ubuntu-latest

      - uses: actions/checkout@v1
      - name: Install Node.js
        uses: actions/setup-node@v1
          node-version: '10.x'
      - name: install packages
        uses: sergioramos/yarn-actions/install@master
          frozen-lockfile: true
      - name: Setup NG-CLI
        run: yarn global add @angular/cli
      - name: Build App
        run: npm run build --prod
      - name: Deploy to Server
        uses: easingthemes/ssh-deploy@v2.0.7
          SSH_PRIVATE_KEY: ${{ secrets.CI_SSH_KEY }}
          ARGS: '-rltgoDzvO --delete'
          SOURCE: 'dist/browser/'
          REMOTE_HOST: ${{ secrets.HOST }}
          REMOTE_USER: ${{ secrets.CI_USER }}
          TARGET: ${{ secrets.STAGING_TARGET }}

Any follow up on this? The action performs as expected but reports the incorrect branch in the UI, which is confusing at the least.

Sounds like the same issue I reported months ago… Slightly disconcerting that this still hasn’t been addressed/fixed…

1 Like

Sorry for the delay response. 

When the branch being merged is a direct descendant of the branch merged into, git simply fast forwards the head pointer, and no merge commit is created. 

merge ff.png

Fast-forward marge will lead to workflow run shows wrong branch . This is an known issue. We have reported it to  the appropriate engineering team.

Does this match your scenario?  

1 Like

Any update here @yanjingzhu?. This makes GitHub actions pretty unusable as a CI, since it also reports the incorrect status badge.

1 Like

I has asked the engineering team again, I am still waiting for their response. Currently, I would suggest you to merge branches to master using Pull Request.  

Another potential workaround would be to use the –no-ff flag when merging until this has been resolved.

With --no-ff, create a merge commit in all cases, even when the merge could instead be resolved as a fast-forward.

This is not ideal as it can result in a lot of unneccesary merge commits being created, however from my testing it does seems to result in the correct branch being displayed.

Any update here? This is a critical feature for us to use github actions effectively as we are using the current branch name to determine the environment to deploy to. Having to remember to merge correctly to deploy to the correct environment is pretty unworkable.



1 Like