parent
e4bb17142c
commit
2a992e2092
@ -1,56 +1,95 @@
|
||||
# prezto docker container
|
||||
# Prezto Docker Container
|
||||
|
||||
This branch contains a Dockerfile and a Makefile that hopefully may
|
||||
prove helpful for prezto development.
|
||||
|
||||
The idea is to have a totally independendn and isolated environemnet
|
||||
in which to quickly make changes to either prezto-core or any plugin
|
||||
that may bein development, enabling automated testing and even
|
||||
continuous integration.
|
||||
The idea is to have a totally independent and isolated environemnet
|
||||
in which to test changes to either prezto-core or any plugin that you
|
||||
may be working on, **without disrupting your environment**, thus enabling
|
||||
automated testing and even continuous integration.
|
||||
|
||||
This is a proof of concept, it may not be even a good idea to have
|
||||
this on the main prezto repository. on the other hand, the container
|
||||
image should depend on the code, so if the team finds this to be a
|
||||
useful tool, there are choices to be made in that respect. My
|
||||
intention is to introduce this as a helpful tool for development and
|
||||
for new users to try prezto easely
|
||||
|
||||
Here is a screencast showing what the container can do so far
|
||||
|
||||
[![asciicast](https://asciinema.org/a/277054.svg)](https://asciinema.org/a/277054)
|
||||
|
||||
The container is a basic install of alpine linux, so the image
|
||||
download is reasonably small
|
||||
The container is a basic install of [alpine linux][1] so the download
|
||||
is reasonably small at around 200M, since debian based images can
|
||||
weigh in around 1.5G.
|
||||
|
||||
On the container we have a few utilities and additional software that
|
||||
prezto has core support for, and you can check it out in a snap by doing:
|
||||
prezto has core support for, (tmux, make, etc) and you can try it i
|
||||
easily by running:
|
||||
|
||||
```bash
|
||||
docker pull hlecuanda/prezto-dev:latest
|
||||
```
|
||||
once you have the image, create a container from it with:
|
||||
|
||||
once you have the image, create a container from it:
|
||||
|
||||
```bash
|
||||
docker run -it --rm -h prezto hlecuanda/prezto-dev:latest
|
||||
```
|
||||
|
||||
That will set you on a prompt within the container with a
|
||||
vanilla install of prezto.
|
||||
That will create an interactive (`--it`) ephemeral container (`--rm`)
|
||||
whose hostname is prezto (`-h prezto`) based on the aforementioned
|
||||
imag. you should be sitting at the plain sorin prompt in a brand new
|
||||
prezto instance.
|
||||
|
||||
A development and testing workflow can be achieved by mounting the stuff
|
||||
you're working on to the image's filesystem:
|
||||
A development and testing workflow can be achieved by mounting a
|
||||
project's directory on to the image's filesystem:
|
||||
|
||||
```bash
|
||||
cd /path/to/project/root
|
||||
docker run -it --rm -h prezto \
|
||||
-v /local/path:/home/prezto \
|
||||
-v /local/path/zdotdir:/home/preztoa \
|
||||
-v /local/module-dev-src:/home/prezto/.zprezto/modules/yourmodulea \
|
||||
-v $(pwd):/home/prezto/.zprezto/modules/${:-$(pwd):t} \
|
||||
hlecuanda/prezto-dev:latest
|
||||
```
|
||||
|
||||
the third volume mapping is particularly interesting. you can
|
||||
develop on your own machine and environnment, and when spinning up the
|
||||
container, your actual source is already in-plase as if installed on a
|
||||
vanilla prezto instance
|
||||
This will mount the current directory on the container's filesystem,
|
||||
you can develop on your own machine and environnment, and test your
|
||||
changes running on the container, your actual source will already be
|
||||
in-place on prezto's directory hierarchy, as if it was just cloned
|
||||
recursively (v.gr for modules with extenral dependencies)
|
||||
|
||||
Keep in mind that the containers created in this fashion are ephemeral,
|
||||
so anything you write on the contain'ers filesystem will be lost,
|
||||
unless you remove the `--rm` option like so:
|
||||
|
||||
keep in mind that the container are ephemeral, unless you remove the
|
||||
`--rm` option which will create new containers each time you run the
|
||||
command, but the changes to the filesystemwill persist on a container
|
||||
file that you can later spin up again to re-use.
|
||||
```bash
|
||||
cd /path/to/project/root
|
||||
docker run -it -h prezto --name prezto \
|
||||
-v $(pwd):/home/prezto/.zprezto/modules/${:-$(pwd):t} \
|
||||
hlecuanda/prezto-dev:latest
|
||||
```
|
||||
This will create a container named prezto, (`--name prezto`) with it's
|
||||
hostname set to prezto also (`-h prezto`) that will retain changes
|
||||
made to it's filesystem. When you detach, the container willi stop and
|
||||
you can spinit up again using:
|
||||
|
||||
```bash
|
||||
docker start -ai prezto
|
||||
```
|
||||
|
||||
Containers started this way will remember the volume mounts they were
|
||||
created with, so the project directory we previously mounted with
|
||||
`-v` on the `docker run` command, will be ready on the image.
|
||||
|
||||
I have found epehermeral containers to be most useful since you get an
|
||||
untainted, pristine environment for testing every time you spin up the
|
||||
container.
|
||||
|
||||
Since the docker commands can be a bit verbose, the included Makefile
|
||||
automates some of the frequent steps in the workflow, although it can
|
||||
be replaced by shell functions quite easily;
|
||||
|
||||
<script src="https://gist.github.com/hlecuanda/78a6a39877c9753230a11c2d8832f4b6.js"></script>
|
||||
|
||||
hope this turns out to be useful.
|
||||
[1]:https://alpinelinux.org
|
||||
|
Loading…
Reference in new issue