workflow to auto publish jpan-lreq

[deniak]

Add a GH action workflow to autopublish jpan-lreq using workflow_dispatch to control when we want to trigger the action.
The PR is missing the URL to the decision.
@r12a can you please provide the link to the decision? I already added the secret for that spec in the repo.

[r12a]

hi @deniak I have no clue what all this means. Fwiw, you can see how we normally publish our documents at https://w3c.github.io/i18n-editors/echidna-pub/index.html

cc @xfq

[r12a]

Note, btw, that the 2-step process we use (1. build to harddrive, 2. publish) is vital, since we need to check that the build has occurred correctly before publishing. This is partly because we rely on special scripting during the build, and we need to check that images have been correctly incorporated, but also (importantly) because sometimes GitHub blocks the build process and we need to wait an hour to be able to build the document. We need to know whether that's the case before publishing to TR.

[himorin]

/cc @kidayasuo (note, this is not for jlreq, but another Japanese Script Resources document, for global / script-wide resources index)

[deniak]

Note, btw, that the 2-step process we use (1. build to harddrive, 2. publish) is vital, since we need to check that the build has occurred correctly before publishing. This is partly because we rely on special scripting during the build, and we need to check that images have been correctly incorporated, but also (importantly) because sometimes GitHub blocks the build process and we need to wait an hour to be able to build the document. We need to know whether that's the case before publishing to TR.

If there's additional steps needed on top of the regular respec snapshot generation, then that PR will not work as is.
Basically, a github action is a list of commands you can run after each commit (or when you decide to, using the workflow_dispatch event).
In this case, someone from the WG with some basic knowledge of github actions will be needed to update the workflow.
That process should eliminate the need to wait hours before being able to generate the document.
I'm happy to schedule a call to explain how this all works as I believe this will be a good improvement to the i18n specs in general.

[r12a]

@deniak Fuqiao and i will discuss this with you when we can find a suitable time (feel free to suggest). In the meantime, can you reinstate the current process? We have a backlog building that is preventing the work moving ahead. thanks.

[r12a]

Ok'ing for testing.

[deniak]

@deniak Fuqiao and i will discuss this with you when we can find a suitable time (feel free to suggest). In the meantime, can you reinstate the current process? We have a backlog building that is preventing the work moving ahead. thanks.

@r12a I just sent you an update version of the script.

[r12a]

@deniak thanks. Seems to be working fine now.

Let us know when you are available next week for a chat about the wider process.

[xfq]

Another point worth mentioning is that this repository contains multiple ReSpec documents. Is it possible for us to manually control the publication for each individual document?

[deniak]

Another point worth mentioning is that this repository contains multiple ReSpec documents. Is it possible for us to manually control the publication for each individual document?

Yes, the action mentions the path to the spec to be published and there will be one action per spec so you will be able to choose which one you want to trigger.

[r12a]

My initial thoughts are that this could be useful for perhaps the majority of documents. For example, i have just queued up 28 -lreq documents for publication, and pressing a button from the repo rather than building then pushing to TR will probably save a lot of time.

The problem is likely to arise for the 30 or so gap analysis documents, which need to be checked after build because they pull in content from GH issues via the GH API, and then use scripting to transform the document. I think we'll probably need to keep the current process for those.

Other documents, like jlreq, clreq, string-meta, glossary, etc will probably also be fine to migrate to the new process.

I have some questions:

1. i'm assuming that publishing a document, once the script is in place, is a question of simply pressing a button. Is that correct? @deniak you mentioned that "someone from the WG with some basic knowledge of github actions will be needed to update the workflow". I assume that that means we need someone to manage alterations to the .yml file as needed, but that to actually publish the documents it will be trivial?
2. how do we ensure that all images, etc., especially when adding new ones, are also published? Is the echidna file still involved?

[r12a]

Btw, the -lreq documents contain preprocessing functions that add content and pull in CSS from a central location. Will this still work? Here's an example:

	preProcess: [ () => { addPrompts() }, () => { addSharedData() }, ],


    postProcess: [
            async function importStyleSheet() { 
                const elems = document.querySelectorAll(`link[rel='stylesheet'][data-import]`)
                await Promise.all(
                    [...elems].map(async link => {
                        const text = await fetch(link.href).then(r => r.text())
                        const style = document.createElement("style")
                        style.textContent = text
                        link.replaceWith(style)
                        })
                    )
                }
            ],
        };