dloez / tag-track Goto Github PK

Using GH actions, create new releases when new tags have been pushed to the repository.
The release should include:

• Release notes
• Artifacts for all supported plaforms
• Install scripts for macOS, Linux, and Windows
• Installation instructions

Even where there are no commits since the last tag, tag-track suggest a minor version bump.

Currently only tags that follow the semantic versioning can be used, forcing users to create tags that follows that specification. We should allow users to define their tag pattern so we can extract the version from the tag instead of using the full tag as a version. This should be configured in the .tag-track file at the root of the repository.

This will be also required for monorepos using tag patterns to tag different applications.

Right now build.rs tries to get the version from the closest tag using the git history. If tag-track is built without a git history, it will not be able to populate the correct version.
We could modify the build.rs logic to:

1. Use a environment variable named ´TAG_TRACK_VERSION´ to use it as the version.
2. If ´TAG_TRACK_VERSION´ does not exists, use the current logic using the git history to populate the version.
3. If git history is not available, let cargo get the version from ´cargo.toml´.

Allow users to define which output format should be used to define actions executed by tag-track so it can be integrated better in CI systems.
A good starting point would be to allow json as an output format but the code must be prepared to integrate more output formats.

Research how could we provide a wrapper around Tag Track similar to the provided GitHub action.

Create basic documentation on the project readme

Currently, there are errors like MissingGitTags or MissingGitClosestTag returned by GitHub source functions that could be also returned by the git source. We need to improve the git command spawn process to be more certain of the errors we could get so we can return errors like MissingGitTags or MissingGitClosestTag in git functions rather than a vague GenericCommandFailed.

To support monorepos, we need to calculate scoped version bumps, for example:

1. A conventional commit is scoped to the foo application: feat (foo): example.
2. A tag following the pattern {SCOPE}-{VERSION} is found: foo-1.0.0.
3. A version bump is calculated from the scoped tag.

To enable this feature, a new --scoped-versioning flag will be needed.

List os subtasks:

• #55
• #66
• #67

Currently only linux and mac runners are supported.

If a commit does not match the used commit_pattern, a warning message indicating the commit SHA is displayed to warn the user which commits are being skipped to calculate the version bump. When the output format is set to JSON, this is still the behaviour.
If the output format is JSON, the application should add the skipped commits to the Output struct which will be then printed at the end of the execution.

When a different format from text is used, the CLI arguments are printed output in the inputs field. We need to include the configuration read from the configuration file.

If the compile action is specified, instead of downloading the binary, the binary should be built. The version that will be built will be the one referenced by the action reference.

If the closest oldest tag cannot be found in the latest 30 commits, ´tag-track´ will return an error about it being not able to find the tag.

In the function git::get_oldest_closest_tag the oldest closest tag is obtained by the current commit but this will not work if it is used in combination with the --commit-sha argument.
The function would need to have an argument to pass a commit SHA that will be used to get the oldest closest tag.

We need a way to run integration tests that creates repositories on GitHub and runs the action so we can evaluate its output.

• Readme includes bad formatted links in the description of the repository.
• Action does not push tags

If the input useCache is set to true, the action should store the binary (downloaded or built) in a GitHub cache, allowing following workflow runs to use it directly instead of downloading or building.

Users of the composite action are forced to parse the new-tags and version-bumps outputs with jq to get each scope new version. This is specially frustrating if you have a single app repo, where you are still being forced to parse it (this is out case for the tag-track repository).

We could have dynamic outputs with the format {scope}-{new/old?}version and {scope}-{new/old?}-tag to easily obtain those values but dynamic outputs are not supported in Composite Actions. We may be forced to migrate to a node action even being overkill for our use case.

In the mean time, can we maybe return the new tag name in the new-tags output if the unique scope is the empty scope (for single app repos)? I know this is not convenient, but it is a workaround until the migration to a node action.

Perform a quick verification of the inputted repository to check if it exists and it can be accessed.

If the closest oldest tag cannot be found in the latest 30 tags, ´tag-track´ will return an error about it being not able to find the tag.

When using matrix builds, multiple jobs will try to push the same tag to the repository, this will cause the first build to success, but the next ones will fail.

Research how we can use GitLab REST API to support it as a source.

If we are using a remote source, we can use the REST API to create tags and do not require git history and git to be available.

Create a GitHub action so it can be easily used in GH environments.
The action should:

• Download tag-track binary from releases.
• Run tag-track using GitHub source.
• Allow the user to control its execution with action inputs:
  • github-token
  • create-tag
  • scoped-versioning
  • etc

The current pattern is (?<version>) but it seems like the standard is v(?<version>.*).

Currently we are replacing the old version string with the new version string, this works but can cause issues on edge cases.

We can store the start match for the different fields in the tag in the tag details struct to be able to replace the correct characters for its new values.

Currently we are using hard-coded regex patterns to calculate version bumps. This method does not allow users to define their custom behavior. We need to design a method to allow custom rules for version bumping so it can be configured in the .tag-track file at the root of the repository.

When an error is printed and the error does not contain a message, it displays ´ErrorName: ´, which would be better if it were ´ErrorName´ if the error has not a message.

Instead of running cargo run in CI to run tag-track, use GitHub Action created in #12
This will increase the CI speed as it will not require to compile tag-track.

Documentation is missing for the following points:

• Schema of the JSON output when using the --output-format json argument.
• Configuration fields:
  • version_scopes
  • new_tag_message
• Usage examples for scope versioning.
• Pre-requisites (git not required when using the GitHub source).
• Github Action with scoped versioning (pending #68).

The documentation should include the requirements:

• Checkout before running tag-track.
• Configure git author if you want tag-track to create tags.

Use tag_pettern not only to parse tags, but also to create new tags.
If the tag pattern is v(?<version>.*), new tags should be v0.1.0.

• Typescript
• NCC

Research if it would be possible to create IDE extensions to display the current version inside the IDE.

To support GitHub enterprise instances, we should allow to modify the base url when calling GitHub REST API. This value should be obtained from the environment variable ´GITHUB_API_URL´ available on GitHub actions runners.

A good solution could be to add another parameter named --github-api-url that is used to modify the base url.

Currently tag track is used once per element in the matrix for the workflow named Build, lint, and test. This in combination with the compile: true input is slowing down builds. We can probably run it a single time, get its output version and use it on each matrix run.

This can be done by reducing the amount of characters used from the hasFile expression function.

Current method only works if is tag-track the one that reports the error, but if the program panics or there is an issue in the bash script that runs tag-track, the error is not processed.

Currently the environment variable ´GITHUB_SHA´ is mandatory to exist if the GitHub source is being used, which makes it "harder" or "not properly" documented when using in a local environment.
I think it would be better if we use a CLI argument similar to how the ´--github-token´ is used or even support both, environment variable and CLI argument but using environment variables seems to perform additional behavior not specified by the user specially when running on CI environments, where those variables exists automatically. For example, if a GitHub actions workflow executes ´tag-track´ and it automatically reads the secret ´GITHUB_TOKEN´, all requests would be automatically authorized under the scenes, but in case the workflow is not being directly executed and it is being reused by another workflow, it would not be able to read those secrets without specifying the ´secrets: inherit´ option. In the previous scenario ´tag-track´ is behaving different without the user noticing. I guess this could be "solved" by documenting it in the usage.