We've been seeing an elevated rate of failure with...
# general
p
We've been seeing an elevated rate of failure with the init-pants github action lately. I wouldn't rule out github having issues, as it so often does lately, but it's a bit suspect to me that we see failures here specifically while other actions (and other stages of our pipeline) don't have correlated failures as I'd expect if it's just github issues. Will add the failure logs in thread since they're chunky, as well as showing how we invoke the action. Any suggestions on ways to avoid/fix this (e.g. some way to not need to run this at the start of every CI run, though I suspect that'd require self-hosted runners)?
The relevant logs (not that they're very interesting):
Copy code
Run pantsbuild/actions/init-pants@ab362158088bb31685015e7f5728a4c1df3c0e6e
Run VERSION=""
Downloading and installing the pants launcher ...
Installed the pants launcher from <https://github.com/pantsbuild/scie-pants/releases/latest/download/scie-pants-linux-aarch64> to /home/runner/.local/bin/pants

Running `pants` in a Pants-enabled repo will use the version of Pants configured for that repo.
In a repo not yet Pants-enabled, it will prompt you to set up Pants for that repo.
Run PANTS_BOOTSTRAP_CACHE_KEY=$(PANTS_BOOTSTRAP_TOOLS=2 pants bootstrap-cache-key)
Failed to determine release URL for Pants: 2.29.1: pants.2.29.1-cp311-linux_aarch64.pex: URL check failed: <https://github.com/pantsbuild/pants/releases/download/release_2.29.1/pants.2.29.1-cp311-linux_aarch64.pex>: Remote end closed connection without response

If this is unexpected (you are using a known good Pants version), try upgrading scie-pants first.
It may also be that the platform linux_aarch64 isn't supported for this version of Pants, or some other intermittent network/service issue.
To get help, please visit: <https://www.pantsbuild.org/community/getting-help>


Error: Failed to establish atomic directory /home/runner/.cache/nce/1c59ae05daeeb7ceae4a96c7b05ec1228de96709ca441436003f7cd6ff5f65e0/locks/configure-596ca741353296a2f1a590b9ba25b850a5b139a31382a364573cba8699ce96f3. Population of work directory failed: Boot binding command failed: exit status: 1

Isolates your Pants from the elements.

Please select from the following boot commands:

<default> (when SCIE_BOOT is not set in the environment)  Detects the current Pants installation and launches it.
bootstrap-tools                                           Introspection tools for the Pants bootstrap process.
update                                                    Update scie-pants.

You can select a boot command by setting the SCIE_BOOT environment variable.
The step that invokes this (there's other stuff in the job this runs in, but I don't think any of it is relevant):
Copy code
- id: init-pants
      uses: pantsbuild/actions/init-pants@ab362158088bb31685015e7f5728a4c1df3c0e6e # main
I see the usage example in the repo for the init action specifies caches. That could be all we need, depending on what exactly they're used for, but I feel like we've previously removed some caching in this area because they'd gotten huge and runs were faster without them.
We're also on quite an old version of the action (from March 2025) so potentially due a bump there, though I'm not necessarily expecting that to help here.
h
Sorry for the trouble. "Remote end closed connection without response" means it's definitely github shutting you out. I wonder if this is falling afoul of some anti-scraping detection on github's end. Possibly your other actions are not exhibiting the relevant pattern. Are there any corporate proxies in the way?
Either way, caching should help.
I don't see anything sensible we can do on the client side
p
All github-hosted stuff within github, no proxies etc. About what I expected though, thanks for the sense check!
h
p
Yeah, we're seeing errors across the board on random pulls since yesterday now. I'm gonna take this as further evidence for my theory that it's down to GitHub's quality/availability deteriorating and us noticing it primarily on the pants setup because it's the longest running pull from GH within our CI