Skip to content

Conversation

@JanSF
Copy link
Contributor

@JanSF JanSF commented Dec 5, 2025

This fixes Issue #76
First attempt: #122
Reverted, due to issue with commit hashes: #125

Instead of downloading the Go binary every time, let's do a version check first, and only download if the latest version doesn't match the current version.

If a specific version of the plugin is selected in the pipeline, and that specific version is in the semver format of ^v[0-9]+\.[0-9]+\.[0-9]+, then we skip the latest version check and just check the version of the binary against the specific version. If the plugin is pinned to a release commit hash, then the plugin code will be the one from the commit hash, but the latest binary will be downloaded.

@JanSF JanSF requested a review from a team as a code owner December 5, 2025 21:07
@toote
Copy link
Contributor

toote commented Dec 6, 2025

Wouldn't it be easier to append the version to the downloaded executable name and check for existence of the binary instead? That way you avoid string manipulations, comparisons and the coupling of the script and the binary through the string that shows the version

@JanSF
Copy link
Contributor Author

JanSF commented Dec 8, 2025

Unfortunately when we download the latest version, we won't know what version it is without running the binary to get the version.

We could add a -v flag to the binary that gives us our version more directly, if you don't like the info parsing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants