lread / muckabout

General personal mucking about, like using as a test library repo for cljdoc

Testing 123 - GHA triggers

Commit Triggers

Goal: Always run tests once for pushed commit(s).

This should be the case for:

• push to master on this repo [good]

• push to branch on this repo [good]

• push to fork of this repo

• push to PR of this repo

  • from local branch [good]

  • from fork

Currently GHA is building twice on push to PR. Once for PR and once for push.

I’d like to avoid this waste of compute. Also, it is confusing.

By default the pull_request triggers on the following activities: - opened - synchronize - reopened

What if we remove synchronize? Would that do the trick?

It seems to for local branch PR. I no longer see the duplicate trigger on the PR checks: Only 1 for push, no longer any for synchronize.

Tag triggers

Releasing on a git version tag is the strong preference of some folks I work with. I find it much more complex to setup, and there is much more to think about, than triggering from the GitHub UI, but I try to keep an open mind.

Github docs on push trigger: > Runs your workflow when you push a commit or tag.

What we want:

When a new tag is pushed to the master repo, initiate a release flow which is:

• run tests

• then publishes a release

Scenario 1: a user from a fork synch with upstream, this pushes a tag This should not trigger a release workflow.

Scenario 2: the Github push trigger recognizes the tag as a trigger then also a commit as a trigger, this triggers tests to be run twice when a tag is pushed. Can we say: never run tests on a tag But invoke tests from release flow that was triggered by a tag.

So maybe this would to the trick to not invoke tests on new tag: on: push: tags_ignore: "*" for test workflow

In practice I found

on:
  push:
    branches:
      - "**"
    tags:
      - "!**"

To be an incantation that works. Apparently the default is "**" for branches and tags, but if you override one, you need to respecify the other.

For not invoking release workflow from a fork…​ I do not see anything at the workflow level, so the workflow would run…​ But we might be able to skip all jobs via the following on each job in the publish/release workflow:

if: github.repository_owner == 'clj-commons'

On Release we have a commit and a tag

In a tag triggered release flow, we’ll push - a commit that updates some files to the new version, and we’ll have our - our tag

GitHub Actions will see these as 2 separate triggers, even if we try to push atomically. For my current setup, this means that my tests will be invoked twice. Once for the commit push. Once by publish which invokes tests.

Sooo…​ can we skip tests for a release commit push? Not at the workflow level. But we could do something at the job level. We could check the commit message content. For example on pomegranate, the publish workflow commit message looks like this:

publish: apply version 1.2.23

So maybe something like:

if: ${{ !startsWith(github.event.head_commit.message, 'publish:') }}

The test flow will still be run but the jobs would be skipped. I think this would work. Maybe. We still want the tests triggered from the publish flow. I’ll play with this.

Note I orginally had 'publish: ' with a trailing space, but that triggered an error. Don’t know if that’s a yaml thing or a github actions thing.

Ok that did not work. The head commit message is the same after a tag, so…​ the tests invoked by publish are skipped and so the publish is skipped.

So, maybe explicitly allowing tests to run from workflow_call might work. I’ll try that.

Not working, need to debug

Ok, the event_name is push, when I tought it would be workflow_call, so I’m probably not understanding something about workflow calls. Lean on github.ref instead.