Just now getting up to speed on this, so please bear with me if I'm not fully understanding the problem.
Fri, Nov 20
Thu, Nov 19
I'm not knowledgable of the initiative or NPM package, and Blubber doesn't really have an opinion about this other than it's best practice to have the source of runtime files (application + linked/importable libraries) be read-only, but here's my suggestion from reading the following part of the documentation:
Fri, Nov 6
This is akin to the experimental RUN --mount Dockerfile instructions which only mount temporary volumes for use in the build container. These instructions cannot be used to aggregate sources into a final image for deployment.
Wed, Nov 4
Thank you, @nskaggs!
Mon, Nov 2
For the paper trail:
Tue, Oct 27
I've updated the patch to match what I submitted upstream.
Oct 24 2020
I wrote a better patch for upstream. :)
I was reading a bit more about packfile negotiation and it seems like a better heuristic approach than matching a regex against the stderr for this function's implementation might be to:
Oct 23 2020
@thcipriani and I peeked into the logs earlier but we couldn't see anything in the PHP error log, only the 500 response in the access logs.
I ran into this issue yesterday in during a submodule update for Wikibase with --depth 1.
Oct 21 2020
Oct 20 2020
After thinking about this a bit more, I'm not sure packaging pack and running it on a bare agent will give us a better situation as it would still have direct access to Docker and more. I can't think of an obvious path here other than auditing pack more closely and determining whether it has anything that could be used for shell/command injection.
is it possible for normal jobs to pull/build docker images? We don't actually need to use the images, but verify that pack can build one.
Oct 16 2020
Oct 15 2020
Thanks for addressing the logspam; much appreciated! However, is this an actual train blocker? I.e. should I be waiting on a backport to wmf/1.36.0-wmf.13 before promoting to all wikis today? If not, please remove T263179: 1.36.0-wmf.13 deployment blockers as a parent task.
Oct 14 2020
Oct 13 2020
Re-deployed for all wikis.
Lowering priority as new logging is in place and this is no longer a blocker of 1.36.0-wmf.11—the latter has been re-deployed for all wikis.
Oct 9 2020
Oct 7 2020
Oct 1 2020
Thanks for taking a look, @tstarling. It looks like there's more context for the MBS cache clear in T222539: Scap deployments are not purging MessageBlobStore (was: Stale localized messages) and the related patchset to scap as well.
Sep 25 2020
@tstarling can you provide insight into why the MessageBlobStore is cleared during this process and whether we might be able to remove/decouple it from localization rebuilds? (See above questions/comments.)
Sep 24 2020
My notes after tracing the process:
Sep 23 2020
Sep 17 2020
Sep 16 2020
Thanks for the feedback, @Joe.