fix: fetch-tags when checking out repo in gh actions

[raharper]

What type of PR is this?

cleanup

Which issue does this PR fix:

n/a

What does this PR do / Why do we need it:

Hopefully fix VERSION and VERSION_FULL values when building a tagged release.
Looks like checkout action doesn't fetch git tags by default.

If an issue # is not available please add repro steps and logs showing the issue:

Look at v1.2.1 tagged release pipeline; it's failing since it gets a version
set to has, not a tag.

Testing done on this change:

This PR pipeline test

Automation added to e2e:

none

Will this break upgrades or downgrades?

no

Does this PR introduce any user-facing change?:

no

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 54.86%. Comparing base (4583f3d) to head (7398bf7).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #796   +/-   ##
=======================================
  Coverage   54.86%   54.86%           
=======================================
  Files          55       55           
  Lines        5909     5909           
=======================================
  Hits         3242     3242           
  Misses       2094     2094           
  Partials      573      573           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mikemccracken]

I haven't seen these before so I googled around a bit and found an issue where people are complaining that just adding fetch-tags: true doesn't do what you want. ( actions/checkout#1471 )

apparently you need to also add fetch-depth: 0, maybe just by itself - see the doc here:
https://github.com/actions/checkout#checkout-v4

here's an example with both: python-packaging/honesty@10f2a23

[raharper]

I haven't seen these before so I googled around a bit and found an issue where people are complaining that just adding fetch-tags: true doesn't do what you want. ( actions/checkout#1471 )

apparently you need to also add fetch-depth: 0, maybe just by itself - see the doc here: https://github.com/actions/checkout#checkout-v4

here's an example with both: python-packaging/honesty@10f2a23

Thanks for the check -- from what I can tell it defaults to fetch-depth: 1 -- which at least for us pulls all of our tags..

https://github.com/project-stacker/stacker/actions/runs/32987140212/job/98235984015?pr=796#step:3:68

I'm leaning toward keeping it as-is and if we find we're missing tags we update then? WDYT?

[raharper]

Hrm, re-creating the steps that the workflow does results in a correct VERSION_FULL=v1.2.1 --- but looks like our build.yaml uses a github value build-id -- not yet sure how that's get calculated but it sure looks like tag+commit-hash -- rather than just the tag....

still digging

[raharper]

This whole thing reminds me of why I dislike github. webui release flow only creates "lightweight" tags -- vs annotate tags which have a date and git object associated with them. This matters when using git describe to get the repo version state; -- so either we use something like git describe --tags which looks at lightweight and annotated where as without --tags only annotated tags are used.

Further, we likely need to separate the build-id being used to set VERSION_FULL since it is sometimes a git sha, and sometimes a git tag + shortsha value.

Will continue to work on something that makes sense for both webui releases as well as annotated pushed tags.

[raharper]

@mikemccracken turns out that fetch-depth: 0 is required -- but it wasn't obvious; it turns out that for git describe --tags to figure out what's going on it needs commit ancestry to connect the HEAD to any given tag.

Closing this as #797 pulled in this commit, and added fetch-depth: 0 to get everything to resolve getting VERSION the same way as developers do after local checkout.