Zsh docker images

Zsh docker images

[Julien Nicoulaud]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

Hi all,

I just wanted to advertise a small project that could be useful to other
zsh users: https://github.com/zsh-users/zsh-docker

This builds images of many versions of zsh (including a daily build of
zsh's master branch) and deploys them to Docker Hub (
https://hub.docker.com/u/zshusers).

So you can do, for instance:

    $ docker run -it zshusers/zsh-5.3.1

-> will launch an interactive session of zsh 5.3.1

We use it to automatically test zsh-syntax-highlighting on all supported
versions of zsh.

Cheers,
Julien

Re: Zsh docker images

[Nikolay Aleksandrovich Pavlov (ZyX)]

15.08.2017, 01:12, "Julien Nicoulaud" <julien.nicoulaud@gmail.com>:
> Hi all,
>
> I just wanted to advertise a small project that could be useful to other
> zsh users: https://github.com/zsh-users/zsh-docker
>
> This builds images of many versions of zsh (including a daily build of
> zsh's master branch) and deploys them to Docker Hub (
> https://hub.docker.com/u/zshusers).
>
> So you can do, for instance:
>
>     $ docker run -it zshusers/zsh-5.3.1
>
> -> will launch an interactive session of zsh 5.3.1
>
> We use it to automatically test zsh-syntax-highlighting on all supported
> versions of zsh.

What you could just as well do without docker which would make travis run faster due to not needed `sudo: required` and ability to setup travis cache. For testing something locally your docker images make more sense because they are easier to use then compiling that big amount of zsh versions.

Also why you have no builds for PRs and why you don’t merge those 24 jobs into something like 7 (4.3*, 5.0*, 5.1*, 5.2*, 5.3*, 5.4*, master)? Less then twenty seconds to run tests in a single job, lots of time to initialize VMs and there is nothing which may prevent you from consequently running two docker commands in one job, or using two zsh versions via other means.

>
> Cheers,
> Julien

Re: Zsh docker images

[Julien Nicoulaud]

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

2017-08-15 0:41 GMT+02:00 Nikolay Aleksandrovich Pavlov (ZyX) <
kp-pav@yandex.ru>:

> 15.08.2017, 01:12, "Julien Nicoulaud" <julien.nicoulaud@gmail.com>:
> > Hi all,
> >
> > I just wanted to advertise a small project that could be useful to other
> > zsh users: https://github.com/zsh-users/zsh-docker
> >
> > This builds images of many versions of zsh (including a daily build of
> > zsh's master branch) and deploys them to Docker Hub (
> > https://hub.docker.com/u/zshusers).
> >
> > So you can do, for instance:
> >
> >     $ docker run -it zshusers/zsh-5.3.1
> >
> > -> will launch an interactive session of zsh 5.3.1
> >
> > We use it to automatically test zsh-syntax-highlighting on all supported
> > versions of zsh.
>
> What you could just as well do without docker which would make travis run
> faster due to not needed `sudo: required` and ability to setup travis
> cache. For testing something locally your docker images make more sense
> because they are easier to use then compiling that big amount of zsh
> versions.
>
You mean, instead of using Docker, building the right zsh version on each
job and use Travis cache ? I am not sure that would work as we would have
to "make install" zsh anyway, so we would need sudo...

The Docker setup makes things very simple on zsh-syntax-highlighting side,
it's only one line (https://github.com/zsh-users/
zsh-syntax-highlighting/blob/master/.travis.yml#L30), so it stays clean and
it's easy to use on other projects as well.


>
> Also why you have no builds for PRs

All those PRs were submitted before we setup Travis-CI, I'm not sure if we
can trigger builds, maybe if contributors rebase their branches ?


> and why you don’t merge those 24 jobs into something like 7 (4.3*, 5.0*,
> 5.1*, 5.2*, 5.3*, 5.4*, master)? Less then twenty seconds to run tests in a
> single job, lots of time to initialize VMs and there is nothing which may
> prevent you from consequently running two docker commands in one job, or
> using two zsh versions via other means.
>
Yeah sure, it was just easier to setup and to get a dashboard with every
version. We want to make it easy for contributors what their pull request
broke. If we start grouping jobs, log files will be harder to analyse.

Currently build time is 5/6 minutes, so I don't see it as a big issue.

>
> >
> > Cheers,
> > Julien
>

Re: Zsh docker images

[Nikolay Aleksandrovich Pavlov (ZyX)]

15.08.2017, 02:19, "Julien Nicoulaud" <julien.nicoulaud@gmail.com>:
> 2017-08-15 0:41 GMT+02:00 Nikolay Aleksandrovich Pavlov (ZyX) <
> kp-pav@yandex.ru>:
>
>>  15.08.2017, 01:12, "Julien Nicoulaud" <julien.nicoulaud@gmail.com>:
>>  > Hi all,
>>  >
>>  > I just wanted to advertise a small project that could be useful to other
>>  > zsh users: https://github.com/zsh-users/zsh-docker
>>  >
>>  > This builds images of many versions of zsh (including a daily build of
>>  > zsh's master branch) and deploys them to Docker Hub (
>>  > https://hub.docker.com/u/zshusers).
>>  >
>>  > So you can do, for instance:
>>  >
>>  > $ docker run -it zshusers/zsh-5.3.1
>>  >
>>  > -> will launch an interactive session of zsh 5.3.1
>>  >
>>  > We use it to automatically test zsh-syntax-highlighting on all supported
>>  > versions of zsh.
>>
>>  What you could just as well do without docker which would make travis run
>>  faster due to not needed `sudo: required` and ability to setup travis
>>  cache. For testing something locally your docker images make more sense
>>  because they are easier to use then compiling that big amount of zsh
>>  versions.
>
> You mean, instead of using Docker, building the right zsh version on each
> job and use Travis cache ? I am not sure that would work as we would have
> to "make install" zsh anyway, so we would need sudo...

1. No, you may just build it with a bot and save an archive. https://github.com/powerline/bot-ci works like this for years, though I only have one zsh version. Binaries are in https://github.com/powerline/deps.
2. You need absolutely no `sudo` for `make install`. Just do user-local installation, something like ~/.local-zsh-$ZSH_VERSION. The *build bot* I referenced above is using container-based builds without sudo, not to mention powerline itself which it builds dependencies for. Works fine for CPython (some variant not provided by travis), zsh, zpython, tmux, fish, rc shell, libvterm, Vim, various Vim plugins and Python packages. This is only a matter of what you pass as a prefix.
3. Actually it is possible to build in the job itself and use travis cache, Neovim works this way. I found it more complicated to setup and it would make build times unpredictable for powerline since I do not hardcode versions like Neovim does.

>
> The Docker setup makes things very simple on zsh-syntax-highlighting side,
> it's only one line (https://github.com/zsh-users/
> zsh-syntax-highlighting/blob/master/.travis.yml#L30), so it stays clean and
> it's easy to use on other projects as well.
>
>>  Also why you have no builds for PRs
>
> All those PRs were submitted before we setup Travis-CI, I'm not sure if we
> can trigger builds, maybe if contributors rebase their branches ?
>
>>  and why you don’t merge those 24 jobs into something like 7 (4.3*, 5.0*,
>>  5.1*, 5.2*, 5.3*, 5.4*, master)? Less then twenty seconds to run tests in a
>>  single job, lots of time to initialize VMs and there is nothing which may
>>  prevent you from consequently running two docker commands in one job, or
>>  using two zsh versions via other means.
>
> Yeah sure, it was just easier to setup and to get a dashboard with every
> version. We want to make it easy for contributors what their pull request
> broke. If we start grouping jobs, log files will be harder to analyse.
>
> Currently build time is 5/6 minutes, so I don't see it as a big issue.

Travis has folds, so you may create a fold for each version and print a summary of “what failed” below for contributors to know what to unfold. (Of course, this works in web interface only.) See https://github.com/ZyX-I/neovim/blob/663ca27d3ac9567bb82fc66141aae67bd80190d2/ci/common/suite.sh for an example, though I must say I have not set up `set [+-]x` well, so some trace lines appear outside folds.

>
>>  >
>>  > Cheers,
>>  > Julien

Re: Zsh docker images

[Julien Nicoulaud]

[-- Attachment #1: Type: text/plain, Size: 4544 bytes --]

Thanks for the tips.

The solution you describe requires way more setup and maintainance than
what we have currently, so I prefer to keep things simple.
zsh-syntax-highlighting is a low activity project, we just need to make
sure tests run in acceptable time, and there is not too much adherence to
Travis-CI.

2017-08-15 10:53 GMT+02:00 Nikolay Aleksandrovich Pavlov (ZyX) <
kp-pav@yandex.ru>:

>
>
> 15.08.2017, 02:19, "Julien Nicoulaud" <julien.nicoulaud@gmail.com>:
> > 2017-08-15 0:41 GMT+02:00 Nikolay Aleksandrovich Pavlov (ZyX) <
> > kp-pav@yandex.ru>:
> >
> >>  15.08.2017, 01:12, "Julien Nicoulaud" <julien.nicoulaud@gmail.com>:
> >>  > Hi all,
> >>  >
> >>  > I just wanted to advertise a small project that could be useful to
> other
> >>  > zsh users: https://github.com/zsh-users/zsh-docker
> >>  >
> >>  > This builds images of many versions of zsh (including a daily build
> of
> >>  > zsh's master branch) and deploys them to Docker Hub (
> >>  > https://hub.docker.com/u/zshusers).
> >>  >
> >>  > So you can do, for instance:
> >>  >
> >>  > $ docker run -it zshusers/zsh-5.3.1
> >>  >
> >>  > -> will launch an interactive session of zsh 5.3.1
> >>  >
> >>  > We use it to automatically test zsh-syntax-highlighting on all
> supported
> >>  > versions of zsh.
> >>
> >>  What you could just as well do without docker which would make travis
> run
> >>  faster due to not needed `sudo: required` and ability to setup travis
> >>  cache. For testing something locally your docker images make more sense
> >>  because they are easier to use then compiling that big amount of zsh
> >>  versions.
> >
> > You mean, instead of using Docker, building the right zsh version on each
> > job and use Travis cache ? I am not sure that would work as we would have
> > to "make install" zsh anyway, so we would need sudo...
>
> 1. No, you may just build it with a bot and save an archive.
> https://github.com/powerline/bot-ci works like this for years, though I
> only have one zsh version. Binaries are in https://github.com/powerline/
> deps.
> 2. You need absolutely no `sudo` for `make install`. Just do user-local
> installation, something like ~/.local-zsh-$ZSH_VERSION. The *build bot* I
> referenced above is using container-based builds without sudo, not to
> mention powerline itself which it builds dependencies for. Works fine for
> CPython (some variant not provided by travis), zsh, zpython, tmux, fish, rc
> shell, libvterm, Vim, various Vim plugins and Python packages. This is only
> a matter of what you pass as a prefix.
> 3. Actually it is possible to build in the job itself and use travis
> cache, Neovim works this way. I found it more complicated to setup and it
> would make build times unpredictable for powerline since I do not hardcode
> versions like Neovim does.
>
> >
> > The Docker setup makes things very simple on zsh-syntax-highlighting
> side,
> > it's only one line (https://github.com/zsh-users/
> > zsh-syntax-highlighting/blob/master/.travis.yml#L30), so it stays clean
> and
> > it's easy to use on other projects as well.
> >
> >>  Also why you have no builds for PRs
> >
> > All those PRs were submitted before we setup Travis-CI, I'm not sure if
> we
> > can trigger builds, maybe if contributors rebase their branches ?
> >
> >>  and why you don’t merge those 24 jobs into something like 7 (4.3*,
> 5.0*,
> >>  5.1*, 5.2*, 5.3*, 5.4*, master)? Less then twenty seconds to run tests
> in a
> >>  single job, lots of time to initialize VMs and there is nothing which
> may
> >>  prevent you from consequently running two docker commands in one job,
> or
> >>  using two zsh versions via other means.
> >
> > Yeah sure, it was just easier to setup and to get a dashboard with every
> > version. We want to make it easy for contributors what their pull request
> > broke. If we start grouping jobs, log files will be harder to analyse.
> >
> > Currently build time is 5/6 minutes, so I don't see it as a big issue.
>
> Travis has folds, so you may create a fold for each version and print a
> summary of “what failed” below for contributors to know what to unfold. (Of
> course, this works in web interface only.) See https://github.com/ZyX-I/
> neovim/blob/663ca27d3ac9567bb82fc66141aae67bd80190d2/ci/common/suite.sh
> for an example, though I must say I have not set up `set [+-]x` well, so
> some trace lines appear outside folds.
>
> >
> >>  >
> >>  > Cheers,
> >>  > Julien
>