[CI & docs] Set up link checker + GH action + fix en links (cncf#3188)

Signed-off-by: Patrice Chalin <[email protected]>

Author: chalin

.github/workflows/check-links.yml

@@ -0,0 +1,18 @@
+name: Links
+
+on:
+  pull_request:
+
+jobs:
+  build-and-check-links:
+    name: CHECK LINKS
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version-file: .nvmrc
+          cache: npm
+          cache-dependency-path: package.json
+      - run: npm install --omit=optional
+      - run: npm run check:links

.gitignore

@@ -1,10 +1,12 @@
 
-public/
-resources/
-node_modules/
-.hugo_build.lock
 .DS_Store
+.hugo_build.lock
+/public
+/resources
+node_modules/
+package-lock.json
 pagefind
+tmp/
 
 # Local Netlify folder
 .netlify

.htmltest.yml

@@ -0,0 +1,8 @@
+# cSpell:ignore pagefind regexs
+DirectoryPath: public
+# IgnoreDirectoryMissingTrailingSlash: true # FIXME
+IgnoreInternalEmptyHash: true # FIXME
+IgnoreDirs:
+  - ^(bn|de|es|fr|hi|it|ja|ko|pt.*?|ru|tr|ur|zh.*?)/
+IgnoreURLs: # list of regexs of paths or URLs to be ignored
+  - ^/pagefind

.nvmrc

@@ -0,0 +1 @@
+lts/*

Makefile

@@ -1,5 +1,27 @@
+HTMLTEST_DIR=tmp
+HTMLTEST?=htmltest # Specify as make arg if different
+HTMLTEST_ARGS?=--skip-external
+
+# Use $(HTMLTEST) in PATH, if available; otherwise, we'll get a copy
+ifeq (, $(shell which $(HTMLTEST)))
+override HTMLTEST=$(HTMLTEST_DIR)/bin/htmltest
+ifeq (, $(shell which $(HTMLTEST)))
+GET_LINK_CHECKER_IF_NEEDED=get-link-checker
+endif
+endif
+
+check-links: $(GET_LINK_CHECKER_IF_NEEDED)
+	$(HTMLTEST) $(HTMLTEST_ARGS)
+
+clean:
+	rm -rf $(HTMLTEST_DIR) public/* resources
+
+get-link-checker:
+	rm -Rf $(HTMLTEST_DIR)/bin
+	curl https://htmltest.wjdp.uk | bash -s -- -b $(HTMLTEST_DIR)/bin
+
 serve:
-	hugo server \
+	npx hugo server \
 		--disableFastRender \
 		--buildDrafts \
 		--buildFuture \
@@ -13,16 +35,15 @@ serve:
 		--gc
 
 production-build:
-	git submodule update --init --recursive
-	hugo \
-		--minify
+	npm run get:submodule
+	npx hugo --minify
 	npx -y pagefind --site public
 
 preview-build:
 	git submodule update --init --recursive
-	hugo \
+	npx hugo \
 		--baseURL $(DEPLOY_PRIME_URL) \
 		--buildDrafts \
 		--buildFuture \
 		--minify
-	npx -y pagefind --site public
+	npx -y pagefind --site public

README.md

@@ -13,19 +13,19 @@ If you'd like to help with the glossary we'd love to have your contributions! Pl
 ## Acknowledgements
 
 The Cloud Native Glossary was initiated by the CNCF Marketing Committee
-(Business Value Subcommittee) and includes contributions from 
-[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), 
-[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/), 
-[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), 
-[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), 
-[Katelin Ramer](https://www.linkedin.com/in/katelinramer/), 
-[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca), 
-and many more contributors. 
+(Business Value Subcommittee) and includes contributions from
+[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/),
+[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/),
+[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk),
+[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/),
+[Katelin Ramer](https://www.linkedin.com/in/katelinramer/),
+[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca),
+and many more contributors.
 For a complete contributor list, please refer to [this GitHub page](https://github.com/cncf/glossary/graphs/contributors).
 
-The Glossary is maintained by 
+The Glossary is maintained by
 [Seokho Son](https://www.linkedin.com/in/seokho-son/),
-[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/), 
+[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/),
 [Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/),
 [Nate W.](https://www.linkedin.com/in/nate-double-u/),
 and [Jorge Castro](https://www.linkedin.com/in/jorge-castro2112/).
@@ -43,10 +43,8 @@ All code contributions are under the Apache 2.0 license. Documentation is distri
 
 To improve the Cloud Native Glossary site itself, install a local copy with these instructions. Note you must have [npm](https://www.npmjs.com/) and [Hugo](https://gohugo.io/) installed.
 
-```
+```sh
 git clone https://github.com/cncf/glossary.git
-cd glossary
-git submodule update --init --recursive
 npm install
 ```
 

content/en/container-orchestration.md

@@ -4,19 +4,19 @@ status: Completed
 category: Concept
 ---
 
-[Container](/container/) orchestration refers to managing and automating the lifecycle of [containerized](/containerization/) applications in dynamic environments. 
-It's executed through a container orchestrator (in most cases, [Kubernetes](/kubernetes)), which enables deployments, (auto)scaling, auto-healing, and monitoring. 
+[Container](/container/) orchestration refers to managing and automating the lifecycle of [containerized](/containerization/) applications in dynamic environments.
+It's executed through a container orchestrator (in most cases, [Kubernetes](/kubernetes/)), which enables deployments, (auto)scaling, auto-healing, and monitoring.
 Orchestration is a metaphor:
-The orchestration tool conducts containers like a music conductor, ensuring every container (or musician) does what it should. 
+The orchestration tool conducts containers like a music conductor, ensuring every container (or musician) does what it should.
 
-## Problem it addresses 
+## Problem it addresses
 
-Managing [microservices](/microservices), security, and network communication at scale — and [distributed systems](/distributed-systems) in general — is hard, if not impossible, to manage manually.
-Container orchestration allows users to automate all these management tasks. 
+Managing [microservices](/microservices-architecture/), security, and network communication at scale — and [distributed systems](/distributed-systems/) in general — is hard, if not impossible, to manage manually.
+Container orchestration allows users to automate all these management tasks.
 
 ## How it helps
 
-Container orchestration tools allow users to determine a system's state. 
+Container orchestration tools allow users to determine a system's state.
 First, they declare how it should look like (e.g., x containers, y pods, etc.).
-The orchestration tool will then automatically monitor the infrastructure and correct it if its state deviates from the declared one (e.g., spin up a new container if one crashes). 
+The orchestration tool will then automatically monitor the infrastructure and correct it if its state deviates from the declared one (e.g., spin up a new container if one crashes).
 This automation simplifies many of the engineering teams' otherwise highly manual and complex operational tasks, including provisioning, deployment, scaling (up and down), networking, load balancing, and other activities.

content/en/loosely-coupled-architecture.md

@@ -5,15 +5,15 @@ category: Property
 tags: ["fundamental", "architecture", "property"]
 ---
 
-Loosely coupled architecture is an architectural style 
-where the individual components of an application are built independently from one another 
-(the opposite paradigm of [tightly coupled architectures](/tightly-coupled-architectures/)). 
-Each component, sometimes referred to as a [microservice](/microservices-architecture/), is built to perform a specific function 
-in a way that can be used by any number of other services. 
-This pattern is generally slower to implement than tightly coupled architecture 
+Loosely coupled architecture is an architectural style
+where the individual components of an application are built independently from one another
+(the opposite paradigm of [tightly coupled architectures](/tightly-coupled-architecture/)).
+Each component, sometimes referred to as a [microservice](/microservices-architecture/), is built to perform a specific function
+in a way that can be used by any number of other services.
+This pattern is generally slower to implement than tightly coupled architecture
 but has a number of benefits, particularly as applications scale.
 
-Loosely coupled applications allow teams to develop features, deploy, and scale independently, 
-which allows organizations to iterate quickly on individual components. 
-Application development is faster and teams can be structured around their competency, 
-focusing on their specific application. 
+Loosely coupled applications allow teams to develop features, deploy, and scale independently,
+which allows organizations to iterate quickly on individual components.
+Application development is faster and teams can be structured around their competency,
+focusing on their specific application.

content/en/microservices-architecture.md

@@ -5,31 +5,31 @@ tags: ["architecture", "fundamental", ""]
 ---
 
 A microservices architecture is an architectural approach that breaks applications into individual independent (micro)[services](/service/), with each service focused on a specific functionality.
-These services work together closely, appearing to the end user as a single entity. 
-Take Netflix as an example. 
-Its interface allows you to access, search, and preview videos. 
+These services work together closely, appearing to the end user as a single entity.
+Take Netflix as an example.
+Its interface allows you to access, search, and preview videos.
 These capabilities are likely powered by smaller services that each handle one functionality, e.g., authentication, search, and running previews in your browser.
 
 This architectural approach allows developers to push out new features or update functionality much faster than if they were all tightly coupled, such as in a [monolithic application](/monolithic-apps/) (more to that below).
 
 ## Problem it addresses
 
-Applications are made up of different parts, each responsible for a specific capability. 
-Demand for a particular functionality will not necessarily increase or decrease with demand for other app parts. 
-Going back to our Netflix example. 
-Let's say that after a big marketing campaign, Netflix experiences a big spike in signups, but streaming has remained more or less stable in the early hours of the day.  
-The surge in signups demands more signup capacity. 
-Traditionally (monolithic approach), the entire app would have to be [scaled](/scalability/) to accommodate the increase — a very inefficient use of resources. 
+Applications are made up of different parts, each responsible for a specific capability.
+Demand for a particular functionality will not necessarily increase or decrease with demand for other app parts.
+Going back to our Netflix example.
+Let's say that after a big marketing campaign, Netflix experiences a big spike in signups, but streaming has remained more or less stable in the early hours of the day.
+The surge in signups demands more signup capacity.
+Traditionally (monolithic approach), the entire app would have to be [scaled](/scalability/) to accommodate the increase — a very inefficient use of resources.
 
-Monolithic architectures also make it easy for developers to succumb to design pitfalls. 
-Because all the code is in one place, it is easier to make that code [tightly coupled](/tightly-coupled-architectures/) and harder to enforce the principle of separation of concerns. 
-Monoliths also often require developers to understand the entire codebase before deploying any changes. 
-Microservices architecture is a response to these challenges.  
+Monolithic architectures also make it easy for developers to succumb to design pitfalls.
+Because all the code is in one place, it is easier to make that code [tightly coupled](/tightly-coupled-architecture/) and harder to enforce the principle of separation of concerns.
+Monoliths also often require developers to understand the entire codebase before deploying any changes.
+Microservices architecture is a response to these challenges.
 
 
 ## How it helps
 
-Separating functionality into different microservices makes them easier to deploy, update, and scale independently. 
-It also allows different teams to work simultaneously on a small part of a bigger application without inadvertently negatively impacting the rest of the app. 
-While a microservices architecture solves many problems, it also creates operational overhead — the things you need to deploy and keep track of increase by order of magnitude. 
+Separating functionality into different microservices makes them easier to deploy, update, and scale independently.
+It also allows different teams to work simultaneously on a small part of a bigger application without inadvertently negatively impacting the rest of the app.
+While a microservices architecture solves many problems, it also creates operational overhead — the things you need to deploy and keep track of increase by order of magnitude.
 Many [cloud-native technologies](/cloud-native-tech/) aim to make microservices easier to deploy and manage.

content/en/stateful-apps.md

@@ -5,12 +5,12 @@ category: Property
 tags: ["fundamental", "application", "property"]
 ---
 
-When we speak of stateful (and [stateless](/stateless-apps/)) apps, 
-state refers to any data the app needs to store to function as designed. 
-Any kind of online shop that remembers your cart is a stateful app for example. 
+When we speak of stateful (and [stateless](/stateless-apps/)) apps,
+state refers to any data the app needs to store to function as designed.
+Any kind of online shop that remembers your cart is a stateful app for example.
 
-Today, most applications we use are at least partly stateful. In cloud native environments though, 
-stateful apps are a challenge. This is because [cloud native apps](/cloud-native-apps) are very dynamic. 
+Today, most applications we use are at least partly stateful. In cloud native environments though,
+stateful apps are a challenge. This is because [cloud native apps](/cloud-native-apps/) are very dynamic.
 They can be scaled up and down, restarted, and moved around but still need to be able to access their state.
 
 Therefore, stateful apps needs some kind of storage that is accessible from anywhere, like databases.