For the integration test environment, I'd want: - a local set up of hg -- with pushlog -- with pulse notifications on a stable IP/DNS/port interface. On top of that, the l10n automation will build - a local rabbit - a local ES (for compare-locales and kibana) - a local kibana - a local worker, for scheduling and compare-locales
For developing an automation framework for l10n.m.o, I want an integration test environment. As I want to tie into hg.m.o at the pulse level, that's rather involved, so preferably I'd build upon work in version-control-tools. Greg, it seems that I'm the first to do this? I'd love to see a deterministic interface to a local instance of hgmo. I'd bet that that would help to get other automation pieces migrated from pollers to pulse, too? Are there things you guys are working on that align with this?
There is an "hgmo" extension in the v-c-t repo. One of the things it does is add an "--hgmo" flag to `hg serve`. When you run `hg serve --hgmo` it runs a local HTTP server configured very similarly to hg.mozilla.org. That gets you pushlog and all our template customizations. What that doesn't give you is the SSH server and the ability to write things into pushlog - at least not the same way that we do things in prod. For that, you'll need `./hgmo start` from v-c-t. That sets up a handful of Docker containers running a hg.mozilla.org SSH server, 2 hg.mozilla.org HTTP servers, an LDAP server, and a Pulse server. It's the closest thing we have to reproducing production. The tests in hgserver/tests/ show how to interact with the test cluster, including creating LDAP users and configuring things for pushing. Please needinfo me if you have any more questions (I tend to reply to needinfo's faster).
You need to log in before you can comment on or make changes to this bug.