- From: Denis Ah-Kang via GitHub <noreply@w3.org>
- Date: Tue, 24 Feb 2026 16:47:53 +0000
- To: public-css-archive@w3.org
> This approach that uses one workflow per spec seems a good one to me, be it only because it allows to only publish specs that actually got updated and need to be published (thanks to the `on.push.paths` setting). > > Not a blocker for this one, but I note that this will become harder to maintain as the number of specs that switch to auto-publication grows. In the `w3c/webcodecs` repository, we use a short Node.js script that starts from a workflow template and the list of specs that are in the repository and that generates the appropriate workflow files, see: > > * The [`generate-auto-publish-workflows.mjs`](https://github.com/w3c/webcodecs/blob/main/.github/generate-auto-publish-workflows.mjs) script > * The [`auto-publish-template.yml`](https://github.com/w3c/webcodecs/blob/main/.github/auto-publish-template.yml). > > Such a script can be used to re-create all workflow files whenever needed, which allows to, e.g., update action versions, and tweak parameters all at once. I suggest to adopt a similar approach. The Node.js script could be easily re-written as a Python script if that seems more aligned with the other build scripts. That's good to know. I agree the list of workflows can quickly become hard to maintain given the number of specs in that repository. -- GitHub Notification of comment by deniak Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/13553#issuecomment-3953400901 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 24 February 2026 16:47:54 UTC