helper to generate auto publication workflows

[deniak]

Based on @tidoust's suggestion, that PR adds a script to help generate the auto publication workflows for a given list of specs.
That PR assumes that the source document is named Overview.bs and each folder matches the shortname of the spec.

[svgeesus]

I see a failing check, but don't understand it. @deniak @tidoust

[svgeesus]

Looks good in general and easier to maintain

[svgeesus]

So, now that this is merged, what triggers the python script to run? Or do we run it locally and just commit the results?

[deniak]

So, now that this is merged, what triggers the python script to run? Or do we run it locally and just commit the results?

The script needs to be run manually only when there's a new spec to be autopublished or if the template is updated.

[deniak]

I see a failing check, but don't understand it. @deniak @tidoust

I see the recent checks passed. Please provide a link to the error if I missed something.

[svgeesus]

I see the recent checks passed. Please provide a link to the error if I missed something.

It is because Bikeshed warnings prevent publication. Bikeshed warns on variables only used once. I had been ignoring that because bikeshed is wrong (it does not consider foo and foo[2] to be two uses of foo but I changed the spec to prevent the warning and now it auto-publishes correctly.

[tabatkins]

(it does not consider foo and foo[2] to be two uses of foo

Since spec variables are in no particular language, there is no way for me to tell what part of the contents of a <var> are the "name" and what parts are "other stuff". So I'm as right as possible here. If you want it to work "correctly", <code>|foo|[2]</code> to just mark up the intended variable name as the var.