Releasing a new version will not post to twitter on GH-Actions

[nils-a]

I experienced this error (no twitter message sent, when it should be) when releasing test-rider using Cake.IntelliJ.Recipe (see the ubuntu run, there). I started analyzing for https://github.com/nils-a/Cake.IntelliJ.Recipe/issues/14.

While analyzing, I came across this in the logs:

BranchType: Unknown

which explains that the post was not made: build.cake sends all messages only for BranchType.Master (or BranchType.Release or BranchType.HotFix when BuildParameters.ShouldNotifyBetaReleases is set.)

I compared to Cake.7zip and Cake.asciidoctorj (both have appVeyor as preferredBuildProviderType so I never noticed the problem there...) and every build in GH-Actions that is based on a tag, has BranchType set to Unknown. ("Every" being based on my sample of three.)

Compared to builds on appVeyor this seems to be the error. Builds on appVeyor that are tag-builds have BranchType set corresponding to the branch being tagged. I.e. Master for the above mentioned cases of Cake.7zip and Cake.asciiddoctorj.

I think the culprit is context.BuildSystem().GitHubActions.Environment.Workflow.Ref in github-actions.cake: For tagged builds on GH-Actions, ref is the tag-name. I.e. refs/tags/0.2.0 for the release build of test-rider.

[nils-a]

@AdmiringWorm you do have projects with preferredBuildProviderType: BuildProviderType.GitHubActions, right? Have you had this problem?

[gep13]

@nils-a I personally haven't moved any project to GitHub fully yet, as there was an ongoing issue with GitVersion which was making it not work properly on tagged builds. I think this has now been addressed though, but not started the process of moving over yet.

[nils-a]

I see. (Probably should continue my tests on appVeyor, then 😄 )

Nonetheless this issue would make moving difficult, too.

[gep13]

Sounds like a potential candidate for investigating on stream... This is something that I would like to get working, as a lot of work was done to get the support for different build providers.

[nils-a]

Good idea. I am certain I found the "error" (not sure about a fix, though). If you compare in github-actons.cake the lines 5-6 with 31-33 (esp. 5 with 31) this will never work correctly.

Not sure about a fix though. According to the docs I fear the "original" branch is not provided to us.
So... a fix could be calling git. Something like git branch --contains tags/0.2.0 should work.

[AdmiringWorm]

Good idea. I am certain I found the "error" (not sure about a fix, though). If you compare in github-actons.cake the lines 5-6 with 31-33 (esp. 5 with 31) this will never work correctly.

Different use case for both of them, 1 is for the tags the other for branch names. They aren't meant to be equal.

The problem is github actions itself, when it checks out a tag it checks it out in a detached state, without having a reference to the actual branch name of the commit (same thing happens on appveyor if you create a tag manually and push it, instead of creating it through the github UI).

I have seen this happen, on my own projects, but haven't found a solution other than using gha for most commits, but appveyor on a tagged commit.

The problem with it not sending the twitter message is due to the above and to the criteria here:

Cake.Recipe/Cake.Recipe/Content/build.cake

Lines 31 to 33 in f7b0621

	(BuildParameters.BranchType == BranchType.Master ||
	((BuildParameters.BranchType == BranchType.Release || BuildParameters.BranchType == BranchType.HotFix) &&
	BuildParameters.ShouldNotifyBetaReleases)) &&

Since it isn't possible to detect the git branch (at least I haven't found out how) on tagged releases, this evaluates to false every time and sending messages is disabled.

[nils-a]

@AdmiringWorm agreed.

However:

Lines 5/6 says:

var tempName = context.BuildSystem().GitHubActions.Environment.Workflow.Ref;
if (!string.IsNullOrEmpty(tempName) && tempName.IndexOf("tags/") >= 0)

So we're using context.BuildSystem().GitHubActions.Environment.Workflow.Ref and if it contains tags/ it's a tag and the part after the last / contains the tag-name.

line 31 uses the exact same thing (environment variable) i.e. context.BuildSystem().GitHubActions.Environment.Workflow.Ref and assumes the part after the last / is the branch name.

Both can not be true at the same time.

Or am I missing something?

[AdmiringWorm]

Both can not be true at the same time.
Or am I missing something?

Nope, you are correct, however the Ref will always be a tag for tagged builds (and BaseRef will be empty).
The part that checks the branch name will only be valid for branch builds, for tagged builds it will be more or less the same as the tag check (although you don't see that in the log, everything not matching master, develop, hotfix, release etc will always be unknown in the log).

This is unfortunately a limitation on the GitHub action though.

[gep13]

We tackled this on the stream tonight, and we have a working solution that correctly identifies that branch name, based on using git branch -r --contains {{ github.ref }}

In order for this to work, the following is required in the workflow file:

      - name: Fetch all history for all tags and branches
        run: git fetch --prune --unshallow