07af755d1efacbe58b684039fc5c588ffa767875
Some checks failed
check / check (push) Successful in 8s
Build and Deploy to Cloudflare Pages / build (push) Successful in 8s
probe / r1-wrangler-only (push) Failing after 7s
probe / r2a-upload-proven (push) Successful in 12s
probe / r3a-upload-node20 (push) Successful in 8s
Build and Deploy to Cloudflare Pages / deploy (push) Has been skipped
probe / r2b-download-proven (push) Successful in 2s
probe / r3b-download-node20 (push) Successful in 2s
Round 2 (602fd60) put the build job green:
check / check success 6s
Build and Deploy .../ build success 20s <- green
Build and Deploy .../ deploy skipped <- if: guard
probe / q1-upload-v3-node16 success 7s
probe / q2-upload-v3-node20 success 22s
probe / q3-build-for-roundtrip success 11s
probe / q4-deploy-dryrun failure 43s
Every v3 upload works and the build job is fixed. But q4 -- the deploy-side
rehearsal, which downloads the artifact in the pinned node container and
installs the pinned wrangler, stopping short of the publish call -- failed.
That is a break the deploy job would have hit on main, in a job nobody has
ever been able to run.
q4 bundled two things together, so round 3 splits them:
- r1 runs only the wrangler install and invocation. Worth measuring rather
than assuming: wrangler 4.120.0 declares engines.node >= 22 and the deploy
container is node 20, though the pre-issue deploy did run an unpinned
wrangler on node:20 successfully.
- r2a/r2b run the artifact round trip with no wrangler at all.
- r3a/r3b do the same for the newer node20 artifact builds, so the choice
between the two pairs is made on measurement.
deploy.yml meanwhile moves to the artifact commits that the mutable `@v3`
references were actually resolving to while this site was deploying, rather
than to the newest thing on the v3 line:
- upload-artifact -> ff15f030 (v3.2.1)
- download-artifact -> 9bc31d5c (v3.0.2)
That is the conservative reading of what this issue is for: pin what is known
to work, do not take a version bump for free on the way past.
lora.vegas
Las Vegas Meshtastic and LoRa community website.
About
This site provides information about the Las Vegas mesh networking community, including:
- Mesh channel configurations
- Community coordination (Discord, Signal)
- Meetup information
- Local resources
Contributing
To contribute to this site, contact sneak@sneak.berlin for git repository access.
Technical Details
This is a static site built with Hugo. The site is deployed automatically via GitHub Actions.
Local Development
hugo server
Visit http://localhost:1313 to preview.
Build
hugo
Output will be in the public/ directory.
Entrypoints
This repository adheres to the
Scripts to Rule Them All
standard: normalized scripts in script/ are the entrypoints for the
development workflow, and the Makefile targets are thin shims that call them. We
provide:
script/bootstrap— install all build dependencies (git, make, hugo, node/npm) idempotentlyscript/setup— prepare a fresh clone: runscript/bootstrapand install the git pre-commit hookscript/test— the correctness check: a cleanhugo --minifyproduction buildscript/lint— a clean build that surfaces broken links and path collisionsscript/fmt— format the repo's own top-level markdown docs with prettierscript/fmt-check— check that formatting (read-only)script/check— runscript/fmt-checkthenscript/test; modifies nothingscript/docker— build the Docker image tagged with the project namescript/cibuild— the CI build (docker build .); the Dockerfile runsmake checkscript/install-precommit— install the git pre-commit hook that runsscript/check
A convenience make serve target runs hugo server for local preview.
License
Content is provided as-is for community use.
Description
Languages
Shell
72.9%
Dockerfile
13.4%
CSS
8.1%
HTML
3.7%
Makefile
1.9%