Merge pull request #2173 from slumbering/docs-warning-banner

website: hardcode version banner for 0.1 docs

docs/guides/1205-container-images.md

@@ -1,6 +1,6 @@
 ---
 slug: /1205/container-images
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Building container images
@@ -11,9 +11,10 @@ You can use Dagger to build container images, either by executing a Dockerfile,
 
 Dagger can natively load and execute Dockerfiles. This is recommended in cases where compatibility with existing Dockerfiles is more important than fully leveraging the power of CUE.
 
- Here's a simple example of a [Dockerfile](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) build:
+Here's a simple example of a [Dockerfile](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) build:
 
 ```cue file=../tests/core-concepts/container-images/simple/with-dockerfile.cue
+
 ```
 
 ## Specifying a build in CUE
@@ -23,6 +24,7 @@ You can specify your container build natively in CUE, using the official Docker
 Native CUE builds have the same backend as Dockerfile builds, so all the same features are available. Since CUE is a more powerful language than the Dockerfile syntax, every Dockerfile can be ported to an equivalent CUE configuration, but the opposite is not true. The following example produces the same image as above.
 
 ```cue file=../tests/core-concepts/container-images/simple/build.cue
+
 ```
 
 Because this build configuration is pure CUE, it can leverage the full power of Dagger's composition model.
@@ -32,6 +34,7 @@ Because this build configuration is pure CUE, it can leverage the full power of
 Building images in CUE gives you greater flexibility. For example, you can automate building multiple versions of an image, and deploy, all in Dagger:
 
 ```cue file=../tests/core-concepts/container-images/template/dagger.cue
+
 ```
 
 Now you can deploy all versions:
@@ -51,4 +54,5 @@ dagger do versions 8.0 build
 Another common pattern is [multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds). This allows you to have heavier build images during the build process, and copy the built artifacts into a cleaner and lighter image to run in production.
 
 ```cue file=../tests/core-concepts/container-images/multi-stage/dagger.cue
+
 ```

docs/guides/1216-docker-cli-load.md

@@ -1,6 +1,6 @@
 ---
 slug: /1216/docker-cli-load
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Loading a dagger image into a docker daemon
@@ -12,9 +12,11 @@ It can be useful to debug or test a build locally before pushing.
 ## Local daemon
 
 ```cue file=../plans/docker-cli-load/local.cue
+
 ```
 
 ## Remote daemon, via SSH
 
 ```cue file=../plans/docker-cli-load/ssh.cue
+
 ```

docs/guides/1217-docker-cli-run.md

@@ -1,6 +1,6 @@
 ---
 slug: /1217/docker-cli-run
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Running commands with the docker binary (CLI)
@@ -10,14 +10,17 @@ There's a `universe.dagger.io/docker/cli` package that allows you to run docker
 ## Local daemon
 
 ```cue file=../plans/docker-cli-run/local.cue
+
 ```
 
 ## Remote daemon, via SSH
 
 ```cue file=../plans/docker-cli-run/ssh.cue
+
 ```
 
 ## Remote daemon, via HTTPS
 
 ```cue file=../plans/docker-cli-run/tcp.cue
+
 ```

docs/guides/1218-cli-telemetry.md

@@ -1,6 +1,6 @@
 ---
 slug: /1218/cli-telemetry
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Understanding CLI Telemetry
@@ -15,10 +15,10 @@ us better understand how Dagger is used, and will allow us to improve your exper
 
 The following information is included in telemetry:
 
-* Dagger version
-* Platform information
-* Command run
-* Anonymous device ID
+- Dagger version
+- Platform information
+- Command run
+- Anonymous device ID
 
 We use telemetry for aggregate analysis, and do not tie telemetry events to a specific identity.
 

docs/guides/1226-coding-style.md

@@ -1,6 +1,6 @@
 ---
 slug: /1226/coding-style
-displayed_sidebar: europa
+displayed_sidebar: '0.2'
 ---
 
 # Package Coding Style
@@ -59,7 +59,7 @@ Choose `_camelCase` for private fields (implementation details).
 }
 ```
 
-## Definitions for *schemas*, fields for concrete *implementations*
+## Definitions for _schemas_, fields for concrete _implementations_
 
 ```cue
 // good, defines a schema
@@ -187,7 +187,7 @@ run: bash.#Run & {
 
 ## Don’t inline scripts
 
-Avoid inlining scripts (e.g., *sh*, *py*, etc). Instead, put them in their own files
+Avoid inlining scripts (e.g., _sh_, _py_, etc). Instead, put them in their own files
 with proper extension, and use `core.#Source` to import into CUE. This allows linting
 and avoids some limitations (script size, escaping).
 
@@ -259,7 +259,7 @@ run: python.#Run & {
 }
 ```
 
-## Favor disjunctions over *if* conditions
+## Favor disjunctions over _if_ conditions
 
 ```cue
 // bad
@@ -283,7 +283,7 @@ if type == "cache" {
 }
 ```
 
-## Favor templates over *for* loops
+## Favor templates over _for_ loops
 
 ```cue
 // bad
@@ -334,11 +334,11 @@ files: {
 }
 ```
 
-## Use *top* to match anything
+## Use _top_ to match anything
 
 From [CUE](https://cuelang.org/docs/references/spec/#values-1):
 
-> At the top of the lattice is the single ancestor of all values, called *top*, denoted `_` in CUE. Every value is an instance of top.
+> At the top of the lattice is the single ancestor of all values, called _top_, denoted `_` in CUE. Every value is an instance of top.
 
 There's a recurring theme when you have a template and need to create instances from it: