KINTO Tech Blog
PlatformEngineering

Summarizing the Launch Timing of GitHub Actions Workflows

Cover Image for Summarizing the Launch Timing of GitHub Actions Workflows

Introduction

Hello. I am Shimamura from the Platform Groups’ Platform Engineering team. I am responsible for the development, operation, and deployment of tools based on platform engineering thinking.

This is the first technical article of the KINTO Technologies Advent Calendar 2023

GitHub Actions is a CICD tool in
GitHub. You probably use Push and Manual trigger (WorkFlow_dispatch) often, but do you sometimes get confused when this is enabled or working?

I do. I often have to ask my team members to refresh my memory.

In this article, I will organize my thoughts on this.

Background

I want to summarize what would happen for the trigger events below.

  • on.push
  • on.workflow_dispatch

Test Preparation

Cases

on.push

  • Does it run even without merging the original workflow to the default(main) branch?
  • What if I change the branch that is pushed to after merging the original workflow to the default(main) branch?
  • Are other branches affected when pushing to the branch?

on.workflow_dispatch

  • Does it run even without merging the original workflow to the default(main) branch?
  • If I create a new branch, edit the workflow, and push it to the branch after merging, will the changes be applied?

Basic code (echo.yaml)

echo.yaml
name: "TestWorkFlow"

on:
  push:
    branches:
      - main
      - 'test/**'
  workflow_dispatch:

jobs:
  TestWorkflow:
    name: "TestWorkFLow Echo"
    runs-on: ubuntu-latest
    steps:
    - name: Echo Branch
      run: |
        echo "Branch:${{ GITHUB_REF_NAME }}"

Summary of the results

Here are the results in one picture.
result

Details

