mathieudutour / mathieudutour/github-tag-action
`fetch_all_tags: true` should be the default behavior to prevent incorrect behavior on repos with >100 tags
- Dominant language
- TypeScript
- Stars
- 733
- Forks
- 227
- PR merge metrics
- No merged PRs in 30d
Description
The action has an input `fetch_all_tags`. When it's set to `false`, which is the default, it only fetches the first 100 tags. The option must be set to `true` in order to fetch all tags.
Using the default value creates a ticking time bomb which goes off when the repository reaches 100 tags. When this happens, `github-tag-action` retrieves only a subset of all tags. If the latest tag is not in this subset, this causes the action to incorrectly determine the latest version and return an incorrect next version.
It therefore makes no sense to ever set `fetch_all_tags` to `false`: the action **must** fetch all tags to function properly. Unless the number of API calls can be optimized in some other way, it is necessary to fetch all pages.
Alternatively, the action could fail with an error if `fetch_all_tags` is `false` and all tags do not fit in a single page. Signaling "I cannot determine the next version with these inputs" would be preferrable to returning garbage. But I think it's best to get rid of the input altogether.
Contributor guide
Research direction
Start by locating the GitHub Action implementation and the `fetch_all_tags` input handling. Reproduce the behavior with a repository containing more than 100 tags, then verify that the action determines the latest and next version correctly without requiring an opt-in setting.】【。
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, typescript
- Domain
- ci-cd, release
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100