| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Support for mounting a shared volume instead of copying application
files was meant to provide an option for development use cases. This
functionality has never been thoroughly tested or utilized for any use
case. It should be removed for now.
Relates tangentially to task T204591 that simplifies node support.
Change-Id: Ib70cb7bceb504841897a38d732880ba376fe67c8
|
|
Change-Id: I91cac046976cf88d513487e27e1b52bf77a6f974
|
|
The builder configuration has proven useful for supporting generic
pre-entrypoint commands such as dependency managers not otherwise
supported by specific Blubber configuration. Adding additional
`builder.requirements` config expands support for such commands by
allowing the user to specify files that should be copied into the image
before the builder command runs.
To support this extra configuration, `builder` had to be changed from a
simple string to a mapping. The builder command must now by given as
`builder.command`.
The pattern of creating parent directories, copying files, and executing
one or more commands prior to the entrypoint has become a common
one. Some of the implementation of this pattern was moved from
`PythonConfig` into shared build macros `build.SortFilesByDir` and
`build.SyncFiles`. All config types that must have requirements files
copied over independently of the entire source tree (`PythonConfig`,
`BuilderConfig`, `NodeConfig`) now delegate to these functions.
Change-Id: I67f33034f22cee2851ec866cfb07ab20c23eba8c
|
|
|
|
Summary:
Change `node.dependencies` flag to `node.requirements`, the list of
files (typically `package.json` and either `npm-shrinkwrap.json` or
`package-lock.json`) that declare dependencies to be installed with NPM.
Test Plan: Run `go test ./...`. Try it out with something like Mathoid.
Reviewers: thcipriani, hashar, mobrovac, Joe, akosiaris, #release-engineering-team
Reviewed By: thcipriani, #release-engineering-team
Tags: #release-engineering-team
Differential Revision: https://phabricator.wikimedia.org/D1058
|
|
Reviewers: thcipriani, dduvall, #release-engineering-team
Reviewed By: dduvall, #release-engineering-team
Tags: #release-engineering-team
Differential Revision: https://phabricator.wikimedia.org/D1054
|
|
Summary:
Introduced a `version` config field that must be specified and match
`config.CurrentVersion`.
Changed `config.ReadConfig` to use `yaml.UnmarshalStrict` to ensure that
errors are surfaced when unknown/bad fields are present in the given
YAML config. A smaller `config.VersionConfig` is now unmarshaled first
to prevalidate the new `version` field before the entire config is
parsed.
Fixes T191460
Test Plan:
Run `go test ./...`. Run `blubber` against some configuration containing
invalid fields and ensure that it surfaces a YAML error.
Reviewers: thcipriani, demon, hashar, mmodell, mobrovac, #release-engineering-team
Reviewed By: thcipriani, #release-engineering-team
Tags: #release-engineering-team
Maniphest Tasks: T191460
Differential Revision: https://phabricator.wikimedia.org/D1021
|
|
Summary:
Use cases involving running of test suites and doc generation require
more liberal ownership and read/write permission to application files.
When `runs.insecurely` is set to `true`, the effective runtime user will
be `lives.as`, the same user that owns the application files and
installed dependencies.
D999 is a complement to this change to allow restrictions on this and
other potentially sensitive configuration.
Depends on D999, D1002
Test Plan: Run `go test ./...`.
Reviewers: thcipriani, mmodell, hashar, #release-engineering-team, demon
Reviewed By: thcipriani, #release-engineering-team
Tags: #release-engineering-team
Differential Revision: https://phabricator.wikimedia.org/D1003
|
|
Summary:
A new root and variant `python` config field is provided with two new
fields below, `version` and `requirements`.
The former, `version`, should specify the Python executable to use when
executing related package installation commands and ostensibly the same
executable that will be used to run the application.
The latter, `requirements`, should specify all pip requirements files
such that a compiler that supports layered filesystems (e.g. Docker) can
output separate instructions that will invalidate cache layers for
changes to those files independently of changes to the rest of the
codebase.
Python related instructions will be generated only if either `version`
or `requirements` are given.
Fixes T186545
Test Plan: Run `go test ./...`.
Reviewers: thcipriani, hashar, demon, #release-engineering-team
Reviewed By: thcipriani, #release-engineering-team
Tags: #release-engineering-team
Maniphest Tasks: T186545
Differential Revision: https://phabricator.wikimedia.org/D976
|
|
Summary:
Introduces new `lives` configuration that provides the name/UID/GID of
the user that will own application files and installed dependencies.
This new configuration is distinct from `runs` in that the former
determines application file location ownership and the latter now only
determines runtime process ownership. Default configuration has also
been introduced for both config sections.
In addition to the new configuration, a new `build.CopyAs` instruction
has been introduced that ensures correct UID/GID ownership of files
copied into the container image, and all unqualified `build.Copy`
instructions are wrapped by the new `build.CopyAs` instruction using the
UID/GID appropriate for the current build phase. A new `build.User`
instruction is also introduced and injected into the build at the start
of certain phases to enforce ownership of `build.Run` processes.
This effective process/file ownership model is:
PhasePrivileged - "root"
PhasePrivilegedDropped - lives.as
PhasePreInstall - lives.as
PhaseInstall - lives.as
PhasePostInstall - runs.as
Fixes T187372
Test Plan: Run `go test ./...`.
Reviewers: thcipriani, hashar, demon, #release-engineering-team
Reviewed By: thcipriani, #release-engineering-team
Subscribers: mmodell
Tags: #release-engineering-team
Maniphest Tasks: T187372
Differential Revision: https://phabricator.wikimedia.org/D984
|
|
Summary:
Defined new abstract `build.Volume` and corresponding
`docker.DockerVolume` instructions.
Refactored compilation of main `COPY` or `VOLUME` instruction for
application files to use the new instructions and moved injection of
these instructions out of the compiler and into `VariantConfig`. The
latter can be smarter about the following cases:
1. When `copies` is set, simply depend on artifacts for the application
files and do not copy anything from the build host.
2. When `sharedvolume` is `true`, inject a `build.Volume` instruction
for the application working directory.
3. When neither of the above are set, copy application files from the
host.
Fixes T174623
Depends on D768
Test Plan:
Run `go test ./...`. Run `blubber blubber.example.yaml production` and ensure:
1. The `prep` stage has a `COPY . .` instruction.
2. The final stage has no `COPY . .` instruction, only `COPY --from=prep`
instructions.
Reviewers: thcipriani, mobrovac, hashar, mmodell, #release-engineering-team
Reviewed By: thcipriani, mobrovac, #release-engineering-team
Tags: #release-engineering-team
Maniphest Tasks: T174623
Differential Revision: https://phabricator.wikimedia.org/D769
|
|
Summary:
Support a `copies` variant config entry that will result in a
multi-stage build, copying both shared library files and application
directory from a previously defined variant. This is essentially a
shorthand for two `artifacts` entries that are likely to be idiomatic to
multi-stage build/prod configurations.
Defined a new abstract `build.CopyFrom` instruction and corresponding
`docker.DockerCopyFrom` instruction and refactored the writing of these
Dockerfile lines to be accomplished using an `InstructionsForPhase`
method on `config.ArtifactsConfig`.
Implemented new support for `copies` configuration in
`config.VariantConfig` and an `InstructionsForPhase` method that returns
`build.CopyFrom` instructions for both the shared library and
application directories.
Fixes T174622
Depends on D759
Test Plan:
Run `go test ./...`. Run `blubber blubber.example.yaml production` and ensure
the right `COPY --from` lines are included for the final stage.
Reviewers: thcipriani, mobrovac, hashar, mmodell, #release-engineering-team
Reviewed By: thcipriani, #release-engineering-team
Tags: #release-engineering-team
Maniphest Tasks: T174622
Differential Revision: https://phabricator.wikimedia.org/D768
|
|
Summary:
Define `NODE_ENV` based on the configuration and define `NODE_PATH` when
either `npm.install` or `npm.env` are true. The latter behavior is
necessary for final stages of multi-stage builds where npm modules are
not installed but the application requires node-related environment
variables to run.
Depends on D757
Ref T174626
Rename npm module/config to node
Renamed `npm` yaml entry to `node` and `NpmConfig` to `NodeConfig`.
Since we're dealing with general node builds and configuration, this
seems to make more sense.
Test Plan:
Run `go test ./...` or `arc unit`. Run blubber against at least the
`blubber.example.yaml`.
Reviewers: thcipriani, mobrovac, mmodell, #release-engineering-team
Reviewed By: thcipriani, #release-engineering-team
Tags: #release-engineering-team
Maniphest Tasks: T174626
Differential Revision: https://phabricator.wikimedia.org/D759
|
|
Summary:
Added support for definition of environment variables under
`runs.environment`. Corresponding `ENV` instructions will be added to
Dockerfile output for the unprivileged build phase.
Fixes T168425
Test Plan: Run `go test ./...`.
Reviewers: thcipriani, mobrovac, hashar, Jrbranaa, mmodell, #release-engineering-team
Reviewed By: mobrovac
Tags: #release-engineering-team
Maniphest Tasks: T168425
Differential Revision: https://phabricator.wikimedia.org/D691
|
|
It sounds more declarative.
|
|
|
