[cpovirk]

They started failing recently because of a non-hermetic build, and we've never wanted them.

Gemini on all that:

1. Do we want this CI job? (No—it’s already half-disabled and does nothing useful)

• The failing job (Prepare the run) is in main.yml (OpenJDK GHA Sanity Checks), which is upstream OpenJDK's CI workflow.
• Back in PR Build the JSpecify JDK #114 (c9befbc), WMD disabled all of the actual build/test jobs in main.yml by making check_platform() output false when platforms is empty:

  # echo 'true'
  # WMD: Assume empty means no platforms
  echo 'false'
  return

• However, main.yml still triggers on: push (both on main and on any branch pushed directly to jspecify/jdk, such as gcc in PR Remove GCC 10 from the list of packages to install. #180) and still runs the prepare job before checking which platform jobs to run.
• All prepare does is run build-jtreg/action.yml to build JTReg from source and upload a bundles-jtreg-8.3+1 artifact, and then output false for every platform so all downstream jobs are skipped and nothing ever uses the artifact. (Meanwhile, JSpecify's actual CI in jspecify.yml downloads prebuilt jtreg from builds.shipilev.net.)

---

2. Why did it start failing on PR #177?

The actions/setup-java bump in PR #177 was a coincidence (setup-java is only used in jspecify.yml, whereas build-jtreg/action.yml uses the runner's preinstalled $JAVA_HOME_17_X64):

1. build-jtreg/action.yml caches the built JTReg directory under key: jtreg-8.3+1 (from JTREG_VERSION in github-actions.conf) and skips downloading/building JTReg whenever there is a cache hit.
2. When you merged upstream OpenJDK on Sep 21 (e89cf6d97e5), build-jtreg built jtreg-8.3+1 once and populated that cache. Every push to main through PR Add @Nullable to more parameters. #176 (Oct 13, 18:48 EDT) hit that cache entry and refreshed its 7-day GitHub Actions TTL.
3. PR Bump actions/setup-java from 6.0.1 to 6.1.0 in the dependencies group #177 was merged on Oct 20, 21:01 EDT—7 days and ~2 hours after PR Add @Nullable to more parameters. #176—just after GitHub Actions evicted the jtreg-8.3+1 cache entry for inactivity.
4. On the cache miss, build-jtreg tried to build JTReg from source, which runs wget https://git.openjdk.org/jtharness/archive/jt6.0-b24.zip. git.openjdk.org is returning an HTTP error response (wget exit code 8) to GitHub Actions runner requests. Because the build fails, the cache is never repopulated, so every subsequent push fails the same way.

---

3. How to get rid of the red X

There are two clean ways to stop OpenJDK GHA Sanity Checks from running on pushes:

1. In .github/workflows/main.yml (recommended if you want it tracked in git):
   Comment out or remove the push: trigger in main.yml so only workflow_dispatch: remains (right next to the existing local diff at lines 36–37):

   on:
   #  push:
   #    branches-ignore:
   #      - pr/*
     workflow_dispatch:

2. In GitHub repo settings (zero diff against upstream):
   Disable the OpenJDK GHA Sanity Checks workflow in the GitHub Actions UI (or via gh workflow disable "OpenJDK GHA Sanity Checks" -R jspecify/jdk).

[cpovirk]

• That does look to have removed the job from the Checks section above.
• The "normal" CI job shows as a failure above because I haven't merged Remove GCC 10 from the list of packages to install. #180 into this branch.
• I guess I still have more zizmor work to do here, even after Address zizmor findings: #149? I can't remember.
• Previously in "Prepare": Address zizmor findings: #149 (comment)

[cpovirk]

• I guess I still have more zizmor work to do here, even after Address zizmor findings: #149? I can't remember.

Oh, OK, yeah:

I've focused only on our custom CI configuration, not on the CI configuration from upstream

Now we don't even "Prepare."