Gerrit features and Docker based testing
John Keeping
john at keeping.me.uk
Sat Oct 21 15:05:39 CEST 2017
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.
More information about the CGit
mailing list