I pushed up latest binaries to releases and they are available.

Is the nginx base image because you have both a nodejs service listening on a socket in addition to static files that need to be served?

Looks really cool!

I think there are a couple of problems with the current Continuous Delivery pipeline implementation:

Added a few inline comments that may require some changes, but code looks like it should work as is so feel free to land when you feel like it's ready.

A few nits inline. The only show-stopper is that sync-wikiversions won't work as implemented. Should this be feature-flagged to hide warnings pre-switchover?

In D1135#22657, @Joe wrote:

I frankly have no idea why these unit test issues pop up; I'm pretty sure I didn't touch anything remotely related.

In D1117#22654, @Joe wrote:

We decided to use a different approach for this patch, containing it in puppet rather than here.

Discussed in today's deployment pipeline meeting.

In T212251#4837963, @akosiaris wrote:

There is however a 3rd overarching use case/requirement which is to allow developers to use the tool even when they have no/flaky internet. There's more than 1 stories of a hackathon (or just parts of, like the quiet room) having no/flaky internet and that's where a lot of work happens. And it's not satisfied in any way by exposing any kind of endpoint or service, but rather by making blubber available to them.

I made a little command line tool to help me find image: https://gist.github.com/thcipriani/7d7633eb238cd868d5ba24d0f1069463

Talked about this with @dduvall in the pipeline meeting today. This work is implicit in the design of the pipeline itself. Closing the task as invalid since it no longer makes sense as the pipeline already provides two test entry points: one low-level and one higher-level (e2e).

The model of execution that this task refers to is not longer used/valid.

AIUI, blubber has no way to allow project owners to specify files to copy to specific locations inside the container, but if what I described is already possible, please advise :)

In T211708#4821969, @LarsWirzenius wrote:

Is this task done now?

In T211625#4811818, @dduvall wrote:

One refactoring option I can think of would be to make the config for copying of project/application files explicit and use a sane default.

e.g.

variants:
  build:
    copies: { hostfiles: true } # default value so not strictly needed here
  production:
    copies: { from: prep, hostfiles: false } # perhaps the default for `hostfiles:` could be based on `copies.from == nil` so it's not strictly necessary here either
  production2:
    copies: { hostfiles: false } # it would be necessary here since we're defining artifacts explicitly below
    artifacts:
    - from: prep
      source: /srv/app/binfile
      destination: ./

Maybe this info could be made a subpage of https://www.mediawiki.org/wiki/Release_checklist and linked from that opening paragraph on that page?

Caused by a change @mmodell and I merged 2 weeks ago. I put it behind a flag in https://gerrit.wikimedia.org/r/#/c/mediawiki/tools/release/+/479134/ so this shouldn't be a problem for next time.