I guess this is fine to keep as a ```bash block, but when we test this doc, this block will effectively be a nop (since we've already installed the packages in the section above. But atleast we will be running this code I guess.

How about this though - create a new section between the two existing sections:

To remove the Kata Packages

$ bash -c "$(curl -fsSL https://raw.githubusercontent.com/kata-containers/tests/master/cmd/kata-manager/kata-manager.sh) remove-packages"

That way, when we test this doc by executing the code blocks from top to bottom we'll:

1. Install a docker system (with Kata packages).
2. Remove the Kata packages.
3. Re-install the Kata packages.

😄

That's a smart idea, but the doc should be made for humans and not for the tests to pass. What about adding the remove-packages in the CI script? Or have a CI job dedicated to installing with kata manager.

That's a smart idea, but the doc should be made for humans and not for the tests to pass.

Unless, of course, our target users are AI monsters 😛

I agree. The problem is that to avoid completely reworking the CI, the docs are executed as scripts from top to bottom. So if we don't want to add the new section, I'd suggest we leave this document as it is, knowing that the "Install the Kata packages only" section will be executed (but do nothing). Or, we could split the doc into two so that the CI can execute both docs in clean environments.

Kind of a compromise, we could add a html comment with the code to execute?

<!---
Code needed for CI purposes, ignore this comment.

```bash
$ bash -c "$(curl -fsSL https://raw.githubusercontent.com/kata-containers/tests/master/cmd/kata-manager/kata-manager.sh) remove-packages"
```
--->

ps: could you point me to the shell script running all the code blocks in md files?

wfm - atleast we'll be testing the docs!

The script that converts the docs to shell scripts is:

• https://github.com/kata-containers/tests/blob/master/cmd/kata-manager/kata-manager.sh

(btw, have you seen https://github.com/kata-containers/tests/blob/master/.ci/README.md ?)

That script is what https://github.com/kata-containers/tests/tree/master/cmd/kata-manager calls too to avoid duplication.

Just to be sure I am understanding correctly

• static-checks.sh will call kata-doc-to-script.sh to syntax check the content of ```bash code blocks with bash -n.
• .ci/test-install-docs.sh calls kata-manager install-docker-system whenever an update to install/.*md is detected.

No one however will try to install kata using the content of install/installing-with-kata-manager.md.
So adding the extra code in the comment makes sense only if we setup an additional step to install kata using this doc. Am I right?

Yes. But I'm working on improving the CI scripts in this repo to test the remaining install docs (installing-with-kata-manager.md and installing-with-kata-doc-to-script.md) on #278.

repetita iuvant :)

Not strictly part of this PR, but this should say "Configures".

bleh, the first time we have buried HTML in our mardown documents I believe.....