@@ -26,7 +26,7 @@ We rely on GitLab CI/CD [Components](https://docs.gitlab.com/ci/components/) to
...
@@ -26,7 +26,7 @@ We rely on GitLab CI/CD [Components](https://docs.gitlab.com/ci/components/) to
It appears GitLab does this differently than GitHub. We're coming from GitHub and migrating/translating workflows. With GitHub reusable workflow authors must manually [move a major version tag themselves](https://docs.github.com/en/actions/sharing-automations/creating-actions/about-custom-actions#using-tags-for-release-management). It appears GitLab allows users to refer to a major version and will [automatically figure out the latest tag](https://docs.gitlab.com/ci/components/#semantic-version-ranges) of that major version. However, another difference is by convention GitHub often uses a `v` prefix on tag names, whereas GitLab conventionally may not. More investigation needed as it appears the automatic determination if latest tag at a given major version assumes no `v` prefix (in the examples anyways). So at the moment, I'm still manually moving a major tag as before with:
It appears GitLab does this differently than GitHub. We're coming from GitHub and migrating/translating workflows. With GitHub reusable workflow authors must manually [move a major version tag themselves](https://docs.github.com/en/actions/sharing-automations/creating-actions/about-custom-actions#using-tags-for-release-management). It appears GitLab allows users to refer to a major version and will [automatically figure out the latest tag](https://docs.gitlab.com/ci/components/#semantic-version-ranges) of that major version. However, another difference is by convention GitHub often uses a `v` prefix on tag names, whereas GitLab conventionally may not. More investigation needed as it appears the automatic determination if latest tag at a given major version assumes no `v` prefix (in the examples anyways). So at the moment, I'm still manually moving a major tag as before with: