Skip to content

build: resolve binary release tag dynamically from GitHub releases API#16

Merged
JKRT merged 1 commit into
OpenModelica:masterfrom
SVAGEN26:dynamic-release-tag
Jun 24, 2026
Merged

build: resolve binary release tag dynamically from GitHub releases API#16
JKRT merged 1 commit into
OpenModelica:masterfrom
SVAGEN26:dynamic-release-tag

Conversation

@SVAGEN26

Copy link
Copy Markdown
Contributor

Summary

deps/build.jl hardcoded the GitHub release tag used to download the prebuilt native libraries and the ModelicaCallbacks shim. The callbacks URL pointed at a v0.1.0 tag that does not exist (only libs-v0.1.0 does), so the shim download always 404s — and on Windows, where there is no gcc toolchain, the source-compile fallback also fails, leaving external-C error handling without its shim.

This replaces the hardcoded const URLs with a single release tag that is resolved dynamically at build time from the GitHub releases API.

What changed

  • Introduced const RELEASE_TAG = Ref{String}(DEFAULT_RELEASE_TAG) populated at build time by resolveReleaseTag().
  • resolveReleaseTag():
    • queries the GitHub releases API for this repo,
    • selects the newest tag on the libs-* binary-release line (these are intentionally decoupled from the package source version),
    • falls back to the most recent release overall, then to the libs-v0.1.0 default if the API is unreachable / rate-limited,
    • honors GITHUB_TOKEN / GH_TOKEN to avoid the anonymous rate limit in CI,
    • logs the chosen tag (and reason) via @info / @warn.
  • Both the runtime libraries and the callbacks shim now derive their URLs from releaseBaseURL() → the single resolved tag.

Why

The dev/user build should follow the latest binary release rather than pin a stale (and in the callbacks case, nonexistent) tag. With this change the build automatically picks up a newer libs-* release as soon as one is cut, with no code edit.

Verification

Ran Pkg.build("OMRuntimeExternalC"; verbose=true) on Windows + Julia 1.12.6:

[ Info: Resolving latest OMRuntimeExternalC release tag from GitHub...
[ Info: Resolved latest binary release tag
        tag = "libs-v0.1.0"
[ Info: Downloading archive from .../download/libs-v0.1.0/x86_64-mingw32.zip...
[ Info: Successfully extracted libraries ...

The runtime libs download and extract correctly. The callbacks shim still 404s because the *-callbacks.tar.gz asset is not yet published on the libs-v0.1.0 release — that is a separate follow-up (publishing the asset via the existing CI.yml release job), independent of this change.

🤖 Generated with Claude Code

@CLAassistant

CLAassistant commented Jun 23, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

Replace the hardcoded `const RELEASE_BASE_URL` / `CALLBACKS_VERSION` /
`CALLBACKS_BASE_URL` strings with a `const RELEASE_TAG = Ref{String}(...)` that is
populated at build time by `resolveReleaseTag()`. That function queries the GitHub
releases API, selects the newest `libs-*` tag (falling back to the most recent
release overall, and finally to a hardcoded default when the API is unreachable or
rate-limited), honors GITHUB_TOKEN/GH_TOKEN, and logs the chosen tag via @info/@warn.

Both the runtime libraries and the ModelicaCallbacks shim now derive their URLs
from the single resolved tag, so the build automatically follows the latest binary
release instead of pinning a stale `v0.1.0` that 404s. (Publishing the
`*-callbacks.tar.gz` asset onto that release remains a separate task.)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@SVAGEN26 SVAGEN26 force-pushed the dynamic-release-tag branch from bfe1a85 to ca9cb67 Compare June 24, 2026 09:35
@JKRT JKRT merged commit 834e29a into OpenModelica:master Jun 24, 2026
4 checks passed
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.

3 participants