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
|
This branch contains a Dockerfile and a Makefile that hopefully may
|
||||||
prove helpful for prezto development.
|
prove helpful for prezto development.
|
||||||
|
|
||||||
The idea is to have a totally independendn and isolated environemnet
|
The idea is to have a totally independent and isolated environemnet
|
||||||
in which to quickly make changes to either prezto-core or any plugin
|
in which to test changes to either prezto-core or any plugin that you
|
||||||
that may bein development, enabling automated testing and even
|
may be working on, **without disrupting your environment**, thus enabling
|
||||||
continuous integration.
|
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)
|
[![asciicast](https://asciinema.org/a/277054.svg)](https://asciinema.org/a/277054)
|
||||||
|
|
||||||
The container is a basic install of alpine linux, so the image
|
The container is a basic install of [alpine linux][1] so the download
|
||||||
download is reasonably small
|
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
|
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
|
```bash
|
||||||
docker pull hlecuanda/prezto-dev:latest
|
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
|
```bash
|
||||||
docker run -it --rm -h prezto hlecuanda/prezto-dev:latest
|
docker run -it --rm -h prezto hlecuanda/prezto-dev:latest
|
||||||
```
|
```
|
||||||
|
|
||||||
That will set you on a prompt within the container with a
|
That will create an interactive (`--it`) ephemeral container (`--rm`)
|
||||||
vanilla install of prezto.
|
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
|
A development and testing workflow can be achieved by mounting a
|
||||||
you're working on to the image's filesystem:
|
project's directory on to the image's filesystem:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
|
cd /path/to/project/root
|
||||||
docker run -it --rm -h prezto \
|
docker run -it --rm -h prezto \
|
||||||
-v /local/path:/home/prezto \
|
-v $(pwd):/home/prezto/.zprezto/modules/${:-$(pwd):t} \
|
||||||
-v /local/path/zdotdir:/home/preztoa \
|
|
||||||
-v /local/module-dev-src:/home/prezto/.zprezto/modules/yourmodulea \
|
|
||||||
hlecuanda/prezto-dev:latest
|
hlecuanda/prezto-dev:latest
|
||||||
```
|
```
|
||||||
|
|
||||||
the third volume mapping is particularly interesting. you can
|
This will mount the current directory on the container's filesystem,
|
||||||
develop on your own machine and environnment, and when spinning up the
|
you can develop on your own machine and environnment, and test your
|
||||||
container, your actual source is already in-plase as if installed on a
|
changes running on the container, your actual source will already be
|
||||||
vanilla prezto instance
|
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
|
```bash
|
||||||
`--rm` option which will create new containers each time you run the
|
cd /path/to/project/root
|
||||||
command, but the changes to the filesystemwill persist on a container
|
docker run -it -h prezto --name prezto \
|
||||||
file that you can later spin up again to re-use.
|
-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
|
I have found epehermeral containers to be most useful since you get an
|
||||||
untainted, pristine environment for testing every time you spin up the
|
untainted, pristine environment for testing every time you spin up the
|
||||||
container.
|
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.
|
hope this turns out to be useful.
|
||||||
|
[1]:https://alpinelinux.org
|
||||||
|
Loading…
Reference in new issue