Fix build workflow conditionals that always evaluated true

[OowhitecatoO]

On a fork without Docker Hub secrets, build.yml fails at "Login to DockerHub" with Username and password required, which fails the job and skips everything after it, so a fork cannot complete a build. The guard is there — if: env.HAS_IMAGE_REPO_ACCESS — but env values are always strings and only the empty string is falsy, so "false" is truthy and the step runs anyway. The same applies to env.PUSH && in the push: expression: && returns an operand rather than a boolean, so the clause reduces to the rest of the condition and guards nothing.

This compares the four boolean-valued env references with == 'true'. It is a no-op on this repo, where both values are true and the expressions already produced the intended result; only fork behaviour changes. Example run: https://github.com/OowhitecatoO/docker-minecraft-server/actions/runs/30648142051 — the step log prints HAS_IMAGE_REPO_ACCESS: false directly above the step running and failing. That run had the matrix trimmed to one variant to save CI time; the login steps themselves are unmodified.

I hit this while trying to build the GraalVM variants on a fork. Along the way I found that current master builds java21-graalvm for both amd64 and arm64, and that the tar: Cannot open: Invalid argument failure behind #3899 no longer reproduces — including with the knockd retrieval that #3893 stubbed out restored: https://github.com/OowhitecatoO/docker-minecraft-server/actions/runs/30649087679. I have not opened anything for that. Is there still interest in those variants, or have you settled on dropping them?

Details, if useful

The rule is in the expressions reference, under Literals:

Note that in conditionals, falsy values (false, 0, -0, "", '', null) are coerced to false and truthy (true and other non-falsy values) are coerced to true.

The only falsy string is the empty string, so the string "false" is truthy. That values read back out of env are strings is documented in the env context, where env.<env_name> is typed string, and GitHub's own fromJSON example notes that an env: entry written as continue: true has to be passed through fromJSON() to become a boolean again.

I compared with == 'true' rather than moving the check into the if: directly, because the context availability table does not list secrets for jobs.<job_id>.steps.if — it is the only step-level key that omits it — so the env indirection for HAS_IMAGE_REPO_ACCESS has to stay. Using the same idiom for PUSH keeps all four sites reading alike, and a note above the env: block records why. The push: half is reasoned from the documented && semantics rather than observed, since the failing login aborts the job before that step runs.

Sites changed, all in .github/workflows/build.yml:

Line	Before	Effect
182	if: env.HAS_IMAGE_REPO_ACCESS (Login to DockerHub)	The failure above
189	if: env.HAS_IMAGE_REPO_ACCESS (Login to GHCR)	Also always true, though harmless in practice since it authenticates with github.token
202	env.PUSH && in push:	The clause has no effect at all
208	&& env.HAS_IMAGE_REPO_ACCESS in push:	Also always true, but unreachable today since build.yml has no pull_request trigger

The DockerHub guard dates to #1645 and the GHCR one to #2051; env.PUSH came in with #4179. The other uses of env in this file — matrix.variant == env.MAIN_VARIANT and the plain string interpolations — are fine, since they compare or interpolate strings rather than relying on truthiness. The notification workflows guarded in #4179 are also fine, as they compare github.repository_owner directly in expression context.

[itzg]

Thanks. I look at that reference material so often but apparently the subtlety of false vs "false" didn't catch my eye.

[itzg]

I hit this while trying to build the GraalVM variants on a fork. Along the way I found that current master builds java21-graalvm for both amd64 and arm64, and that the tar: Cannot open: Invalid argument failure behind #3899 no longer reproduces — including with the knockd retrieval that #3893 stubbed out restored: https://github.com/OowhitecatoO/docker-minecraft-server/actions/runs/30649087679. I have not opened anything for that. Is there still interest in those variants, or have you settled on dropping them?

Yes, I would be interested in putting them back if their builds work again.