integration test set up for l10n.m.o automation



Localization Infrastructure and Tools
2 years ago
2 years ago


(Reporter: Pike, Unassigned)


(Blocks: 1 bug)


User Story

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?

Comment 1

2 years ago
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 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 SSH server, 2 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.