mirror of
https://github.com/taiki-e/install-action.git
synced 2026-05-06 05:00:27 +00:00
65 lines
2.5 KiB
Markdown
65 lines
2.5 KiB
Markdown
# Development Guide
|
||
|
||
## Add support for new tool
|
||
|
||
(Example: [ffbd316](https://github.com/taiki-e/install-action/commit/ffbd316e0fe98cb460dae3a66cd2ef9deb398bb1))
|
||
|
||
1\. Add base manifest to [`tools/codegen/base`](tools/codegen/base) directory.
|
||
|
||
See JSON files in `tools/codegen/base` directory for examples of the manifest.
|
||
|
||
2\. Generate manifest with the following command (replace `<tool>` with the tool name).
|
||
|
||
```sh
|
||
./tools/manifest.sh <tool>
|
||
```
|
||
|
||
> If you're having problem with github api rate limit, you can use your GITHUB_TOKEN to increase the rate limit.
|
||
> If you have `Github CLI` installed (the command `gh`), you can:
|
||
>
|
||
> ```sh
|
||
> GITHUB_TOKEN=$(gh auth token) ./tools/manifest.sh <tool>
|
||
> ```
|
||
|
||
3\. Update `TOOLS.md` with the following command.
|
||
|
||
```sh
|
||
./tools/update-markdown.sh
|
||
```
|
||
|
||
## Troubleshooting
|
||
|
||
If one of the CI builds fails due to a bin path or release asset_name, fix the problem in the base
|
||
manifest, and re-run the manifest tool `tools/manifest.sh` to regenerate the manifest json file. The
|
||
base manifest supports overriding the bin path per platform by adding the `"bin"` / `"asset_name"`
|
||
to the platform object.
|
||
|
||
If CI fails only for containers using older versions of glibc or musl, you may need to add the tool
|
||
name to one of the `*_incompat` arrays in `tools/ci/tool-list.sh`.
|
||
|
||
## Release new version
|
||
|
||
Releases are performed by running the [release workflow](https://github.com/taiki-e/install-action/actions/workflows/release.yml) via workflow dispatch. The owner and collaborators can start the release workflow, but the owner’s [approval](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments#required-reviewers) is required before the actual release.
|
||
|
||
### Minor version vs patch version
|
||
|
||
Increase the patch version if only the following changes are included.
|
||
|
||
- Update the `@latest` version of the tool.
|
||
|
||
Rationale: Normally, tool versions are controlled by the `@<version>` syntax, which is explicitly separated from the versioning of the install-action itself.
|
||
|
||
Exception: If the major or minor version of the `cargo-binstall` is updated, the minor version may be increased because the behavior of the fallback may change slightly.
|
||
|
||
- Fix regressions or minor bugs.
|
||
|
||
Rationale: Semantic Versioning.
|
||
|
||
- Improve documentation or diagnostics.
|
||
|
||
Rationale: Semantic Versioning.
|
||
|
||
Usually increase the minor version otherwise.
|
||
|
||
Adding support for a new tool may conflict with existing fallbacks, so it is necessary to increase the minor version.
|