search

w3c / encrypted-media

Encrypted Media Extensions
https://w3c.github.io/encrypted-media/
Other
180 stars 80 forks source link

Enable auto-publication #553

Closed tidoust closed 1 month ago

tidoust commented 1 month ago

This automates the publication of all 9 EME documents to the gh-pages branch and to /TR, using the w3c/spec-prod action.

The W3CTRMANIFEST files are no longer needed as a result and nothing needs to be Git-ignored anymore either.

Also note the change of shortname for Encrypted Media Extensions to encrypted-media-2.

I added the Echidna tokens as repository secrets.

Preview | Diff

chrisn commented 1 month ago

Thank you, I have just one question. I notice that /TR/encrypted-media now also shows the FPWD, will both /TR/encrypted-media and /TR/encrypted-media-2 point to the same document as we make more updates? Or should /TR/encrypted-media still point to the existing Rec?

tidoust commented 1 month ago

Thank you, I have just one question. I notice that /TR/encrypted-media now also shows the FPWD, will both /TR/encrypted-media and /TR/encrypted-media-2 point to the same document as we make more updates?

Yes. I requested the same setting as for MSE: the series shortname encrypted-media returns the latest level of the specification, meaning encrypted-media-2.

Or should /TR/encrypted-media still point to the existing Rec?

Same as for MSE as well: the previous Recommendation got a (new) encrypted-media-1 shortname and is available at https://www.w3.org/TR/encrypted-media-1/.

chrisn commented 1 month ago

Perfect, that all makes sense.

marcoscaceres commented 1 month ago

Will these all run when we change one file? I wonder if we should bind each job to a particular path?

tidoust commented 1 month ago

Will these all run when we change one file?

Yes.

I wonder if we should bind each job to a particular path?

That would be useful for WebCodecs too (16 jobs run whenever a file is changed).

It's not trivial because the paths filter runs at the workflow level, whereas we would need it at the job level.

We could create one workflow per document. That works. That's not DRY-friendly. But then that's simple. Thinking about it, it should be trivial to script the creation of the workflow document to ease maintenance and address the "not DRY-friendly" concern.

Or we need to check what changed ourselves within a step. The Paths Change Filter action seems to provide what we need. To avoid starting a new job for each and every document, we would need to drop the "matrix" approach, and rather create one step per document. We'd lose a bit of DRY-ness as well.

I'll look into it. Let me know if you see other approaches!

tidoust commented 1 month ago

I created dedicated workflows with paths filters, generated from a companion script and a workflow template that I put under the .github folder as well. How does that look, @marcoscaceres?

tidoust commented 1 month ago

Merging. We can always iterate and improve the workflow afterwards :)