[CI] Use default checkout depth

[matthiasdiener]

Description

This is intended to reduce the time spent on the git checkout step in CI.
Not sure if we need the full checkout depth. Tests seem to pass with the default depth (=1) + tags.

Timings (min:sec) for checkout (not necessarily representative, timings vary quite a bit):

CI run	Checkout time on MI325	Checkout time on MI355	Data transferred	Disk size
This PR	3:03	0:53	370 MByte	880 MByte
CI run w/o this PR	5:55	13:36	1540 MByte	2100 MByte

Type of change

• Documentation change (change only to the documentation, either a fix or a new content)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Infra/Build change
• Code refactoring

Changes

Please list the changes introduced in this PR:

• Do not set checkout depth, but require git tags
• Update checkout version to v6

Checklist:

• I have read and followed the contributing guidelines
• The functionality is complete
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[wenchenvincent]

I think removal of fetch-depth of all levels should be fine and fetch-tags might not be necessary. I will let @ipanfilo and @leo-amd comment

[ipanfilo]

What is desired result of removing fetch-depth:0?

[matthiasdiener]

What is desired result of removing fetch-depth:0?

I noticed that the checkout stage in CI runs takes a considerable amount of time (highest I've seen is 36+ minutes, e.g. in https://github.com/ROCm/TransformerEngine/actions/runs/21598826002/job/62238786074). Not fetching the full git history (and only fetching the GitHub Actions default, i.e. the latest commit in each repo) helps reduce that (see e.g. the numbers in the initial message in this PR).

[ipanfilo]

My concern is that to run CI on a PR, GHA makes merge commit to the destination branch. I think to make proper merge commit git should have history at least to fork point. How does checking out w/o history work in this case?

[matthiasdiener]

My concern is that to run CI on a PR, GHA makes merge commit to the destination branch. I think to make proper merge commit git should have history at least to fork point. How does checking out w/o history work in this case?

Can you clarify, is there some custom merge commit creation in our CI, or is it the default GHA behavior? In the latter case, GitHub creates the merge commit internally, before the checkout action runs, so the fetch-depth setting does not affect the merge.

[leo-amd]

Removing fetch-depth: 0 should be safe. The concern about the merge commit is valid for local git operations, but GHA creates the merge commit on the server's side before the job starts on a runner
fetch-tags: 'true' is likely unnecessary though

[matthiasdiener]

1f93d39 removes the fetch-tags, and CI seems to work fine.

[ipanfilo]

There is still [skip_]dev_merge option in manual run but it seems currently unused. So having no depth should be OK.
Can skip_dev_merge be removed to make sure we don't start using it

[matthiasdiener]

I removed the skip_dev_merge option in 01fa0d5.