Name the missing Pages setting instead of failing on it, and stop the browser test failing on a long game - #3
Merged
Conversation
enablement: true cannot work with a workflow token: creating a Pages site needs administration:write, which GITHUB_TOKEN cannot be granted, so the step failed with "Resource not accessible by integration" rather than enabling anything. The action's own maintainers changed the default away from attempting it for the same reason. Removed, and the one-time human step it was trying to avoid is written down where the next person will look for it. Co-authored-by: BruceMoseti <BruceMoseti@users.noreply.github.com>
The harness aims at a random legal ball, so it plays badly and its games run long in the tail: one reached 66 shots and was still making progress when the 40-turn cap stopped it, failing a test that had nothing wrong with it. Games observed since: 5, 6, 23, 29, 31, 33, 37 shots, all concluding. The cap is there to catch a table that has stopped progressing, not to express how long a game should take, so it moves to 120 and the failure now says how many shots were played and what phase the game was stuck in. selfplay.mjs already allows 250 for the same reason. Co-authored-by: BruceMoseti <BruceMoseti@users.noreply.github.com>
cursor
Bot
changed the title
The deploy job has gone red on every push to main, with "Resource not accessible by integration" from configure-pages. That reads like a broken workflow. It is not: Pages has never been switched on for the repository, and no workflow token can switch it on. The precondition is now checked and named. If the site does not exist the job ends with a warning saying which setting to set, and publishes nothing rather than failing at it. Once the setting is set, every step runs as before. Co-authored-by: BruceMoseti <BruceMoseti@users.noreply.github.com>
cursor
Bot
changed the title
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.
Everything here came out of working out why the published page returns 404.
The page cannot publish itself, and the workflow now says so
The deploy job has gone red on every push to
main:That reads like a broken workflow. It is not. GitHub Pages has never been switched on for this repository, and no workflow can switch it on: creating a Pages site requires
administration: write, which a workflow'sGITHUB_TOKENcannot be granted — it is not one of the valuespermissions:accepts. The action's own maintainers changed its default away from attempting this for the same reason (actions/configure-pages#40, #48). Pushing agh-pagesbranch is not a way around it either: publishing from a branch still needs the source configured, and GitHub does not run a Pages build for commits pushed with a workflow token.So
enablement: trueis gone, and the deploy job now checks the precondition and names it. With no Pages site it ends with a warning saying exactly which setting to set, and publishes nothing rather than failing at it; with a site, every step runs as before.The one-time step: in Settings → Pages, set Source to GitHub Actions. Then re-run the deploy workflow, or push anything to
main, and the game is live at https://brucemoseti.github.io/cueai/#play.The browser test could fail on a game that was fine
While checking that the page survives being served from a subpath —
/cueai/, the way Pages serves it; it does, every asset path is relative, and four games played to completion that way with no console errors — the browser test failed withgame did not reach a conclusion. Nothing was wrong. The harness aims at a random legal ball on purpose, so it plays badly, and one game reached 66 shots and was still making progress when the 40-turn cap cut it off.That cap exists to catch a table that has stopped progressing, not to say how long a game should take, so it moves to 120 —
selfplay.mjsalready allows 250 for the same reason — and the failure now reports how many shots were played and which phase the game was in, so a stuck table is distinguishable from an unlucky one.Games observed since, all reaching a legal conclusion: 5, 6, 23, 29, 31, 33 and 37 shots.