all: Fix broken links and add GitHub Actions workflow for link checking#903
all: Fix broken links and add GitHub Actions workflow for link checking#903Mossaka merged 5 commits intocontainerd:mainfrom
Conversation
Mossaka
changed the title
jprendes
changed the title
|
I think we need to increase the 5min timeout on the build jobs, it's the second time I see is hitting it. |
Sure! |
|
Just to clarify, do you want me to bump the timeout in this PR? @jprendes |
|
No, doesn't need to be here. |
devigned
left a comment
devigned
left a comment
There was a problem hiding this comment.
I added some feedback about different types of links. Please consider the link check timing.
| ### End to End tests | ||
|
|
||
| The e2e test run on [k3s](https://k3s.io/) and [kind](https://kind.sigs.k8s.io/). A test image is built using [oci-tar-builder](./crates/oci-tar-builder/) and is loaded onto the clusters. This test image is not pushed to an external registry so be sure to use the Makefile targets to build the image and load it on the cluster. | ||
| The e2e test run on [k3s](https://k3s.io/) and [kind](https://kind.sigs.k8s.io/). A test image is built using [oci-tar-builder](https://github.com/containerd/runwasi/tree/main/crates/oci-tar-builder) and is loaded onto the clusters. This test image is not pushed to an external registry so be sure to use the Makefile targets to build the image and load it on the cluster. |
There was a problem hiding this comment.
I think floating links like this would be most desirable in the docs since a PR moving or removing the file should cause a failure of the link check.
There was a problem hiding this comment.
what are floating links? Do you mean links like ./crates/oci-tar-builder/? The issue with this is that in runwasi.dev it can't read links outside of the /docs folder so the linkChecker would fail.
| ## Contributing | ||
|
|
||
| To begin contributing, please read our [Contributing Guide](https://runwasi.dev/developer/contributing.html). | ||
| To begin contributing, please read our [Contributing Guide](https://runwasi.dev/CONTRIBUTING.html). |
There was a problem hiding this comment.
I think anything based on checking runwasi.dev will fail only after runwasi.dev is deployed.
There was a problem hiding this comment.
How about a two phase linking strategy?
- Run link checkers for every PR, skip checking links to
runwasi.devor do not fail the PRs if there are errors related to links not found onrunwasi.dev - Run another link checker for every deployment of the
runwasi.devand make sure that the links are working in the livesite.
There was a problem hiding this comment.
To elaborate more on the second point, I've added a action to create a GitHub issue for broken links it finds at post-deployment of runwasi.dev.
Signed-off-by: Jiaxiao (mossaka) Zhou <duibao55328@gmail.com>
Signed-off-by: Jiaxiao (mossaka) Zhou <duibao55328@gmail.com>
Signed-off-by: Jiaxiao (mossaka) Zhou <duibao55328@gmail.com>
Signed-off-by: Jiaxiao (mossaka) Zhou <duibao55328@gmail.com>
This workflow runs after the deployment of the runwasi.dev website to check for broken links. Signed-off-by: Jiaxiao (mossaka) Zhou <duibao55328@gmail.com>
3 participants
This PR does two things:
linkCheckerjob to the CI/CD pipelines. It does so in a two-phase checking. The first phase is to run per PR and does not fail the PR if the links are broken. This is becasue links might not be live prior to deployment. The second phase runs after deployment ofrunwasi.devand create or update issues if broken links are found.