stencil-action

Currently, the only functionality exposed is to install stencil for usage in other steps.

This action supports both Forgejo and GitHub as sources for the stencil binary. When resolving latest, it tries Forgejo first and falls back to GitHub if unavailable.

• Forgejo source: Verifies the archive using GPG signature (ed25519 key)
• GitHub source: Verifies the archive using GitHub attestation

steps:
  - name: Checkout
    id: checkout
    uses: actions/checkout@v4

  - name: Install Stencil
    uses: rgst-io/stencil-action@latest
    with:
      # Used for attestation validation and when version is 'latest' (GitHub fallback).
      github-token: ${{ github.token }}
      # Optional: Version of stencil to install.
      version: 'latest'
      # Optional: Location to install stencil to. Automatically added
      # to the $PATH.
      binary-dir: '~/.local/bin'

  - name: Use Stencil
    run: stencil --version

When version is set to 'latest':

1. The action tries Forgejo (git.rgst.io) first via the Gitea-compatible API
2. If Forgejo is unavailable or returns no releases, it falls back to GitHub
3. The source (Forgejo or GitHub) is logged in the action output

When version is set to an explicit value (e.g., '1.2.3'):

• The action tries Forgejo first, then falls back to GitHub if the release is not found
• Forgejo source verifies via GPG signature; GitHub source verifies via attestation

This project includes a helper script, script/release designed to streamline the process of tagging and pushing new releases for GitHub Actions.

GitHub Actions allows users to select a specific version of the action to use, based on release tags. This script simplifies this process by performing the following steps:

1. Retrieving the latest release tag: The script starts by fetching the most recent SemVer release tag of the current branch, by looking at the local data available in your repository.
2. Prompting for a new release tag: The user is then prompted to enter a new release tag. To assist with this, the script displays the tag retrieved in the previous step, and validates the format of the inputted tag (vX.X.X). The user is also reminded to update the version field in package.json.
3. Tagging the new release: The script then tags a new release and syncs the separate major tag (e.g. v1, v2) with the new release tag (e.g. v1.0.0, v2.1.2). When the user is creating a new major release, the script auto-detects this and creates a releases/v# branch for the previous major version.
4. Pushing changes to remote: Finally, the script pushes the necessary commits, tags and branches to the remote repository. From here, you will need to create a new release in GitHub so users can easily reference the new tags in their workflows.