We've changed the config to be more consistent about "copies" and
"artifacts". This means that "copies" no longer accepts a string, but a
slice of strings. We should bump the config version and blubber version
to make it clear that we're not longer backwards compatible.
Change-Id: Ib68f623cbdcdf0aed74f4fdaec062835748e8eb9
Refactored `copies` configuration to allow for greater control over when
and which both local build context files and variant artifacts are
copied into the target image.
The new configuration introduces a "local" keyword to signify when a
`copies` entry should apply to the files from the local build context as
opposed to files from another variant's image during a multi-stage
build.
variants:
build:
copies:
- from: local
source: ./src
destination: .
Note that with this change, the user must now explicitly define whether
_any_ files should be copied in from the local build context. None will
be copied in by default.
To help keep configurations succinct, especially considering this new
requirement, and to approximate the old `copies: variant`, a shorthand
format and sane defaults for `source` and `destination` (depending whether
`from` is "local" or a variant name) were implemented.
variants:
build:
copies: [local]
development:
copies:
- from: build
- from: local
source: ./config.dev.yaml
destination: ./config.yaml
The shorthand:
copies: [ref, ...]
# is equivalent to
copies: [{ from: ref }, ...]
And the following defaults are used when no `source` and `destination`
are specified.
copies:
- from: local
# defaults to
- from: local
source: .
destination: .
copies:
- from: variant
# defaults to two entries
- from: variant
source: /srv/app # the lives.in dir
destination: /srv/app
- from: variant
source: /opt/local # the shared lib dir
destination: /opt/local
Bug: T211625
Change-Id: I4c4217905afc0762b6bd66ed594d43cc0486e3e2
The new logo was the winner of a recent round of voting among Release
Engineering. (See https://phabricator.wikimedia.org/V19) It incorporates
colors from the WM design palette and the ring pattern from the logos of
other WM teams, platforms, and tooling.
R.I.P. Tyler's dead-whale logo.
Change-Id: I0f79dcd9cb521f39059fa4270f65508c3c097a54
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
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
Summary:
To help new developers get on board, let's provide a `CONTRIBUTING.md`
doc.
Test Plan: Proofread with your eyeballs.
Reviewers: thcipriani, demon, hashar, mmodell, zeljkofilipin, greg, Jrbranaa, #release-engineering-team
Reviewed By: thcipriani, hashar, #release-engineering-team
Tags: #release-engineering-team
Differential Revision: https://phabricator.wikimedia.org/D993
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
Summary:
Added a Makefile so you don't need any special mangling of your go path
Test Plan:
None
Reviewers: dduvall, mmodell, #release-engineering-team
Reviewed By: mmodell
Subscribers: Joe
Tags: #release-engineering-team
Revert Plan:
None
Differential Revision: https://phabricator.wikimedia.org/D671
Tyler Cipriani
Dan Duvall
Gilles Dubuc
Giuseppe Lavagetto