uhhm/iris
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases 22 Wiki Activity

Versioned as portal: released by portal's publish job
Test / test (push) Successful in 1m0s
Details

Browse Source 
iris reports its own version as the portal it matches; the tag, the
pin and the changelog line are written by portal's release step.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L4jrCgLiKKHAEFuZUJjckH
This commit is contained in:
Bendik Aagaard Lynghaug
2026-09-22 22:05:06 +02:00
co-authored by Claude Fable 5.1
parent e543b41cb0
commit bd8a5e0c6c
2 changed files with 16 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+13 -9
View File
@@ -39,15 +39,19 @@ what sits around those.
## Matching the site ## Matching the site
Every type iris reads is portal's own: portal is a library dependency Every type iris reads is portal's own: portal is a library dependency
pinned to a release tag in `Cargo.toml`, and `iris --version` says pinned to a release tag in `Cargo.toml`, and iris carries the same
which. A content repo should run the iris that matches the portal version number as that tag, so `iris v0.3.39` is the lint for portal
release its site runs. Portal's own release tarball ships an `iris` v0.3.39 and nothing else. A content repo pins `IRIS_RELEASE` to the
binary built the same way, so a site that pins nothing extra has one `PORTAL_RELEASE` its site runs. Portal's own release tarball ships the
at `/srv/app/<instance>/current/iris`. matching `iris` binary too, at `/srv/app/<instance>/current/iris`.
## Release ## Release
Move the `Unreleased` lines in `CHANGELOG.md` under a heading for the Iris is released by portal's publish job, never by hand: when a
version, bump `Cargo.toml`, commit, tag `v<version>`, push. CI builds portal tag is pushed, that job re-pins this crate to the tag, sets
the binary and attaches it to the Gitea release as `iris`, with that the version to match, builds and tests it, adds the changelog line,
section as the notes. and pushes the commit and the tag here. This repo's own CI then
attaches the binary to the Gitea release as `iris`. A portal change
to something the lint reads fails the portal release at that step.
Changes to iris itself land on `main` between releases and ship with
the next portal tag.
src/main.rs
+3 -5
View File
@@ -38,19 +38,17 @@ async fn main() -> anyhow::Result<()> {
replay::run(argv).await replay::run(argv).await
} }
Some("--version") | Some("-V") => { Some("--version") | Some("-V") => {
println!("iris {} (portal {})", env!("CARGO_PKG_VERSION"), PORTAL_TAG); println!("iris {v} (portal v{v})", v = env!("CARGO_PKG_VERSION"));
Ok(()) Ok(())
} }
Some(flag) if flag.starts_with("--") => check::run(argv).await, Some(flag) if flag.starts_with("--") => check::run(argv).await,
_ => { _ => {
eprintln!( eprintln!(
"iris {} - matches portal {PORTAL_TAG}\n\nusage:\n iris check (--repo <gitea-url> [--branch main] [--subdir questions] | --path <dir>) [--needs-tasks <out.jsonl> [--skim]] [--needs-sim <model.json>] [--needs-score <answers.jsonl> [--min-accuracy 0.8]]\n iris replay --path <dir> --nats <url> (--cases <cases.jsonl> | --report-only)", "iris {v} - matches portal v{v}\n\nusage:\n iris check (--repo <gitea-url> [--branch main] [--subdir questions] | --path <dir>) [--needs-tasks <out.jsonl> [--skim]] [--needs-sim <model.json>] [--needs-score <answers.jsonl> [--min-accuracy 0.8]]\n iris replay --path <dir> --nats <url> (--cases <cases.jsonl> | --report-only)",
env!("CARGO_PKG_VERSION") v = env!("CARGO_PKG_VERSION")
); );
std::process::exit(2) std::process::exit(2)
} }
} }
} }
/// The portal release this iris was built against (see Cargo.toml).
const PORTAL_TAG: &str = "v0.3.36";