Age | Commit message (Collapse) | Author | Files | Lines |
|
Remove a race condition which appears when uploadHashLayer is called
with the same key from multiple threads simultaneously. This can
easily happen when the same image path is requested by multiple
clients at the same time. When it does, a 500 status is returned and
the following error message is logged:
{
"context": {
"filePath": "github.com/google/nixery/builder/builder.go",
"lineNumber": 440,
"functionName": "github.com/google/nixery/builder.uploadHashLayer"
},
"error": "rename /var/lib/nixery/staging/<hash> /var/lib/nixery/layers/<hash>: no such file or directory",
"eventTime": "...",
"layer": "<hash>",
"message": "failed to move layer from staging",
...
}
To solve this issue, introduce a mutex keyed on the uploaded hash and
move all layer caching into uploadHashLayer. This could additionally
provide a small performance benefit when an already built image is
requested and NIXERY_PKGS_PATH is set, since symlink layers and config
layers are now also cached.
Change-Id: I50788a7ec7940cb5e5760f244692e361019a9bb7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/6695
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
|
|
Since the source of nix-1p is checked in under //nix/nix-1p, we should
use it from there if Nixery is being built inside of depot.
Change-Id: Iddd54f7b93b398b2f909db6ee105366a9914a2ac
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5882
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Autosubmit: tazjin <tazjin@tvl.su>
|
|
People occasionally ask what the current nixpkgs commit is on
nixery.dev (see e.g. https://github.com/tazjin/nixery/issues/153).
With this change, the commit is displayed on nixery.dev if Nixery is
built for the TVL deployment.
Change-Id: I795220214db5a367a126c9b4bd03754e9f144940
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5881
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Autosubmit: tazjin <tazjin@tvl.su>
|
|
Change-Id: Id6ff48d66368732cba0b8af6e1cbab64b0f2afbf
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5671
Autosubmit: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
This exports the `:/tools/nixery` subtree to Github automatically
after merges to `canon`.
Due to the way the project was imported this continues the existing
git history in the external repository.
Change-Id: Ie871c14ad5d8f1019f8be86adecbe9b130ffb01a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5667
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
Nixery is going to gain a new binary (used for building images without
a registry server); to prepare for this the server binary has moved to
cmd/server and the Nix build logic has been updated to wrap this
binary and set the required environment variables.
Change-Id: I9b4f49f47872ae76430463e2fcb8f68114070f72
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5603
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
This will be required for making a standalone, Nixery-style image
builder function usable from Nix.
Change-Id: I5e36348bd4c32d249d56f6628cd046916691319f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5601
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
|
|
Change-Id: I67405f9c9bd9cc8cb34fafff80e30b2fca53a2b3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5502
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: tazjin <tazjin@tvl.su>
|
|
Cleans up a whole bunch of things I wanted to get out of the door
right away:
* depot internal references to //third_party/nixery have been replaced
with //tools/nixery
* cleaned up files from Github
* fixed SPDX & Copyright headers
* code formatting and inclusion in //tools/depotfmt checks
Change-Id: Iea79f0fdf3aa04f71741d4f4032f88605ae415bb
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5486
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: tazjin <tazjin@tvl.su>
|
|
This does not fully change the build structure of Nixery to be
depot-compatible yet, but should allow most targets to be built in
depot CI.
This contains some hacks to work around surface incompatibilities
which we'll clear away later.
Change-Id: I84e7734334abbe299983956f528c0897f49fa8c2
Reviewed-on: https://cl.tvl.fyi/c/depot/+/5485
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
|
|
This absorbs a josh-filtered Nix subtree into depot, at
//tools/nixery.
This subtree was created through `josh-filter ':prefix=tools/nixery'`,
which allows a filter on tools/nixery to yield the same commit hashes
as the original Nixery repository (allowing for history continuity).
Change-Id: Icc1a99bf1248226b91f437b0a90361d36fb0d327
|
|
The Nixery main Git repo has moved
from https://github.com/google/nixery
to https://github.com/tazjin/nixery .
So change it in README and on the https://nixery.dev/ website.
|
|
Two minor "quality of life" improvements:
- automatically set SSL_CERT_FILE environment variable,
so that programs relying on OpenSSL for certificate
validation can actually validate certificates
(the certificates are included no matter what since
we add the "cacert" package to all iamges)
- if the requested image includes an interactive shell
(e.g. if it includes the "shell" metapackage), set
the image Cmd to "bash", which allows to execute
"docker run nixery.dev/shell" and get a shell)
I'm happy to split this PR in two if you'd like, but
since both features touch the Config structure and are
rather small, I thought it would make sense to bundle
them together.
|
|
Examples of programs that fail when /tmp doesn't exist:
- terraform
- anything using mktemp and similar helpers
|
|
|
|
The error message shows the wrong variable name, which might
be confusing for new users.
|
|
These instructions were not up-to-date (they didn't mention
the different storage backends, and some variables were
tagged as optional while they were mandatory). With this
update, they should (hopefully) be more accurate! :)
I also added instructions if someone wants to run Nixery
outside of the container image (I found it convenient when
working on Nixery's code).
|
|
Result of 'go get -u && go mod tidy'
|
|
|
|
... basically never updated this, oops.
|
|
I no longer work at Google and the repo has moved, so this is no
longer relevant.
|
|
This reverts commit 7db252f36a68d875429a25e06d88fbfc804d84fd.
Superseded by the implementation in #127.
|
|
This is required by common patterns in shell scripts.
There are some caveats around this. Adding logic to filter whether
coreutils is included in an image would slow down the Nix evaluation,
so the link is currently created even in cases where it doesn't point
to anything.
Fixes #109
|
|
Required for builds where the full repository isn't available (e.g.
from a tarball).
|
|
Moves the build badge to point at Github Actions, instead of the old (failing) Travis build
|
|
After the discussion in #116, this stores the blob content types
in extended attributes when using the filesystem backend.
If the underlying filesystem doesn't support extended attributes,
storing blobs won't work; also, if extended attributes get removed,
blobs won't be served anymore. We can relax this behavior if
needed (i.e. log errors but still accept to store or serve blobs).
However, since the Docker Engine (and possibly other container
engines) won't accept to pull images from a registry that doesn't
use correct content types for manifest files, it could be argued
that it's better to give a hard fail. (Otherwise, the container
engine gives cryptic error messages like "missing signature key".)
I can change that behavior (and log errors but still store/serve
blobs to the filesystem) if you think it's better.
|
|
With https://github.com/google/nixery/pull/127, nixery will use extended
attributes to store metadata (when using local storage).
Right now, our integration test mounts a tmpfs to /var/cache/nixery.
However, *user* xattrs aren't supported with tmpfs [1], so setting
xattrs would fail.
To workaround this, use a folder in the current working directory and
hope it's backed by something supporting user xattrs (which is the case
for GitHub Actions).
[1]: https://man7.org/linux/man-pages/man5/tmpfs.5.html#NOTES
|
|
|
|
Drops the go2nix configuration in favour of pkgs.buildGoModule.
Note that the go.sum file is bloated by issues with cyclic
dependencies in some Google projects, but this large number of
dependencies is not actually built.
|
|
|
|
|
|
* remove a step that was not supposed to be committed ("Do we have
Docker?")
* remove setup of old temporary storage directory (now done in
integration script test instead)
* skip creation of out-link for initial Nixery build (to avoid
cache-busting on the second build)
|
|
In case the `GOOGLE_APPLICATION_CREDENTIALS` environment variable is not
set, a redirect to storage.googleapis.com is issued, which means the
underlying bucket objects need to be publicly accessible.
This wasn't really obvious until now, so further clarify it.
|
|
This copies the integration tests from `.travis.yaml` into a script,
documents the assumptions it makes, and wires it into GitHub Actions.
Contrary to the travis version, we don't use Nixery's GCS backend, as
handing out access to the bucket used, especially for PRs, needs to be
done carefully.
Adding back GCS to the integration test can be done at a later point,
either by using a mock server, or by only exposing the credentials for
master builds (and have the test script decide on whether
GOOGLE_APPLICATION_CREDENTIALS is set or not).
The previous travis version had some complicated post-mortem log
gathering - instead of doing this, we can just `docker run` nixery, but
fork it into the background with the shell - causing it to still be able
to log its output as it's running.
An additional `--rm` is appended, so the container gets cleaned up on
termination - this allows subsequent runs on non-CI infrastructure (like
developer laptops), without having to manually clean up containers.
Fixes #119.
|
|
We don't intend to label, authenticate or whatever with the
GITHUB_TOKEN, so there's not really a reason to give any broader
permissions than the defaults.
|
|
Travis is being deprecated, and this might be the best option for now.
|
|
When serving a manifest, it is important to set the content-type
correctly (otherwise pulling an image is likely to give a cryptic
error message, "Error response from daemon: missing signature key").
This makes sure that we set the content-type properly for both
manifests and layers.
|
|
It looks like NixPkgs channels have moved. Fixing this URL allows
using nixos-20.09, for instance.
|
|
|
|
|
|
Extends storage.Persist to accept a Content-Type argument, which in
the GCS backend is persisted with the object to ensure that the object
is served back with this content-type.
This is not yet implemented for the filesystem backend, where the
parameter is simply ignored.
This should help in the case of clients which expect the returned
objects to have content-types set when, for example, fetching layers
by digest.
|
|
... if I don't mention this somewhere I'll probably never do it!
|
|
To ensure that registry clients which attempt to pull manifests by
their content hash can interact with Nixery, this change implements
persisting image manifests in the CAS in the same way as image layers.
In combination with the previous refactorings this means that Nixery's
serving flow is now compatible with containerd.
I have verified this locally, but CI currently only runs against
Docker and not containerd, which is something I plan to address in a
subsequent PR.
This fixes #102
|
|
Modifies the layer serving endpoint to be a generic blob-serving
endpoint that can handle both manifest and layer object "types".
Note that this commit does not yet populate the CAS with any
manifests.
|
|
This is going to be used for general content-addressed objects, and is
not layer specific anymore.
|
|
There is a new handler coming up to fix #102 and I want to avoid
falling into the classic Go trap of creating thousand-line functions.
|
|
|
|
Installing Cachix started failing on ARM64.
|
|
Permission changes in the Travis CI Nix builders have caused this to
start failing, as the build user now has insufficient permissions to
use caches.
There may be a way to change the permissions instead, but in the
meantime we will just cause things to rebuild.
|
|
|