Gerrit features and Docker based testing

[john at keeping.me.uk (John Keeping)]

On Thu, Oct 19, 2017 at 05:07:30PM -0600, bbuhlig at codeaurora.org wrote:
> Hi, Cgit is frequently paired with Gerrit installations, so I have a
> some Gerrit integration features I'd like to contribute. One is a Lua
> authentication filter for Gerrit. Background is that Gerrit allows 
> different
> users to have access to different repos, so in essence this auth filter
> leverages the user's Gerrit login HTTP cookie to access the Gerrit REST 
> API,
> which it uses to figure out whether the logged in user should have 
> access to
> the particular repo.
> 
> Anyway, to help ensure it keeps working along with the Lua code itself, 
> I'd
> ideally like to contribute some tests for it. But the environment those
> tests would need to run in would be a bit complicated, in particular 
> needing:
> 
>    (1) the auth filter's Lua package dependencies installed-
>          - specifically: crypto, ssl.https and ltn12
>    and,
>    (2) a test Gerrit instance configured that the filter could talk to,
>          - or a simple python/node.js based webserver that looks 
> sufficiently
>            like the part of the Gerrit REST API that the filter cares 
> about
> 
> An obvious way to define this environment would be a Dockerfile that the
> "make test" command invokes Docker against. To enable people who don't 
> care
> about the Gerrit auth-filter, the makefile could be setup to skip the 
> test
> if Docker isn't installed on the build machine. But unless the cgit
> maintainers were to trigger the tests in a build environment with Docker
> available, the auth filter code would eventually get stale and break.
> 
> Assuming the above sounds reasonable and I provided said feature and 
> tests,
> would it be possible for the cgit maintainers to generally have Docker
> available when regularly running "make test"?

I wouldn't want the top-level "make test" to add additional
dependencies, but I'm not sure that's necessary here.

Assuming this lives under contrib/, it can have its own build and test
infrastructure that is separate from the main CGit source.