Ease local development and testing of said changes, including Markdown relative links (and thus static validation that destination files exist, at build time).
Potentially improve search engine ranking.
Remove duplication of maintenance efforts around updating jekyll-theme-amethyst, keeping stylesheets in sync, etc.
Proposal
I'd like to unify these two domains, with the content coming solely out of the docs/ directory in the main qunit repository.
Steps to get there
What we have today:
api.qunitjs.com is published from the qunitjs/qunit repo's docs/ directory, via its gh-pages branch.
qunitjs.com is published from the qunitjs/qunitjs.com repo's main branch, to its gh-pages branch.
Restraints: Committing the qunitjs.com site directly to this repo, would create an undesirable intermediary state for the api.qunitjs.com domain, during which testing changes is hard as it wouldn't be previewing the final state, and further more introduce additional URLs for content that aren't meant to keep working. This is imho a bit too risky and hard to revert back from, as it also involves CNAME/DNS changes.
Proposed steps:
[x] Step 1: Commit a patch to the qunitjs.com repo that merges in the API sites.
This merges the site data, and assets, and adds a copy of the Markdown content to an api/ subdirectory.
This is a locally previewable version of the state we want, and could be committed and published as-is.
We can use the spider-check job to verify links within this domain, and re-run typesense to crawl that domain only.
We can leave this for a little while. Existing links to api.qunitjs.com will keep showing the old-but-identical content temporarily. We can spot-check a few individual URLs on the api.qunitjs.com domain to confirm that the same URLs do work on the new site as well, by changing the domain, and confirming the URL is either a 200 OK or a redirect to one.
[x] Step 2: Set up a redirect in https://github.com/jquery/infrastructure-puppet from api.qunitjs.com to qunitjs.com and update DNS for api.qunitjs.com away from GitHub Pages and to our redirect service instead.
[x] Step 3: Commit the whole site from the qunitjs.com repo to the docs/ directory in this repo. This might trigger a GitHub Pages build to put non-API content on the API subdomain, but will either fail or invisibly succeed since that domain no longer points to GitHub. We do this step before the next, so that GitHub has the new content ready to be served.
[x] Step 4:
In the qunit repo's GitHub Pages config, change api.qunitjs.com to qunitjs.com.
In the qunitjs.com repo's GitHub Pages config, remove qunitjs.com.
Rationale
Proposal
I'd like to unify these two domains, with the content coming solely out of the
docs/directory in the main qunit repository.Steps to get there
What we have today:
api.qunitjs.comis published from the qunitjs/qunit repo'sdocs/directory, via its gh-pages branch.qunitjs.comis published from the qunitjs/qunitjs.com repo's main branch, to its gh-pages branch.Restraints: Committing the qunitjs.com site directly to this repo, would create an undesirable intermediary state for the
api.qunitjs.comdomain, during which testing changes is hard as it wouldn't be previewing the final state, and further more introduce additional URLs for content that aren't meant to keep working. This is imho a bit too risky and hard to revert back from, as it also involves CNAME/DNS changes.Proposed steps:
api/subdirectory.api/will include a newredirect_fromfor its previous path without theapi/prefix. E.g.api/QUnit/test.mdwill includeredirect_from: - "/QUnit/test/". This means https://api.qunitjs.com/QUnit/test/ will redirect to https://qunitjs.com/api/QUnit/test/.spider-checkjob to verify links within this domain, and re-runtypesenseto crawl that domain only.api.qunitjs.comwill keep showing the old-but-identical content temporarily. We can spot-check a few individual URLs on theapi.qunitjs.comdomain to confirm that the same URLs do work on the new site as well, by changing the domain, and confirming the URL is either a 200 OK or a redirect to one.api.qunitjs.comtoqunitjs.comand update DNS forapi.qunitjs.comaway from GitHub Pages and to our redirect service instead.docs/directory in this repo. This might trigger a GitHub Pages build to put non-API content on the API subdomain, but will either fail or invisibly succeed since that domain no longer points to GitHub. We do this step before the next, so that GitHub has the new content ready to be served.api.qunitjs.comtoqunitjs.com.qunitjs.com.