enable auto-publication for css-color-5

[deniak]

That PR adds a GitHub action to publish css-color-5 through echidna after each commit.
It relies on spec-prod to build the spec and submit it to echidna.

I already generated the token for css-color-5 and added it as a repository secret.

Also, as discussed, the will be able to disable that action if needed and re-enable it later.

[svgeesus]

Does this need to override with "Prepare for TR: yes" or does Echidna add that automatically?

I don't see anywhere that ../default.css is added?

[svgeesus]

Some questions remain

[tidoust]

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 script
• The 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.

It might be interesting to deploy Editor's Drafts to GitHub Pages using the same workflow as well. Right now, any update in the repository triggers a complete rebuild of all specs, which takes more than 8 minutes. That could also be done later on.

[tidoust]

Does this need to override with "Prepare for TR: yes" or does Echidna add that automatically?

The spec-prod action takes care of that automatically.

I don't see anywhere that ../default.css is added?

The spec-prod action automatically retrieves and publishes stylesheets and images that appear to be linked from the specification. Now, it does not seem that css-color-5 links to default.css? (various specs in the repository do, but not this one, as far as I can tell).

[svgeesus]

Now, it does not seem that css-color-5 links to default.css? (various specs in the repository do, but not this one, as far as I can tell).

Looking at recent CSS TR publications, they don't anymore (but do have huge inline css) so I guess that gets added by bikeshed now. Well, that will save me one step from manual publication in future.

The spec-prod action automatically retrieves and publishes stylesheets and images that appear to be linked from the specification.

Could you be a little more precise? Just stylesheets and images, or other things as well? For this spec, images has images/fonts which has a woff2 font needed for the SVGs.

[deniak]

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 script
• The 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.

[deniak]

The spec-prod action automatically retrieves and publishes stylesheets and images that appear to be linked from the specification.

Could you be a little more precise? Just stylesheets and images, or other things as well? For this spec, images has images/fonts which has a woff2 font needed for the SVGs.

spec-prod will fetch all the resources linked from the main document. However, in the case of css-color-5, the fonts are used by the svg files, e.g. https://www.w3.org/TR/2026/WD-css-color-5-20260113/images/CH-mixing.svg, and spec-prod will not see them so you are right, we will need to adapt the action to include the fonts files too.

[deniak]

@sidvishnoi and I worked to fix the subresources issue and spec-prod will now fetch the missing fonts as well. With this, I believe that PR is ready to be merged.

[deniak]

@svgeesus I re-triggered the action after you merged my fix on the workflowand it passed just fine this time:
https://lists.w3.org/Archives/Public/public-tr-notifications/2026Feb/0202.html

See https://www.w3.org/TR/2026/WD-css-color-5-20260227/