Don't tag nightly pre-releases

[varac]

I'm using the lychee pre-commit hook.
pre-commit has a nifty autoupdate subcommand which updates all configured hooks to their latest git tags (which is considered by pre-commit as the latest stable release).
In the case of lychee, it will always update to the nightly git tag, which is not what I want. Could be maybe not use a nightly tag please ? If it always points to the main branch HEAD it's kind of useless anyway. It it's only needed for the GitHub nightly release maybe there's another way of shipping an automated nightly release without a dedicated (moving) git tag.
Thanks !

[mre]

Hey @varac, thanks for bringing this up! While looking at this, I also noticed that our pre-commit-hooks.yml example has an outdated Docker image version (0.14 while we're at 0.18 now).

For pre-commit users, I believe the recommended approach would be to pin to specific versions in their config, like this:

- id: lychee
  name: lychee
  description: "Run 'lychee' for fast, async, stream-based link checking"
  entry: lychee
  language: system
  args: ["--no-progress"]
  types: [text]
  pass_filenames: true
  require_serial: true
  rev: "v0.18.0"  # Pin to a specific version

Or for Docker users:

- id: lychee-docker
  name: lychee
  description: "Run 'lychee' docker image for fast, async, stream-based link checking"
  entry: lycheeverse/lychee:0.18  # Updated to latest version
  language: docker_image
  args: ["--no-progress"]
  types: [text]
  pass_filenames: true
  require_serial: true

That said, I'm not an expert on pre-commit's best practices and might be overlooking important considerations. I'd appreciate any corrections or suggestions on how to better handle this!

For now, we use the nightly tag for our automated builds and Docker images. Would pinning versions in the pre-commit config work for your use case? Let me know what you think!

[lwbt]

Hey @varac, thanks for bringing this up! While looking at this, I also noticed that our pre-commit-hooks.yml example has an outdated Docker image version (0.14 while we're at 0.18 now).

I'm not an expert either, but this might be a good example: https://github.com/koalaman/shellcheck-precommit/tree/master

I see that - id: lychee looks for a binary installed on the system:

lychee...................................................................Failed
- hook id: lychee
- exit code: 1

Executable `lychee` not found

From what I have seen so far, such hooks should end with the suffix -system e.g. - id: lychee-system.

Trying to follow the current instructions I cannot get it to work.

lychee...................................................................Failed
- hook id: lychee-docker
- exit code: 125

Error: short-name "lycheeverse/lychee:0.14" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"

I know, the easiest way would be to download the binary myself, but that's against how I was taught by the pre-commit FAQ and other articles to use pre-commit.

As you can see from shellcheck, a popular program, providing one hook is good enough. If it works.

[varac]

For pre-commit users, I believe the recommended approach would be to pin to specific versions in their config

That's the thing, I'd like to stick with pinned versions. But because of the nightly releases, pre-commit always updates the pinned version to rev: nightly. See here:

$ cat .pre-commit-config.yaml 
repos:
  - repo: https://github.com/lycheeverse/lychee.git
    rev: lychee-v0.18.0
    hooks:
      - id: lychee
        args: ["--config", "lychee.toml"]

$ pre-commit autoupdate
[https://github.com/lycheeverse/lychee.git] updating lychee-v0.18.0 -> nightly

$ cat .pre-commit-config.yaml 
repos:
  - repo: https://github.com/lycheeverse/lychee.git
    rev: nightly
    hooks:
      - id: lychee
        args: ["--config", "lychee.toml"]

Please note that all other pre-commit hooks I use are properly tagged, and upgrade fine to a pinned new version once there's a release.

[kemingy]

The nightly release has to bind to a tag, so the action has to delete the old one and create a new one when there are updates in the repo.

I agree that pre-commit autoupdate updates to a pre-release is usually not what users want. Sadly, I suppose the pre-commit won't fix this according to the comments in:

• pre-commit autoupdate wrongly picks pre-releases like 1.2.3a0 pre-commit/pre-commit#995

Also, git command won't be able to get the "pre-release" info, unless checking the semver (if the repo follows).

• code: https://github.com/pre-commit/pre-commit/blob/aba1ce04e70162ca48b12f809ceffb253b788fe6/pre_commit/commands/autoupdate.py#L46

So I guess the possible solution is finding another compatible 3rd tool to update the .pre-commit-config.yaml file. The one I know is preflight but it hasn't implemented the autoupdate feature. I have created a feature-request issue there.

[varac]

@kemingy One idea how to fix this I also had: Could you please use semantic versioning ? Meaning, could you please remove the lychee- prefix in the release version ? This way pre-commit could determine the last version properly. I'll try once lychee has a proper versioned release. Thanks !

[mre]

I could, but I'm not sure if it will be easy to do or fun. 😅 The problem is, that prefixes were added automatically once we switched to release-plz for releases. We had to fix the versioning in

• Releases
• Dockerfiles
• Package managers

It wasn't pretty.
So, I'm not exactly motivated to undo that change at the moment. 😕