Calculated height varies between local git and GitHub Actions #991
Replies: 8 comments 10 replies
-
|
There's probably something different between the local and GHA working directories. The first thing I would do is turn the verbosity up to |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for taking your time to reply. As you already hinted, something is different .. so the good thing is, that your tool is working .. the bad thing is, that I need to investigate why the GitHub repo is different from my local repo (i did mention I was not an expert git user). I will close with thanks - but leave it so others may learn from my mistake :-) PS Full log from local: Compared with full log from GitHub: |
Beta Was this translation helpful? Give feedback.
-
Even with the differences - if i do a gh repo clone codebeltnet/shared-kernel everything works as expected (or as close to expected as possible). I still dont get the commit id deviation .. I also tried resetting main with my local copy .. still same issue. I will continue digging, but I am blindfolded :-) |
Beta Was this translation helpful? Give feedback.
-
|
And just to add; i have been using your tool in AzDO pipelines for years .. only GitHub Actions proves a greater challenge than expected. Oddly enough - I am not successful in finding minver integrations .. but that could of course just be my Google skills that are lacking ;-) |
Beta Was this translation helpful? Give feedback.
-
|
Tags are not read .. even with both fetch-depth set to 0 as well as fetch-tags set to true. Here is a new dump: |
Beta Was this translation helpful? Give feedback.
-
|
As you can see from the logs, the head commit is 5e7240e (29th March), which is way down in your history, and is indeed at a height of 8 from 5ef3567 (27th March), which is your first commit. There is a 0.1.0 tag on commit d73e7d (1st April) but that appears much more recently than the head commit, so it's obviously not in the history, and therefore MinVer doesn't see it. I see no problem with MinVer here. It seems to be working as expected. The problem seems to be with your working directory. You are expecting the head commit to be somewhere around 7de6c7 (1st April). It seems your local working directory does have its head commit where you expect, but your working directory in GitHub Actions seems to be stuck on commit 5e7240e (29th March) for some reason. As an observation, I see you are wrapping stock actions such |
Beta Was this translation helpful? Give feedback.
-
|
When adding some debug info inside GHA, this is actually what I am also seeing locally: Same thing run by MinVer: I have to investigate further .. and maybe deepdive into the MinVer code :-) |
Beta Was this translation helpful? Give feedback.
-
|
@adamralph - I finally found a solution .. although I still do not understand how that could have such a great impact. I was puzzled by the git show-ref --tags --dereference pointing to b422e307 instead of 7ad14902, so my last resort as of today was to move minver call to before the call to download an external file into the repo. codebeltnet/shared-kernel@be03219 This solved it .. not sure why, as the file is not committed or anything .. anyway, thank you for your time .. and hopefully others can learn from mistake/findings. TL;DR: call minver ASAP after your checkout. Cheers. |
Beta Was this translation helpful? Give feedback.
-
|
Your “Download sharedkernel.snk file” step must be doing something weird to your working directory. It may be worth resolving that as it may have other effects on your later steps. |
Beta Was this translation helpful? Give feedback.
-
|
It is just downloading the signing key for the project. Nothing more; nothing less. But thanks. |
Beta Was this translation helpful? Give feedback.
-
|
@adamralph you where right; apparently I accidently cached |
Beta Was this translation helpful? Give feedback.
-
I don't really understand which MinVer integrations are required. For .NET SDK projects, you can install the For other uses, you can execute: dotnet tool install --global minver-cli --version 5.0.0
minver |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that is also what I am doing. When I talk integrations, then its more towards the CI/CD pipeline - e.g., fetching version number and using it outside the confines of .NET (e.g., Docker tagging etc.). Besides that, your tool is very easy to use - and my preferred .. especially if I manage to get it to work with GHA. |
Beta Was this translation helpful? Give feedback.
-
|
It seems like there isn't a bug in MinVer here so I'm moving this to a discussion, in case anyone can help out with your working directory problems. |
Beta Was this translation helpful? Give feedback.
-
So while transitioning from AzDO Pipelines to GitHub Actions, I noticed an odd behavior before even adding tags and whatnot.
Note, in time of writing, I am just playing around to get a grasp on how this new pipeline is working .. so apologies if something looks odd.
Version(s)
MinVer 5.0.0
To reproduce
Steps to reproduce the behaviour:
Expected behaviour
I am no git expert - but I would expect the following from all environments:
Actual behaviour
Local (Windows, Git Bash, Bash WSL - Ubuntu 22.04):
GitHub:
Additional context
My apologies in advance if I have overseen or misunderstood how to use your otherwise great tool.
GitHub action i use to checkout: https://github.com/codebeltnet/pipelines/blob/main/.github/actions/gh-checkout/action.yml
GitHub action i use to calculate version: https://github.com/codebeltnet/pipelines/blob/main/.github/actions/minver-version/action.yml
Beta Was this translation helpful? Give feedback.
All reactions