Highlight some code-blocks with 'console' label
Update the dracula theme styles to make 'console' highlighting more legible
This commit is contained in:
parent
791cd692c6
commit
449a41aa85
@ -25,7 +25,7 @@ System.no_halt(true)
|
||||
|
||||
When we run this script with just `elixir` (instead of `iex`), we should still see an interactive IEx session start.
|
||||
|
||||
```bash
|
||||
```console
|
||||
$ elixir run.exs
|
||||
Erlang/OTP 26 [erts-14.1] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit:ns]
|
||||
|
||||
|
||||
@ -7,14 +7,14 @@ I use Docker mostly when working on software projects and I figured out how to g
|
||||
|
||||
1. Start a container with X11 forwarding:
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run -it --rm --net=host -e "DISPLAY" -e "NO_AT_BRIDGE=1" \
|
||||
-v "$XAUTHORITY:/root/.Xauthority:rw" elixir bash
|
||||
```
|
||||
|
||||
2. Build ["the recommended minimal PLT for Erlang/OTP"](https://www.erlang.org/doc/apps/dialyzer/dialyzer_chapter#the-persistent-lookup-table):
|
||||
|
||||
```
|
||||
```console
|
||||
# dialyzer --build_plt --apps erts kernel stdlib mnesia
|
||||
Creating PLT /root/.cache/erlang/.dialyzer_plt ...
|
||||
...
|
||||
@ -25,20 +25,22 @@ I use Docker mostly when working on software projects and I figured out how to g
|
||||
|
||||
a. From the command line:
|
||||
|
||||
```console
|
||||
# dialyzer --gui
|
||||
```
|
||||
|
||||
b. From inside an IEx session:
|
||||
|
||||
1. Start the Dialyzer application:
|
||||
|
||||
```elixir
|
||||
```
|
||||
iex(1)> Application.load(:dialyzer)
|
||||
:ok
|
||||
```
|
||||
|
||||
2. Start the Dialyzer GUI:
|
||||
|
||||
```elixir
|
||||
```
|
||||
iex(2)> :dialyzer.gui()
|
||||
```
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ We're going to do this whole thing with containers. That means Docker is all we
|
||||
|
||||
We use the `mix new` command to create our Elixir project. If we were using Elixir installed natively on our computer, it would just be the last part, `mix new static_site`. Since we are using Docker, the command looks like this:
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run --rm -w /opt -v $PWD:/opt -u $(id -u):$(id -u) elixir mix new static_site
|
||||
```
|
||||
|
||||
@ -64,7 +64,7 @@ That might look a bit overwhelming, so let's explain each part of the command.
|
||||
|
||||
After the command finishes, we have a new directory on our filesystem called `static_site`. Let's change into that directory and make sure we can run the tests. We don't care if the files `mix` creates in `_build` are owned by `root`, so we don't bother setting the user and group with the `-u` option when we run the command this time.
|
||||
|
||||
```
|
||||
```console
|
||||
$ cd static_site
|
||||
$ docker run --rm -w /opt -v $PWD:/opt elixir mix test
|
||||
```
|
||||
@ -112,13 +112,13 @@ end
|
||||
|
||||
The easiest way to test our task is to run `mix build` and then inspect the contents of `/public/index.html` with the `cat` command, but `docker run` only accepts a single command. We can combine both into one with `bash -c "mix build && cat /public/index.html"`.
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run --rm -w /opt -v $PWD:/opt elixir bash -c "mix build && cat /public/index.html"
|
||||
```
|
||||
|
||||
If all went well, our output should be:
|
||||
|
||||
```
|
||||
```console
|
||||
running build task
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
@ -154,7 +154,7 @@ end
|
||||
|
||||
We will also have to add a call to `mix deps.get` in our command. Again, we combine the two commands into one with `&&`:
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run --rm -w /opt -v $PWD:/opt elixir bash -c "mix deps.get && mix build"
|
||||
* creating /root/.mix/archives/hex-2.0.6
|
||||
Resolving Hex dependencies...
|
||||
@ -176,7 +176,7 @@ There is a problem with this method, however. What if the dependencies are only
|
||||
|
||||
We will re-run our command, but we will add a call to `mix deps` to see what dependencies our project builds.
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run --rm -w /opt -v $PWD:/opt elixir bash -c "mix deps.get && mix build && mix deps"
|
||||
...
|
||||
Compiling 2 files (.ex)
|
||||
@ -202,7 +202,7 @@ Our `dev` environment has the dependency we added.
|
||||
|
||||
Now, we will run the command again after we set the environment variable `MIX_ENV` to `prod`. We do this with the `-e` option:
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run --rm -w /opt -v $PWD:/opt -e MIX_ENV=prod elixir bash -c "mix deps.get && mix build && mix deps"
|
||||
* creating /root/.mix/archives/hex-2.0.6
|
||||
Resolving Hex dependencies...
|
||||
@ -223,7 +223,7 @@ running build task
|
||||
|
||||
It turns out that `mix deps.get` [has an `--only` option](https://hexdocs.pm/mix/Mix.Tasks.Deps.Get.html) that can be used to fetch dependencies only for a specific environment. We try our command again with that option.
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run --rm -w /opt -v $PWD:/opt -e MIX_ENV=prod elixir bash -c "mix deps.get --only prod && mix build && mix deps"
|
||||
* creating /root/.mix/archives/hex-2.0.6
|
||||
All dependencies are up to date
|
||||
@ -283,13 +283,13 @@ With that complete, we can now build an image.
|
||||
|
||||
This first build will not have the `MIX_ENV` variable set, so we expect it to default to `dev` and to find the `plug` dependency installed.
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker build -t hw_dev .
|
||||
```
|
||||
|
||||
Let's see what dependencies our image contains:
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run --rm hw_dev mix deps
|
||||
|
||||
* mime 2.0.5 (Hex package) (mix)
|
||||
@ -308,7 +308,7 @@ $ docker run --rm hw_dev mix deps
|
||||
|
||||
That looks good. And let's also check that our HTML file was written:
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run --rm hw_dev ls /public
|
||||
index.html
|
||||
```
|
||||
@ -317,20 +317,20 @@ index.html
|
||||
|
||||
Excellent. Now let's build a production image. We pass in the value to set for the `MIX_ENV` argument with the `--build-arg` option:
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker build -t hw_prod --build-arg MIX_ENV=prod .
|
||||
```
|
||||
|
||||
And now we check as before. We have to set `MIX_ENV` in the container if we want our mix command to run in that environment. We do this with the `-e` option.
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run --rm -e MIX_ENV=prod hw_prod mix deps
|
||||
$
|
||||
```
|
||||
|
||||
This shows no dependencies, as expected. And check our index.html:
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run --rm hw_prod ls /public
|
||||
index.html
|
||||
```
|
||||
|
||||
@ -51,7 +51,7 @@ end
|
||||
|
||||
Let's try running the test.
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run --rm -w /opt -v $PWD:/opt hw_dev mix test
|
||||
running build task
|
||||
...
|
||||
@ -197,7 +197,7 @@ File.write("index.html", """
|
||||
|
||||
After running the test,
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run --rm -w /opt -v $PWD:/opt hw_dev mix test
|
||||
running build task
|
||||
...
|
||||
@ -207,7 +207,7 @@ Finished in 0.02 seconds (0.02s async, 0.00s sync)
|
||||
|
||||
we have our test directory, `test/mix/tmp`,
|
||||
|
||||
```
|
||||
```console
|
||||
$ find test/mix/tmp
|
||||
test/mix/tmp
|
||||
test/mix/tmp/build
|
||||
@ -218,7 +218,7 @@ test/mix/tmp/build/index.html
|
||||
|
||||
and our fixture file.
|
||||
|
||||
```
|
||||
```console
|
||||
$ cat test/mix/tmp/build/index.html
|
||||
<!-- Auto-generated fixture -->
|
||||
<!DOCTYPE html>
|
||||
@ -240,7 +240,7 @@ end)
|
||||
|
||||
Now, after we run the tests, all the files and directories created during the test run have been removed.
|
||||
|
||||
```
|
||||
```console
|
||||
$ find test/mix/tmp/
|
||||
find: ‘test/mix/tmp/’: No such file or directory
|
||||
```
|
||||
@ -258,7 +258,7 @@ capture_io(fn -> Mix.Tasks.Build.run([]) end)
|
||||
|
||||
When we run our tests now, there are no more IO messages cluttering up the test results.
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker run --rm -w /opt -v $PWD:/opt hw_dev mix test
|
||||
...
|
||||
Finished in 0.02 seconds (0.02s async, 0.00s sync)
|
||||
|
||||
@ -29,8 +29,11 @@ span.linenos.special { color: #50fa7b; background-color: #6272a4; padding-left:
|
||||
.highlight .py-gr { color: #f8f8f2 } /* Generic.Error */
|
||||
.highlight .py-gh { color: #f8f8f2; font-weight: bold } /* Generic.Heading */
|
||||
.highlight .py-gi { color: #f8f8f2; font-weight: bold } /* Generic.Inserted */
|
||||
.highlight .py-go { color: #44475a } /* Generic.Output */
|
||||
.highlight .py-gp { color: #f8f8f2 } /* Generic.Prompt */
|
||||
/*.highlight .py-go { color: #44475a } /* Generic.Output */
|
||||
/*.highlight .py-go { color: #6272a4; } /* Generic.Output */
|
||||
.highlight .py-go { color: #f8f8f2 } /* Generic.Output */
|
||||
/*.highlight .py-gp { color: #f8f8f2 } /* Generic.Prompt */
|
||||
.highlight .py-gp { color: #50fa7b } /* Generic.Prompt */
|
||||
.highlight .py-gs { color: #f8f8f2 } /* Generic.Strong */
|
||||
.highlight .py-gu { color: #f8f8f2; font-weight: bold } /* Generic.Subheading */
|
||||
.highlight .py-gt { color: #f8f8f2 } /* Generic.Traceback */
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user