Skip to content

1.36.0 — checksums, and screenshots that are real

Choose a tag to compare

@github-actions github-actions released this 29 Aug 10:59
· 21 commits to main since this release

Added

  • Every release now says how to install it, on the page where it is
    downloaded.
    The macOS app is ad-hoc signed rather than notarised — that
    needs a paid Apple Developer account this project does not have — so macOS
    quarantines the downloaded zip and Gatekeeper refuses it with "SEO Audit is
    damaged and can't be opened"
    , offering to move it to the Trash. It is not
    damaged, and that message reads exactly like malware.

    Homebrew never had this problem: the cask verifies the checksum and clears the
    flag. But the release page and the README's download badge both led somewhere
    that explained none of it. Both now do, with the checksum printed first, so
    clearing the flag is something done after verifying the file rather than on
    the say-so of a README.

    Windows gets the same treatment for SmartScreen, and the AppImage's chmod +x
    is written down rather than assumed.

  • Every file on a release has a published checksum. The macOS zip always had
    one, because the Homebrew cask needs it. The .deb, the .AppImage and the
    setup.exe had none — so "check it before you wave the warning away" was
    advice you could not actually follow on the two platforms whose warning
    dialogs are the reason to say it. On Windows it reduced to "run it anyway".

    A SHA256SUMS.txt is attached to each release and the same lines are printed
    in its notes, so one command covers all four:

    shasum -a 256 --ignore-missing -c SHA256SUMS.txt

    Hashed from what is actually attached rather than from what each runner built,
    which also proves the upload arrived intact. One job rather than a step in each
    build: two matrix jobs editing the same release notes race, and the loser's
    edit is gone with nothing to show it.

  • The screenshots are a real crawl of a real site. The app shot was a
    25-page run whose numbers had drifted from what the app draws; it is now
    astro.build — 60 pages, 232 findings, 37 things to change, scored 87 — and the
    one error at the top is a link to a page that does not exist, which is the bug
    this tool was written to catch. A compare shot goes with it, docs.astro.build
    against astro.build, matched by path because the hosts differ. Settings was
    captioned "seven panes" and has had nine since Search Console shipped.

  • The site says there are three apps now, and what to do when one will not
    open.
    nurkamol.github.io/seo-audit offered a single "Download for macOS"
    button and described the app as macOS-only, which had been true for about a
    day. It now has a card per platform, the Homebrew route marked as the easier
    one, and a section for the warnings an unsigned build produces on macOS and
    Windows.

    The verify step and the quarantine command are two blocks with two copy
    buttons rather than one block with one, because a single paste that runs the
    checksum and then immediately clears the flag has verified nothing.

  • The desktop workflow can attach bundles to a tag it is given. A release
    whose upload failed can be completed by running the workflow manually, rather
    than by force-moving a tag that people may already have fetched.

Fixed

  • Three enum variants warned on every build that they were never
    constructed.
    Each is built under a #[cfg] — two on Windows, one on Linux —
    while every platform matches on all of them, because matching is not
    constructing. Silenced per variant and only where the claim is true, so a
    variant that stops being reachable on the platform that owns it still warns.

  • The first tagged release built its Windows and Linux bundles and then could
    not attach them.
    gh release upload came back with "HTTP 403: Resource not
    accessible by integration" — the workflow never asked for contents: write,
    so its token was read-only. Twenty minutes of building, installing and running
    the bundles, all of it correct, and then a refusal on the last step.

    The same commit also matched tags with a bare v*, which matches the floating
    v1 tag, so force-pushing v1 started a second full build that would have
    spent fifteen minutes failing to attach bundles to a release named v1.

    Both mistakes were already solved elsewhere in this repository, and
    mac-release.yml carries a comment describing the second one exactly. So both
    are now checked by test/workflows.test.mjs rather than written down a third
    time: a tag trigger may not be a bare v*, and a workflow that writes to a
    release must ask for permission to.

  • Refreshing a release's checksums no longer rebuilds it first. The
    checksums job needs needs: build on a tag, where the bundles have to be
    attached before anything can hash them. On a manual re-run they are already
    attached, and it was spending fifteen minutes compiling two Tauri bundles to
    hash four files it downloads from the release anyway.

    needs: cannot be conditional. A skipped job completes instantly, though, so
    the build is what became conditional — only_checksums skips it, and
    always() on the checksums job stops a skipped dependency from skipping it
    too. It still refuses to run behind a build that actually failed: hashing
    half-attached assets publishes a checksum for a release nobody should trust
    yet.

  • The checksums job had no repository to talk to. It needs a release's
    assets rather than the source, so it had no actions/checkout — and gh
    works the repository out from the git remote, so it failed with "fatal: not a
    git repository", which names a problem that was not the problem. GH_REPO
    says it directly. Checked now, like the other two: a job running gh with
    neither a checkout nor GH_REPO fails the suite.


Installing on macOS

brew tap nurkamol/seo-audit https://github.com/nurkamol/seo-audit
brew trust nurkamol/seo-audit
brew install --cask seo-audit

Homebrew verifies the download against the checksum below and clears the
quarantine flag for you, so the app opens the first time.

Downloading the zip instead? macOS may say "SEO Audit is damaged and
can't be opened."
It is not damaged. The app is ad-hoc signed rather than
notarised — notarising needs a paid Apple Developer account this project
does not have — and macOS refuses quarantined apps without a notarisation
ticket. Check what you downloaded first:

shasum -a 256 seo-audit-1.36.0-macos.zip
# 59789d5a83cbfa57021f9daa84999911c1321cefbfae1b5e4422740dfa4dd51c

Then, once it matches, clear the flag — no sudo needed:

xattr -dr com.apple.quarantine "/Applications/SEO Audit.app"

That is what right-click → Open does in the Finder, without the dialog.
Apple Silicon, macOS Tahoe or newer.

Windows and Linux

The setup.exe, .deb and .AppImage below are attached by a separate
job and may appear a few minutes after this release does.

The Windows installer is unsigned, so SmartScreen shows "Windows protected
your PC"
More info → Run anyway. Same reason as macOS: a code-signing
certificate is a paid, per-year thing this project does not have. The
.AppImage needs chmod +x before it will run.

Check any of them first. A SHA256SUMS.txt covering every file here is
attached alongside them, and the same checksums are listed at the end of
these notes:

shasum -a 256 --ignore-missing -c SHA256SUMS.txt

Checksums

Verify a download before you wave a warning away. With SHA256SUMS.txt
saved beside the file, in the same folder:

shasum -a 256 --ignore-missing -c SHA256SUMS.txt
67affeeea6eac4e1c1ed3a28a7544286db69f030e410d2591ccdd62adc270fbf  SEO.Audit_1.36.0_amd64.AppImage
94ca9978bd8063143dd7228d042348441926ef04f28bbf9e8b8caf7ff3e5a1ca  SEO.Audit_1.36.0_amd64.deb
14181cae775e06c6d89a915c6674e694fd06b0f89a1085f86e3ff45cb9f8326e  SEO.Audit_1.36.0_x64-setup.exe
59789d5a83cbfa57021f9daa84999911c1321cefbfae1b5e4422740dfa4dd51c  seo-audit-1.36.0-macos.zip

The macOS line appears twice in these notes on purpose: once above, computed
when the app was built, and once here, computed from what is actually attached.
They should agree.