fix(pages): supply the Pages workflow the repository was configured for but never had - #69
Merged
Merged
Conversation
…or but never had Pages is configured with build_type "workflow". This repository carries no Pages workflow, so the build never ran and the site was never published: https://hyperpolymath.github.io/nesy-solver/ returns 404 for the site root and for /.well-known/security.txt alike. Supplying the workflow is the fix that needs no repository-settings access. (A switch to the legacy branch builder would also work, but the token in use does not carry the Pages settings scope.) WHY THE STAGING IS A SUBSET, NOT THE REPOSITORY ROOT index.html references /public/styles.css and /public/app.js, and the site needs .well-known/ at its root. Those, plus the entry page, are what is staged. Publishing the repository root would instead serve 45 root files — AUDIT.adoc, Containerfile, server.js, wrangler.toml and the rest — none of which is content. WHY NOT .nojekyll The first pass added one, reasoning that Jekyll drops dot-directories. That is true of the legacy branch builder, and irrelevant here: a workflow upload does not run Jekyll, so the file would have been dead weight that looked like a fix. It is not included. UNRESOLVED, AND NOT FIXABLE FROM HERE wrangler.toml is a Cloudflare Pages configuration (pages_build_output_dir = "dist") and index.html advertises nesy-solver.dev, which does not currently resolve. So this repository may already have an intended host that is not GitHub Pages. If Cloudflare is the real target, this workflow is scaffolding rather than the answer, and .well-known/ still needs to reach that origin root — a GitHub Pages project path is not it. Settling that does not change this commit: it makes the configured Pages build run, and exposes nothing that was not already public.
Contributor
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| cancel-in-progress: false | ||
|
|
||
| jobs: | ||
| build: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pages is configured for this repository with
build_type: "workflow". There is no Pages workflow, so the build never runs and the site was never published:Supplying the workflow is the fix that needs no repository-settings access. (Switching to the legacy branch builder would also work — I tried, and the token in use does not carry the separate Pages settings scope.)
Why the staging is a subset, not the repository root
index.htmlreferences/public/styles.cssand/public/app.js, and the site needs.well-known/at its root. Those three things, plus the entry page, are what is staged. Publishing the repository root instead would serve 45 root files —AUDIT.adoc,Containerfile,server.js,wrangler.tomland the rest — none of which is site content.Simulated locally:
Why not
.nojekyllMy first pass added one, reasoning that Jekyll drops dot-directories. That is true of the legacy branch builder and irrelevant here — a workflow upload does not run Jekyll, so the file would have been dead weight that looked like a fix. It is not included.
This is the same trap twice in one session:
hyperpolymath.github.ioalso looked like a.nojekyllproblem and is also an Actions-built site.Unresolved, and not fixable from here
wrangler.tomlis a Cloudflare Pages configuration (pages_build_output_dir = "dist"), andindex.htmladvertisesnesy-solver.dev, which does not currently resolve:So this repository may already have an intended host that is not GitHub Pages. If Cloudflare is the real target, this workflow is scaffolding rather than the answer, and
.well-known/still needs to reach that origin root — a GitHub Pages project path is not the origin root, so RFC 8615 is not satisfied by this alone.Settling that does not change this commit: it makes the configured Pages build run, and exposes nothing that was not already public.
Context
Found while resolving the 8 repositories held back from the
.well-known/→www/.well-known/migration (#119). This repository is deliberately not migrated: it expects to serve from an origin root, so root.well-known/stays.