From mboxrd@z Thu Jan 1 00:00:00 1970 From: john at keeping.me.uk (John Keeping) Date: Sat, 21 Oct 2017 14:05:39 +0100 Subject: Gerrit features and Docker based testing In-Reply-To: References: Message-ID: <20171021130539.GB2393@john.keeping.me.uk> 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.