2025-10-01 [09:16:25.0937] Again [09:17:01.0772] bakkot ljharb [09:19:24.0300] Maybe because I pushed a PR of mine that had the wrong version of the action? [09:19:29.0054] * Maybe because I pushed to a PR of mine that had the wrong version of the action? [09:19:45.0524] yes, that would do it - always rebase before pushing [09:19:53.0976] i'll fix the branch, one sec [09:20:06.0900] But why run deploy from a PR? [09:20:18.0018] for PR previews. an older version of the action had a bug [09:20:32.0586] ok, give it a minute and the page should hopefully be fixed [09:20:59.0507] I will rename the script so this doesn't happen [09:21:11.0885] I wanted to do a better fix but haven't had time [09:21:13.0602] I'm confused about how this can do it though. I don't have write permission to the repo, so what is in my fork shouldn't matteerr? [09:21:23.0553] * I'm confused about how this can do it though. I don't have write permission to the repo, so what is in my fork shouldn't matter? [09:21:45.0953] actions have that permission even if you don't [09:22:03.0133] * actions can have that permission even if you don't, i believe [09:22:52.0893] Oh I see, we run on `pull_request_target` but running the script from the PR branch and not the script committed in the target branch [09:23:02.0822] Yeah [09:23:10.0926] we could rename the secret and that'd fix it [09:23:26.0871] Renaming the script will also fix it [09:23:46.0328] Better fix is to use the build script from the main repo also but that takes more work [09:23:56.0247] and debugging github actions is very annoying so I haven't done it yet [09:24:08.0072] renaming the script would let someone add a workflow to their own PR and push anything they wanted up there, by adding the old script name [09:24:10.0040] * Better fix is to use the build/deploy scripts from the main repo also but that takes more work [09:24:17.0104] * renaming the script would let someone add a workflow to their own PR and push anything they wanted up there, by adding the old script name, no? [09:24:22.0322] For ecma426 we only checkout `spec.emu` and `img/` from the PR branch, and for the rest we use files on `main`: https://github.com/tc39/ecma426/blob/6f45f6fd5884424b5131e2709aff833fa3327e2e/.github/workflows/auto-publish.yml#L28 [09:24:27.0232] * renaming the script would let someone add a workflow to their own PR and push anything they wanted up there, by adding the old script name, no? (if they targeted an old enough commit on main) [09:24:31.0176] script only runs for tc39 members or when explicitly requested by a maintainer [09:24:50.0745] I am not worried about tc39 members trying to mess with things [09:25:20.0491] fair [09:25:49.0570] we definitely want to use ecmarkup from the PR branch at least, because much of what previews are for is confirming ecmarkup updates worked as expected [09:29:47.0392] https://github.com/tc39/ecma262/pull/3697 for now 2025-10-02 [17:30:56.0824] fixing preview is on my list; the pattern that works is at https://github.com/tc39/template-for-proposals/tree/main/.github/workflows [17:35:54.0644] It's fixed once https://github.com/tc39/ecma262/pull/3698 lands [17:36:49.0115] This is intentionally slightly different from the code in template-for-proposals [18:04:48.0675] I hadn't looked at https://github.com/tc39/ecma262/pull/3698 until just now, but I agree that it also works. We should also switch template-for-proposals over to the same scripts-from-main approach: https://github.com/tc39/ecma262/pull/3698#pullrequestreview-3291743667 2025-10-03 [10:43:36.0965] a friend is running a JS trivia night in SF next week, and I figured some of you who are local may be interested https://luma.com/hmi5b6ql