• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

rero / rero-ils / 33394383849
91%

Build:
DEFAULT BRANCH: staging
Ran 31 Aug 2026 01:38PM UTC
Jobs 1
Files 612
Run time 2min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

31 Aug 2026 12:57PM UTC coverage: 91.414%. Remained the same
33394383849

push

github

jma
perf(docker): speed up the dev and test stack

This stack serves the test suite and `scripts/setup`, whose data
is always thrown away, so it can trade durability and production
sizing for speed.

* add an `init` service putting a legacy template that brings the
  development indices down to one shard and no replica: the
  `record` template asks for 8, sized for production, and every
  search fans out over all of them
* relax every PostgreSQL durability guarantee, here and not in
  docker-services.yml, which is the base of the production
  example
* put the template back in the `search` fixture after each
  `put_templates`, whose recovery branches wipe all templates

`docker compose up -d` returns as soon as the containers are
started, so an index created right after would keep the 8 shards:
measured three times out of three, `init` is still running and the
template returns 404 when it returns. A `gate` service closes that
window inside the compose file, by depending on `init` having
completed and on all four services being healthy. Healthchecks
added to `db` and `cache`, which had none.

Plain `docker compose up -d` therefore guarantees the whole stack,
and no caller needs a second command: docker/wait-for-services.sh
is deleted, unused since .travis.yml disappeared in 2020.

Measured from a cold stack: `up -d` blocks 8 s and returns 0 with
the template installed; a template rejected by Elasticsearch makes
it return 1 with `service "init" didn't complete successfully:
exit 22`; a service that never turns healthy makes it return 1
once its retries are exhausted, rather than hanging.

The shard count stays out of `scripts/setup`, which also runs on
the test servers, where the production defaults are the right
ones.

Co-Authored-By: Johnny Mariéthoz <Johnny.Mariethoz@rero.ch>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

24361 of 26649 relevant lines covered (91.41%)

0.91 hits per line

Jobs
ID Job ID Ran Files Coverage
1 33394383849.1 31 Aug 2026 01:38PM UTC 612
91.41
GitHub Action Run
Source Files on build 33394383849
  • Tree
  • List 612
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #33394383849
  • 8ef67d4f on github
  • Prev Build on staging (#32943916857)
  • Next Build on staging (#33401872719)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc