Add documentation on published specifications and how P4.org finds them #1334
Conversation
Signed-off-by: Andy Fingerhut <[email protected]>
|
@rcgoodfellow Some proposed docs on how the "Working draft" links on the P4.org specification pages work today. |
|
@rcgoodfellow Do your Github actions for building the HTML and PDF from the AsciiDoc source, put the resulting HTML and PDF files in a place with a known URL that does not change from one run of the Github actions to the next? If so, we can update the little HTML files on the P4.org server mentioned in this PR, to load those new URLs, instead of the URLs that they load now. |
The artifact URLs change from run to run. They are of the form: The deploy job is pushing artifacts to the I've noticed that images are not rendering from the page I'll look into that as soon as I can. |
| documnted here after those decisions have been made. | ||
|
|
||
|
|
||
| ### Working draft versions of specifications, generated from Madoko source (historical interest only as of 2024) |
There was a problem hiding this comment.
The links are still relevant today, as the Asciidoc CI mechanisms are still publishing files to these URLs.
|
It is a space optimization, not a must-have, but at least the older way of generating Madoko PDF and HTML grew the Git history of the p4-spec repo on every commit, because I believe it was keeping the full commit history of all PDF and HTML generated versions. The P4Runtime spec does not do that -- it uses a different way of publishing the generated PDF and HTML that always overwrites the previous PDF and HTML versions with the latest one, not keeping around the history. See #1287 for a few more details if you are curious. It might be as small of a difference as a single command line option to one git command somewhere. While you are investigating this, it would be nice if we could curb the future growth of the p4-spec repo in this same way. |
No description provided.