on.push

  • Even if you don't merge it, it runs whenever you push if the following conditions are met:
    • There are no syntax errors (although it will be shown as Fail if there is a syntax error)
    • The conditions of the pushed branch match those of the workflow's on.push branch
  • Even if you leave on.push.branches as test/** and create a branch with "feature/trigger-test" and push it, it does not run
    • If you change on.push.branches to "feature/xx" and push, the feature/trigger-test workflow runs
  • Behavior when two of the following branches exist:
    • test/trigger-test with on.push.branches filter set as “feature/xx”
    • feature/another-trigger with on.push.branches filter set as ”test/xx”
      • Even if you fix something and push it with trigger-test, the feature/another-trigger workflow does not work
      • Even if you fix something and push with feature/another-trigger, the trigger-test workflow does not work
  • The "on"-type parameters looks at the contents of the file in the branch where it occurred and determines whether to launch

on.workflow_dispatch

  • If there are no files in the default branch, the manual run button is not displayed
  • After merging, we create a new branch and add Inputs
    • When launching manually, we can select branches, so we select the new branch and increase inputs
  • Just like when pushing, it shows the contents of the file in the branch

Verification

on.push

Does it run even without merging the original workflow to the default(main) branch?

First, create echo.yml and push.
vscode

junpei@:test-trigger-repo$ git add .github/
junpei@:test-trigger-repo$ git commit -m "create workflow"
[test/trigger-test 43be511] create workflow
 1 file changed, 17 insertions(+)
 create mode 100644 .github/workflows/echo.yml
junpei@:test-trigger-repo$ git push origin test/trigger-test
・・・・・・
Total 5 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: Create a pull request for 'test/trigger-test' on GitHub by visiting:
remote:      https://github.com/junpeishimamura-kinto/test-trigger-repo/pull/new/test/trigger-test
remote:
To https://github.com/junpeishimamura-kinto/test-trigger-repo.git
 * [new branch]      test/trigger-test -> test/trigger-test
junpei@:test-trigger-repo$

Main branch

I thought it would not work the way I assumed it would, but the Action runs.

Running the GitHub Action

What if I change the branch that is pushed to after merging the original workflow to the default(main) branch?

Naturally, even if you create "feature/trigger-test" from the main branch with the trigger condition "test/**", it will not run.

If you revise the files in the workflow and modify it as "feature/trigger-test", then push it, it will run.

echo.yaml
on:
  push:
    branches:
      - main
      - 'feature/**'
  workflow_dispatch:

Is There Any Effect on Other Branches

From the main branch, create "test/trigger-test-other-branch" and create a suitable file. Then push with the following, and it will run.

vscode

junpei@:test-trigger-repo$ git status
On branch test/trigger-test-other-branch
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        test-branch.txt

nothing added to commit but untracked files present (use "git add" to track)
junpei@:test-trigger-repo$ git add test-branch.txt
junpei@:test-trigger-repo$ git commit -m "create test-branch.txt"
git p[test/trigger-test-other-branch 0c738b1] create test-branch.txt
 1 file changed, 1 insertion(+)
 create mode 100644 test-branch.txt
junpei@:test-trigger-repo$ git push origin test/trigger-test-other-branch
・・・・
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: Create a pull request for 'test/trigger-test-other-branch' on GitHub by visiting:
remote:      https://github.com/junpeishimamura-kinto/test-trigger-repo/pull/new/test/trigger-test-other-branch
remote:
To https://github.com/junpeishimamura-kinto/test-trigger-repo.git
 * [new branch]      test/trigger-test-other-branch -> test/trigger-test-other-branch
junpei@:test-trigger-repo$

The workflow file in this case is "test/trigger-test-other-branch" and is not Main.
Running the GitHub Action

Additionally, create a new branch called "feature/another-trigger" from the main branch. We keep the branch "feature/trigger-test" that was verified earlier.

junpei@:test-trigger-repo$ git switch -c feature/another-trigger
Switched to a new branch 'feature/another-trigger'
junpei@:test-trigger-repo$ git branch
* feature/another-trigger
  feature/trigger-test
  Main
  test/trigger-test
  test/trigger-test-other-branch
junpei@:test-trigger-repo$

Make a file, and without changing the "feature/another-trigger" workflow conditions, push as (test/**).

When Actions don’t run

Then you’ll see that the Actions, does in fact, not run. The point seems to be whether it meets the workflow conditions in the operation branch.

on.workflow_dispatch

Does it run even without merging the original workflow to the default(main) branch?

What can you do manually without merging the echo.yml created with on.push into the main branch?

There is No Button

Even if workflow_dispatch is in Yaml, the button is not displayed and cannot be moved unless it is merged into the main branch. Since there is no button, it seems that it is not possible to switch the specified branch.

If I create a new branch, edit the workflow, and push it to the branch after merging, will the changes be applied?

I use it often, so I don’t need to check it. The changes are reflected as I expected. If you press the RunWorkflow button, you can specify the branch, so if you select it, you can run the one that shows the changes.

Impressions

For on.push, all of the items work as expected except “Does it run even without merging the original workflow to the default(main) branch?” Pushing alone does not register as GitHub Actions. Because it was recognized when it is registered after merging, I fortunately discovered that it was recognized incorrectly after adjusting it. I used the branch condition, but since Tag has the same event-driven type, I think it will behave the same way.

I wanted to compare it with Circle.CI and other CICD services, but I think it will work the same way. Unlike GitHub Actions, SaaS-based CICD tools are event-driven and hold back the source code. I think it judges what is in the branch where the event occurred.

Conclusion

The Platform Engineering team manages and develops tools used internally across the organization. We adopt what other teams in the Platform group have created and based on the company's requirements, we either build from the ground up or migrate components as needed. I also tried it with CDK and started programming with tools other than Managed Service. If you are interested in any of these activities or would like to hear from us, please feel free to contact us.

Facebook

関連記事 | Related Posts

masahi
masahi
Cover Image for Reduce Leftover PRs! GitHub Actions Workflow Recommendations

Reduce Leftover PRs! GitHub Actions Workflow Recommendations

masahi
masahi
Cover Image for 残り続けるPRを減らす!GitHub Actionsワークフローのすすめ

残り続けるPRを減らす!GitHub Actionsワークフローのすすめ

Cover Image for GitHubActions+ECSでBlueGreenDeploymentを実装するお話

GitHubActions+ECSでBlueGreenDeploymentを実装するお話

Taka
Taka
Cover Image for プラットフォームグループのご紹介

プラットフォームグループのご紹介

Cover Image for AWSサーバレスアーキテクチャをMonorepoツール - Nxとterraformで構築してみた!

AWSサーバレスアーキテクチャをMonorepoツール - Nxとterraformで構築してみた!

Atsushi KANAYA
Atsushi KANAYA
Cover Image for JIRAとGitHub Actionsを活用した複数環境へのデプロイトレーサビリティ向上の取り組み

JIRAとGitHub Actionsを活用した複数環境へのデプロイトレーサビリティ向上の取り組み

We are hiring!

【プラットフォームエンジニア】プラットフォームG/東京・大阪

プラットフォームグループについてAWS を中心とするインフラ上で稼働するアプリケーション運用改善のサポートを担当しています。

【スクラッチ開発エンジニア】プラットフォームG/東京・大阪

プラットフォームグループについてAWS を中心とするインフラ上で稼働するアプリケーション運用改善のサポートを担当しています。