photos: pin exif-sooc 0.2.0 in the guards, and fix the install command - #400
Merged
Conversation
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
aadhar-sh | 614892a | Aug 15 2026, 12:17 PM |
The guards checked that exif-sooc understood -all=, which a build can do
while still being wrong. 0.1.0 supported the flag and truncated every
progressive JPEG it stripped, and every JPEG this pipeline produces is
progressive, so the check could not tell a working binary from one that
destroys the file. It compares --version against 0.2.0 now, through
`sort -V`, so 0.10.0 reads as newer than 0.2.0 rather than older.
Three things the version check had to get right, each verified against a
stub on PATH rather than reasoned about:
broken binary refused, and it SAYS so. `|| true` on the assignment
is load-bearing: under `set -euo pipefail` the script
otherwise died at that line, silently, before it
could explain itself
garbled --version refused. `sort -V` will happily order a word against
a version and answer, so anything that is not a
plain x.y.z fails closed
0.1.0 vs 0.10.0 ordered correctly
Separately, the documented install command had stopped working and is
fixed in all twelve places it appears. exif-sooc became a cargo WORKSPACE
when its tools moved to an xtask, so `cargo install --git <url>` can no
longer infer the package and exits asking for one. It needs the package
name: `cargo install --git <url> exif-sooc`. That command was printed in
the guards' own error messages, so the advice for a stale binary was
itself broken.
config/tools.json records min_version, since the registry is where the
declaration checker looks.
oddharsh
force-pushed
the
chore/pin-exif-sooc-version
branch
from
August 15, 2026 12:15
a5e4c48 to
614892a
Compare
Contributor
Wire-size diff vs merge base
Brotli q11, the quality the edge serves. Every number here is deterministic: Client assetsNo change. 20 files, 73.98 KiB Brotli total. PagesNo change. 48 files, 496.95 KiB Brotli total. Worker bundleNo change. 271.96 KiB gzip. Dictionary deltas (
|
oddharsh
enabled auto-merge (squash)
August 15, 2026 12:17
This was referenced Aug 15, 2026
oddharsh
added a commit
that referenced
this pull request
Aug 16, 2026
…verse (#416) This gotcha claimed twice that the Copilot check fails on every diff, and one of those claims went in a few hours ago as the general lesson. It is wrong. The run always fires; whether it REQUESTS A MODEL depends on the diff. The job prints a file exclusion list on every run, covering js, json, mjs, ts, py, rs, yaml, yml, html, xml, go, java, c/cpp, rb and more. `.md`, `.sh` and `.css` are NOT on it. So a docs diff survives the filter and gets a `claude-opus-4.6` request, while a pure JavaScript diff is filtered to nothing and the run exits clean. Both paths print `Sessions disabled: not supported for code scanning yet`, which this session initially read as the discriminator and is not; the discriminating line is `Creating copilot-sdk session with model`, which only the failing path reaches. Correlates 12 of 12: the five runs of 2026-08-15 (#399 jpg/json and #402 js/mjs passed; #398, #400 and #401 all carried md and failed), plus all seven earlier failures checked backwards. #313 is the "CSS-only" diff this gotcha already singles out, and css is not on the list either. #351's note here called its entire diff a `${{ }}` move in workflow files; it touched md and mjs too, and the md is what drew the request. The prose-only argument is unchanged in conclusion and inverted in mechanism: a docs PR reddens this because markdown is one of the few things the detector still looks at, rather than because the agent choked on prose. The entitlement root cause is untouched. Records the method failure too, since it is the transferable part. Nine entries were built by pattern-matching outcomes across PRs without once reading which files each diff touched, and "fails on everything" was an artifact of that sample. One uncollected column explained the whole shape. Co-authored-by: Aadharsh Pannirselvam <19518661+oddharsh@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The guards checked that exif-sooc understood -all=, which a build can do
while still being wrong. 0.1.0 supported the flag and truncated every
progressive JPEG it stripped, and every JPEG this pipeline produces is
progressive, so the check could not tell a working binary from one that
destroys the file. It compares --version against 0.2.0 now, through
sort -V, so 0.10.0 reads as newer than 0.2.0 rather than older.Three things the version check had to get right, each verified against a
stub on PATH rather than reasoned about:
broken binary refused, and it SAYS so.
|| trueon the assignmentis load-bearing: under
set -euo pipefailthe scriptotherwise died at that line, silently, before it
could explain itself
garbled --version refused.
sort -Vwill happily order a word againsta version and answer, so anything that is not a
plain x.y.z fails closed
0.1.0 vs 0.10.0 ordered correctly
Separately, the documented install command had stopped working and is
fixed in all twelve places it appears. exif-sooc became a cargo WORKSPACE
when its tools moved to an xtask, so
cargo install --git <url>can nolonger infer the package and exits asking for one. It needs the package
name:
cargo install --git <url> exif-sooc. That command was printed inthe guards' own error messages, so the advice for a stale binary was
itself broken.
config/tools.json records min_version, since the registry is where the
declaration checker looks.