Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
nils-a opened this issue Jan 1, 2021 · 12 comments
Closed

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

nils-a opened this issue Jan 1, 2021 · 12 comments
Assignees
Labels
Milestone

Comments

@nils-a
Copy link
Contributor

nils-a commented Jan 1, 2021

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
Copy link
Contributor Author

nils-a commented Jan 1, 2021

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

@gep13
Copy link
Member

gep13 commented Jan 1, 2021

@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
Copy link
Contributor Author

nils-a commented Jan 1, 2021

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

Nonetheless this issue would make moving difficult, too.

@gep13
Copy link
Member

gep13 commented Jan 1, 2021

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
Copy link
Contributor Author

nils-a commented Jan 1, 2021

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
Copy link
Member

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:

(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
Copy link
Contributor Author

nils-a commented Jan 2, 2021

@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
Copy link
Member

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 added a commit that referenced this issue Jan 4, 2021
If tag is being built on GitHub actions, additional work is required in
order to find the branch name.
@gep13
Copy link
Member

gep13 commented Jan 4, 2021

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

@gep13 gep13 closed this as completed Jan 4, 2021
@gep13 gep13 added this to the 2.2.0 milestone Jan 4, 2021
@gep13 gep13 added the Bug label Jan 4, 2021
@gep13 gep13 self-assigned this Jan 4, 2021
@nils-a
Copy link
Contributor Author

nils-a commented Jan 5, 2021

@gep13 @AdmiringWorm I think we fixed this only for non-windows systems (And I think we checked only ubuntu yesterday).

If you check the ubuntu run from yesterday at https://github.com/gep13/CakeRecipeGHA/runs/1646503805?check_suite_focus=true#step:5:536 it reads:

Using GitHub Action Provider...
Resolved tool to path /usr/bin/git
Executing: /usr/bin/git branch -r --contains refs/tags/0.7.0
  origin/main
Printing Build Parameters...

compare that with the windows run at https://github.com/gep13/CakeRecipeGHA/runs/1646503796?check_suite_focus=true#step:5:750. It reads:

Using GitHub Action Provider...
Could not resolve path for tool "git" using these directories: [....]
Could not resolve path for tool "git" using these directories: [....]
Printing Build Parameters...

and this run also results in BranchType: Unknown

@nils-a
Copy link
Contributor Author

nils-a commented Jan 5, 2021

I have done some quick checks and it seems context.Tools.Resolve("git") has never been working for me anyway.

Building Cake.7zip (or any other Cake.Recipe enabled project) always starts like this:
image

nils-a added a commit to nils-a/Cake.Recipe that referenced this issue Jan 5, 2021
to all cases of resolving "git" to make them work on windows.
gep13 added a commit that referenced this issue Jan 5, 2021
@cake-contrib-bot
Copy link
Contributor

🎉 This issue has been resolved in version 2.2.0 🎉

The release is available on:

Your GitReleaseManager bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants