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

Error exit when DEFAULT_BRANCH is empty, despite BRANCH_HISTORY being set to last #243

Closed
vancejc-mt opened this issue Jan 6, 2023 · 13 comments

Comments

@vancejc-mt
Copy link

Hello,

It looks like #235 introduced an issue for us (as mentioned in the PR) - in our case, we have BRANCH_HISTORY set to last, but it's still erroring out due to DEFAULT_BRANCH being empty.

While theoretically DEFAULT_BRANCH should not be empty (looks like there's an issue with the symbolic-ref in our remote pointing to a non-existent branch (thanks main/master)), the fact that we're using BRANCH_HISTORY set to last should ignore this exit error altogether - DEFAULT_BRANCH is not used at all if BRANCH_HISTORY is set to last.

Is there a way that we can avoid the DEFAULT_BRANCH check if BRANCH_HISTORY is set to last ?

@sbe-arg
Copy link
Collaborator

sbe-arg commented Jan 6, 2023

The quickest fix is to set the env var DEFAULT_BRANCH with whatever is the default branch, main master, other

@sbe-arg
Copy link
Collaborator

sbe-arg commented Jan 6, 2023

Can you share the debug logs as well and what merge strategy are you using?

@stefano-elysium
Copy link

having the same issue, please fix ASAP

@sbe-arg
Copy link
Collaborator

sbe-arg commented Jan 6, 2023

@stefano-elysium can you please share the debug logs. Hard to understand why the var is empty for your use case without logs.

@vancejc-mt
Copy link
Author

Agree we can put in the DEFAULT_BRANCH to avoid this (doing so now) but shouldn't technically be necessary with last (I saw your PR go in which should avoid this - awesome thanks!)

Debug logs:

The DEFAULT_BRANCH should be autodetected when tag-action runs on on PRs else must be defined, See: https://github.com/anothrNick/github-tag-action/pull/230, since is not defined we find it natively
fatal: ref refs/remotes/origin/HEAD is not a symbolic ref
default_branch=
Error: DEFAULT_BRANCH must not be null, something has gone wrong.

Let me know if I can get you information otherwise.

@vancejc-mt
Copy link
Author

Our merge strategy is a little complex; we have main and dev branches which are long lived. Feature branches off of dev are squashed-merged into dev, and when ready to release we do a normal merge to main. Our action only queues on push to main.

@sbe-arg
Copy link
Collaborator

sbe-arg commented Jan 6, 2023

Thanks for sharing the merge strategy details.
if you can test 1.61.0 and and report back would be amazing

@vancejc-mt
Copy link
Author

Things look like they're working, thanks again

@TobiWo
Copy link

TobiWo commented Jan 10, 2023

Hi @sbe-arg, I also tested the new version but still found some issues:

I always use the rebase and merge pattern with the following workflow trigger:

on:
  pull_request:
    types:
      - closed
    branches:
      - main
  1. If I set BRANCH_HISTORY: full and add ref: ${{ github.sha }} to the with property (as suggested in your documentation) I receive a fatal: ambiguous argument error. Here is an example run.
  2. If I set BRANCH_HISTORY: full without ref: ${{ github.sha }} in the with property, the commit history is empty so no version bump happens (DEFAULT_BUMP: none). Here is an example run.
  3. If I set BRANCH_HISTORY: last without ref: ${{ github.sha }} in the with property (as suggested in your documentation) everything works as expected. Here is an example run.

@sbe-arg
Copy link
Collaborator

sbe-arg commented Jan 15, 2023

Whats the problem then? Documentation in the readme?

Cc @sammcj

@TobiWo
Copy link

TobiWo commented Jan 18, 2023

I would say the issue is the documentation (see fatal error) and how the tool works on rebase and merge in general. The full commit history check does not work if I rebase and merge. I didn't test with normal merge commit workflow but I guess as most users use this pattern (I guess you as well) you would have seen many people complaining 🙂.

@sbe-arg
Copy link
Collaborator

sbe-arg commented Jan 18, 2023

Mind opening a pr with the readme improvements? @TobiWo

@TobiWo
Copy link

TobiWo commented Apr 7, 2023

Hi @sbe-arg sorry for the super late reply. However, I just want to comment on your request: I'm working on my own open source tool like you guys so I actually do not have time to work here as well (although I really like this action). If I will try to improve the rebase and merge functionality if I can find time and maybe adapt the documentation as requested.

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

No branches or pull requests

4 participants