[Monorepo] Netlify to replace pr-review

[spectranaut]

We also want to look to add the follow features to our netlify publications:

• links in the comment from netlify to all specs that were edited by the PR, like: https://deploy-preview-2284--wai-aria.netlify.app/core-aam/ => PR [Monorepo] Netlify to replace pr-review #2242
• Can we have some kind of banner/message -- that links from the netlify publication back to the PR it was generated from? Explains what this is a preview of?
• Eventually, we will need successful links between specs generated by the PR instead of links to the editor's drafts
• publish generated respec document (instead of running respec client side)
• relative links to ARIA specs point to netlify preview Editorial: Relative links for PR and branch netlify previews #2473

[daniel-montalvo]

We now have statically-generated PR previews
#2265
All pages changed can be viewed from within the "Checks" tab, for example in https://github.com/w3c/aria/pull/2284/checks/> Netlify > Page changed

[spectranaut]

About Eventually, we will need successful links between specs generated by the PR instead of links to the editor's drafts -- If, for core-aam, we add the ED links like this:

  ariaSpecURLs: {
    ED: "../index.html",
    CR: "https://w3c.github.io/aria/",
    CRD: "https://w3c.github.io/aria/",
    PR: "https://www.w3.org/TR/wai-aria/",
    REC: "https://www.w3.org/TR/wai-aria/",
  },
  accNameURLs: {
    ED: "../accname/index.html",
    CR: "https://w3c.github.io/accname/",
    CRD: "https://w3c.github.io/accname/",
    PR: "https://www.w3.org/TR/accname-1.2/",
    REC: "https://www.w3.org/TR/accname-1.2/",
  },

It works in PR preview, which you could see before I realized w3c.github.io/core-aam editor draft would be broken: #2298

So maybe we really do need to set up all the w3c.github.io/* to directed back to this repository. Then if we do this for all the specs, the links will be correct in PR preview... right...?

[daniel-montalvo]

@spectranaut @pkra @jnurthen and all.

I have followed an approach similar to @spectranaut comments above in https://github.com/daniel-montalvo/aria

The build process now has a bash script that replaces specStatus with "unofficial" and then includes the unofficial keys for the resolveReferences function to generate relative links in the PRs.

For a prototype of how this could work, see
https://staging-aria.netlify.app
and add / to get to the other specs as desired.

I am using the Netlify production context for now because this is just a test. If we are happy with this approach, I will adjust the main ARIA netlify configuration file accordingly so that this only runs in PRs.

[pkra]

@daniel-montalvo I thought #2325 and #2386 had fixed cross references to link within PRs but on #2416 in https://deploy-preview-2416--wai-aria.netlify.app I find ~5000 links starting with https://w3c.github.io/aria/#. Should I open a new issue?

[daniel-montalvo]

Daniel to have a look at links that take to github.io

An example is list item.

[spectranaut]

Hmm @daniel-montalvo I'm trying to track down the fix for relative links in pr previews. Did you ever merge in the work you mentioned (in this comment above)[https://github.com//issues/2242#issuecomment-2271738905]?

There are a few PRs that reference this issue and mention relative links, but they both look like they were closed without merging and there is a zero diff in both of them: #2325 and #2386

Currently, the links that work are those that are generated by as relative links, for example, respec links to definitions.

The problem is that all the <rref> and <pref> and generated entries in the Characteristics table all go back to the editors draft, instead of being relative. Did we think we solved this, by the bash script you mentioned @daniel-montalvo? I think the script didn't make it into the main branch somehow, unless I'm missing something.

[daniel-montalvo]

Thanks for pointing this out, Valerie.

Bummer... I thought this was merged and restored my fork discarding all of these. Will have to recreate this.