action-gh-release VS golangci-lint-action

While those actions are indeeded archived, they do recommend some other community actions to use. I have used https://github.com/softprops/action-gh-release and it works well. That said, you need to do your own due diligence on how comfortable you are using community actions.

Alternatively, if you do not want to use the LaTeX compilation process on GitHub Actions, you can omit the building process and track the locally generated PDF file as well. Usually binary files, PDF files in this case, are not tracked. You can remove the Compile LaTeX Document step in the .github/workflows/release.yml file, and start tracking the output PDF in your repository. By this way, you can move the compilation process to local. However, if you follow this path, by default, you will not have your output PDF listed under releases. It is possible to achieve this by editing the Release step in the workflow (see action-gh-release for more information).

action-gh-release really makes it easy to do these steps.

softprops/action-gh-release able to achieve that in two lines of code.

Finally, we use a 3rd-party release creation Action for creating a release draft with the release notes and artifacts we just created:

# source: https://github.com/golangci/golangci-lint-action?tab=readme-ov-file#how-to-use name: golangci-lint on: push: branches: - master - main pull_request: permissions: contents: read # Optional: allow read access to pull request. Use with `only-new-issues` option. # pull-requests: read jobs: golangci: name: lint runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-go@v4 with: go-version: '1.21' cache: false - name: golangci-lint uses: golangci/golangci-lint-action@v3 with: # Require: The version of golangci-lint to use. # When `install-mode` is `binary` (default) the value can be v1.2 or v1.2.3 or `latest` to use the latest version. # When `install-mode` is `goinstall` the value can be v1.2.3, `latest`, or the hash of a commit. version: v1.54 # Optional: working directory, useful for monorepos # working-directory: somedir # Optional: golangci-lint command line arguments. # # Note: By default, the `.golangci.yml` file should be at the root of the repository. # The location of the configuration file can be changed by using `--config=` # args: --timeout=30m --config=/my/path/.golangci.yml --issues-exit-code=0 # Optional: show only new issues if it's a pull request. The default value is `false`. # only-new-issues: true # Optional: if set to true, then all caching functionality will be completely disabled, # takes precedence over all other caching options. # skip-cache: true # Optional: if set to true, then the action won't cache or restore ~/go/pkg. # skip-pkg-cache: true # Optional: if set to true, then the action won't cache or restore ~/.cache/go-build. # skip-build-cache: true # Optional: The mode to install golangci-lint. It can be 'binary' or 'goinstall'. # install-mode: "goinstall"

Finally, we can use golangci-lint's provided GitHub Action for linting - it runs golangci-lint on the workflow runner's clone of the repo and outputs an error code if any Go file in the repo fails rules of any linters in golangci-lint. Note that golangci-lint fails if the AST cannot be parsed (i.e. if there are any syntax errors), so it can also be used for checking syntax correctness, which itself is a good proxy for checking for merge conflict strings. We can fail-fast with any checks this way - there's no need to spin up a compilation and a go test invocation if there are syntax errors.

If you want to run golangci-lint in CI, you can use golangci-lint-action same as other actions.