GitHub Actions Samples

My samples about GitHub Actions that I learned in multiple customer projects.

You can find the official documentation on GitHub Actions here: https://docs.github.com/en/actions/learn-github-actions

Introduction

I'm a big fan of GitHub Actions because they are easy to develop and helps very much in automation almost everything.

My Tipps & Tricks

1. Generate better outputs in logs

Some bash scripts can generate a lot of valuable output, or a loooooong list to scroll down to find the right information. During some projects I learnt some helpful tricks, that I want to share here with you.

steps:
      - shell: bash
        run: |
          echo "# Results" >> $GITHUB_STEP_SUMMARY

          echo "::group::My very long list"
          echo "Log output of execution"
          for i in {1..100}
          do
            echo "Log $i"
          done
          echo "::endgroup::"

          echo "::group::My title 2"
          echo "Inside group"
          echo "Inside group"
          echo "::add-mask::Mona The Octocat"
          echo "Inside group"
          echo "::endgroup::"

The output will look like:

If required you can expanded the list:

2. Add outputs to the summary page

I was reading the logs of each step to check if something was successful or for some outputs during some tasks.

Then I just learned that you can generate some extra entries for the summary page of your workflow.

jobs:
  prepare-job:
    runs-on: ubuntu-latest
    name: Prepare
    steps:
        # Writing into step summary
        echo "New resource group created with name ABC" >> $GITHUB_STEP_SUMMARY

        echo ":rocket: Preparation successful" >> $GITHUB_STEP_SUMMARY
        echo "| Key | Value |" >> $GITHUB_STEP_SUMMARY
        echo "| --- | ----- |" >> $GITHUB_STEP_SUMMARY
        echo "| A   | 'red' |" >> $GITHUB_STEP_SUMMARY
        echo "| B   | 42    |" >> $GITHUB_STEP_SUMMARY
        echo "| C   | 3.141 |" >> $GITHUB_STEP_SUMMARY

This will result to this output on the summary page, as soon as the step is done.

3. Use artifacts for outputs and inputs

Not new, but extrem helpful in finding issues, or get access to remote generated content. Just create some files, and upload them as artifacts. You can download them easily in other jobs in the same workflow. This makes sense if you build something on linux for example, but need it on windows in a later step, for example.

steps:

  - id: generate-log-file
    shell: bash
    run: |
        for i in {1..100}
        do
        echo "Log $i" > log.txt
        done

  - id: upload-log-file
    use:  uses: actions/upload-artifact@v3
    with:
        name: log.txt
        path: log.txt

4. Trigger manually on demand and use inputs

GitHub Actions are very dynamic and can be configured by input variables that you can use inside the logic.

You can define to run the workflow manually on GitHub with the workflow_dispatch trigger:

name: Output Demo
on:
  workflow_dispatch:
    inputs:
      username:
        description: "The name of the user"
        default: "Oliver"
        required: true

In later steps you can access those inputs very simple with the followin snippet:

echo "Hello ${{ inputs.username }}"

5. One line for summary output and logging output

If you want to output some information on the summary page and also in the classic logging, you can use the following trick.

- name: Duplicate outputs in log and summary
  run: |
    # 2 lines for ouput in logging and in summary
    echo "You want to output this in the logs and summary"
    echo "You want to output this in the logs and summary" >> $GITHUB_STEP_SUMMARY

    # 1 line for output and summary
    echo "You want to output this in the logs and summary" | tee -a $GITHUB_STEP_SUMMARY

The tee command allows us to print something and take this as an input to some other "outputs" like files or env vars. The good thing about tee is, that you can use multiple outputs in one line:

tee -a myfile.txt myotherfile.txt $GITHUB_STEP_SUMMARY

Summary

After applying some of my favorite tricks the summary page looks like this:

Coming next:

Test workflows in a branch
Build Re-usable components
Good practices for naming inputs and environment vars
Parallel execution
Write an az cli like action
Context
add linting but only for added/changed files