Add Dockerfile

[vladistan]

On modern CI server sometimes it’s handy to run such small tools from Docker container instead of making sure it exists on every build host

If you choose to accept this PR, you'll need to create an account on docker hub, and enroll this repository in there. They will auto-build and auto-distribute everything for you.

Preflight Checklist

I have:

• Read the Contributor's Guidelines.
• Updated the examples as necessary.
• Updated the documentation as necessary.
• GPG signed my commits.

[dak180]

• I like the idea, but this should be more generic; so not just git but also hg, bzr, svn and git-svn.

• Additionally, besides the repo types autorevision also uses the following non builtin commands: sed, cut, grep, wc, tail, basename, dirname, tee, getopts, tr and cmp.

• Also, it should use the installed version of autorevision not the .sh file.

• I am not familiar enough with docker to know where this would best go, but the man page (and possibly other docs) should be somewhere as well.

[vladistan]

On your second point. The container this Dockerfile builds is based on base alpine linux distribution. So it already has all non-built in commands.

Look at the test below. You can verify it for yourself, using the docker command from the test. All you need to have installed is just docker.

$ docker run -it  -v  `pwd`:/app/ --entrypoint /bin/sh autorevision:local
 /app # sed
BusyBox v1.30.1 (2019-06-12 17:51:55 UTC) multi-call binary.

Usage: sed [-i[SFX]] [-nrE] [-f FILE]... [-e CMD]... [FILE]...
 or: sed [-i[SFX]] [-nrE] CMD [FILE]...

 /app # cut
 cut: expected a list of bytes, characters, or fields
 /app # grep
 BusyBox v1.30.1 (2019-06-12 17:51:55 UTC) multi-call binary.

 Usage: grep [-HhnlLoqvsriwFE] [-m N] [-A/B/C N] PATTERN/-e PATTERN.../-f FILE [FILE]...

 /app # wc
 ^C
 /app # tail
 ^C
 /app # basename
 BusyBox v1.30.1 (2019-06-12 17:51:55 UTC) multi-call binary.

 Usage: basename FILE [SUFFIX]

 Strip directory path and .SUFFIX from FILE

  /app # dirname 
 BusyBox v1.30.1 (2019-06-12 17:51:55 UTC) multi-call binary.

 Usage: dirname FILENAME

 Strip non-directory suffix from FILENAME
 /app # tee
 ^C
 /app # getopts
 /bin/sh: getopts: usage: getopts optstring var [arg]
 /app # tr
 BusyBox v1.30.1 (2019-06-12 17:51:55 UTC) multi-call binary.

Usage: tr [-cds] STRING1 [STRING2]

 /app # cmp
BusyBox v1.30.1 (2019-06-12 17:51:55 UTC) multi-call binary.

Usage: cmp [-l] [-s] FILE1 [FILE2 [SKIP1 [SKIP2]]]

app #

[vladistan]

I see your point about the support of multiple revisions. But this makes pretty large container, 115MB with all VCS installed vs 26MB with just git.

 $ docker images | head  
REPOSITORY                      TAG                  IMAGE ID            CREATED             SIZE
autorevision                    all-vcs              9f69e252c527        45 seconds ago      115MB
vladistan/autorevision          latest               46c075d03512        2 days ago          26.7MB

Maybe we should have two different images one just for git as it's most common use case these days and another one with everything else included

[vladistan]

Now there are two Dockerfiles one with just GIT and another one with the rest of the VCS ( hg, svn, bzr)

Also, I am no longer copying the shell script, but doing 'make install'

Let me know what you think

[vladistan]

As for the docs, do you it's better to put into man page, or have a separate README just for docker?

[dak180]

As for the docs, do you it's better to put into man page, or have a separate README just for docker?

As I have never used docker before (personally I tend to use jails instead), I am not sure what would have the best visibility from inside docker but I definitely think a separate readme is in order to go over how the docker images are meant to be used.

[vladistan]

Ok, I'll write a separate README and put it in the directory with Docker files.

[vladistan]

Ok, readme is there now. Note, I put the references to my personal account in Dockerhub. Might be a good thing if you could create an Autorevision account in dockerhub and hook the this repo, so you'll always have the fresh containers built automatically once changes are checked in into this repository.

I can walk you through creating the account. Dockerhub has the same policy to open source as the github. Hosting is always free for the containers that are publicly available.

[dak180]

I can walk you through creating the account. Dockerhub has the same policy to open source as the github. Hosting is always free for the containers that are publicly available.

I did not see a free tier for orgs; only individuals.

[vladistan]

Actually, they changed their naming scheme. All you need is to create an account named 'Autorevision' and link it to the github repo