Manually pull the complement branch matching the current branch name.

[clokep]

This is akin to matrix-org/pipelines#157, but using GitHub Actions.

[clokep]

I'm fairly certain we cannot use the action here since we need the fallback behavior?

[anoadragon453]

The fallback looks to work from the CI output. From the code it appears the same-named branch stuff should work as well.

As you said, I don't think fallback behaviour is possible with actions/checkout.

[anoadragon453]

Heads up $GITHUB_HEAD_REF is only set for PRs, though I think this is fine as probably will want to test release-* and develop branches against Complement master anyhow.

[clokep]

I saw that, but don't we only run builds for PRs anyway?

There's also $GITHUB_REF, but I don't think that returns the information I need.

[anoadragon453]

If you check the top of the workflow file you'll see that we run it whenever develop or release-* branches are pushed to:

synapse/.github/workflows/tests.yml

Lines 3 to 6 in 2df7196

	on:
	push:
	branches: ["develop", "release-*"]
	pull_request:

[callahad]

It may be cleaner to keep using actions/checkout@v2 here and just do a full clone (fetch-depth: 0) followed by opportunistically trying to git checkout the matching branch?

[clokep]

@anoadragon453 Thanks! I believe I've updated this to take this into account, it now:

1. Uses GITHUB_HEAD_REF if it exists.
2. Falls back to GITHUB_REF (and cuts off a refs/head/ prefix)
3. Falls back to master

[callahad]

A few options here:

• Complement is tiny; cloning the whole history is less than 1 MiB. You could grab the whole history (fetch-depth: 0) and then try to git checkout the target branch, ignoring (and thus staying on master) if that fails.

• You could stick with the wget logic you have, but might be slightly easier to instead try to call git clone --depth 1 --branch $whatever https://github.com/matrix-org/complement; then you don't have to directly muck with wget and tar.

• If you can somehow easily determine whether the branch exists before actually cloning the repo, you could do that in one step and pass it along as the ref argument to the actions/checkouts step as an output. E.g., if a step echoes ::set-output name=branch::$whatever, then in the following steps can access that as ${{ steps.STEP_ID.outputs.branch }}

To find the right reference from either a push or a pull_request you might need to dig into events that trigger workflows, the github context, and default environment variables. E.g., for pull requests you probably want to look at github.head_ref or github.base_ref, but for pushes you probably wantgithub.ref.

All of those are also available as envvars: $GITHUB_HEAD_REF, $GITHUB_BASE_REF, and $GITHUB_REF.

[clokep]

@anoadragon453 Please take another look

[anoadragon453]

lgtm 🙂