This is the final piece. If 'sources' are defined, tar up
the sources and rewrite them accordingly. Pass it as build
build context to 'docker'.
This allows building from something like this:
├── etc
│ ├── foo
└── foo
├── Dockerfile
├── build.yml
└── main.go
With 'build.yml':
image: foo
extra-sources:
- ../etc:etc
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This commit adds the ability to add a build context to
docker for the package build. The build context is passed
on stdin to the docker process.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
If the build.yml specifies 'extra-sources', ie sources
outside the package directory, calculate the hash based on
the tree hash of all source directories and the package
directory.
Note, this requires the source directories to be under
git revision control.
Also clean up the src and dst of the path and stash the
result in the Pkg structure.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
In e8786d73bb the logwrite package will
automatically append .log to every log.
In 5201049f2c the init package will send
stderr of a service `s` to a log named `s` and the stdout to `s.out`.
Therefore the files we create on disk are `s.log` and `s.out.log`.
This patch modifies the memlogd `logwrite` command-line wrapper to use
the same convention.
Note there is a confusing name clash between `pkg/logwrite` and `cmd/logwrite`
in `memlogd` modified here.
Signed-off-by: David Scott <dave.scott@docker.com>
This commit adds support for authentication for image pulls for
'linuxkit build'. For each image reference we look up credentials
via the docker CLI configuration and use it if defined for
a given registry server. The code caches credentials to avoid
lookups for every image.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
A subsequent commit will enable support for private repositories.
This requires some functions from 'github.com/docker/cli' which
in turn relies on some newer versions of some of the vendored
packages here.
In this commit, update all packages used here to the versions
used by 'github.com/docker/cli' release 18.06 (the latest stable).
This requires vendoring a bunch of additional packages, such
as prometheus
Also run 'sort' over 'vendor.conf' to keep things in order.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- use the mkimage hashes that we had in LinuxKit as more up to date than tool.
- update docs
- move the code from moby under src/cmd/linuxkit
Signed-off-by: Justin Cormack <justin@specialbusservice.com>
These must have fallen through the crack during various
kernel updates. Move everything to the latest 4.14.x kernel.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
When logging directly to files (the not-using-memlogd case) the onboot
services must log to /run/log because /var/log might be overmounted
by a persistent disk. Therefore we create a symlink at the end of
the onboot section.
When logging via memlogd, all logs are buffered until a logwrite service
starts, so no symlink is needed.
Signed-off-by: David Scott <dave.scott@docker.com>
Also simplify the code by directly storing the path to
the log file in the LogFile structure.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The default Go tar has restrictions on filename length for example.
PAX is recommended over GNU.
Requires Go 1.10
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
For the initrd we only want to extract kernel, cmdline, and
the ucode CPIO archive. Skip whatever is left in ./boot
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This output produces a kernel and a root filesystem
in squashfs format. squashfs is a read-only, compressed
filesystem.
The 'kernel+squashfs' output can be used in a similar way as
the default 'kernel+initrd' output format with the benefit
that the rootfs does not consume any memory.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
We currently hardcode the Linuxkit/mkimage- images. This has the
unfortunate consequence that, if we update the LinuxKit image used
to generate the output, we have to update the Moby tool and then
vendor it back into the LinuxKit repository.
This commit introduces UpdateOutputImages() which allows a client
of the Moby tools package to selectively overwrite the packages
used to generate the outputs.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@gmail.com>
It is quite confusing that from the host or another container that
binds `/containers` you cannot see the bind mounts, you have to enter
the container namespace. I think `rshared` is a better default. You
can always be explicit and add `private` if you want a private bind mount.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This adds a namespace field to override the LinuxKit containerd
default namespace, in case you want to run a container in another
namespace.
Needs a patch in LinuxKit to implement this that I will open soon.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Annotations do not do anything by default but get passed through to the runtime,
which can be useful. I never metadata I didn't like...
Also fix sysctl to be a map in the validation, not an array. I can't see any
examples using this in LinuxKit, but this matches OCI so is correct.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This prepends 'ucode.cpio' to the initrd if present. Padding
should not be necessary as the ucode.cpio should be padded
to the right size.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
For now the backends for the different formats do not yet
use the extracted ucode cpio archive, but '// TODO' are
placed for the backends which should eventually handle it.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This extends the kernel filter to also look for the CPU microcode
file if specified in the YAML. If found, the ucode cpio archive
is placed into the intermediate tar file as '/boot/ucode.cpio'.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This optional option will allow users to specify a CPU
microcode cpio archive to be prepended to the initrd file.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
User specified mounts should be able to rely on the rootfs being mounted, in
particular for a writeable container they should expect the writeable overlay
to already be in place.
Signed-off-by: Ian Campbell <ijc@docker.com>
Since that bumps to gogo protobuf v0.5 too do the same.
Note that there are no actual containerd changes here, although there are some
gogo proto ones.
Signed-off-by: Ian Campbell <ijc@docker.com>
Rather than queueing up into a `bytes.Buffer`.
In my test case (building kube master image) this reduces Maximum RSS (as
measured by time(1)) compared with the previous patch from 2.8G to 110M. The
tar output case goes from 2.1G to 110M also. Overall allocations are ~715M in
both cases.
Signed-off-by: Ian Campbell <ijc@docker.com>
All of the `output*` functions took a `[]byte` and immediately wrapped it in a
`bytes.Buffer` to produce an `io.Reader`. Make them take an `io.Reader` instead
and satisfy this further up the call chain by directing `moby.Build` to output
to a temp file instead of another `bytes.Buffer`.
In my test case (building kube master image) this reduces Maximum RSS (as
measured by time(1)) from 6.7G to 2.8G and overall allocations from 9.7G to
5.3G. When building a tar (output to /dev/null) the Maximum RSS fell slightly
from 2.2G to 2.1G. Overall allocations remained stable at around 5.3G.
Signed-off-by: Ian Campbell <ijc@docker.com>
Following https://golang.org/pkg/runtime/pprof/. When attempting to build
images in https://github.com/linuxkit/kubernetes CI the process is mysteriously
being SIGKILL'd, which I think might be down to OOMing due to the resource
limits placed on the build container.
I haven't done so yet but I'm intending to use these options to investigate and
they seem potentially useful in any case, even if this turns out to be a
red-herring.
Signed-off-by: Ian Campbell <ijc@docker.com>
The syntax used for the yaml definitions is changed by the need to include the
substruct in the struct literal.
For the label switch to `ImageConfig` directly, which is actually more correct
in that it avoids spurious `name` and `image` fields in the label.
Signed-off-by: Ian Campbell <ijc@docker.com>
Where "config-related" here means "ones you might find in the
"org.mobyproject.config" label on an image.
By making this new struct an anonymous member of the existing Image struct the
Go json parser does the right thing (i.e. inlines into the parent) when parsing
a complete image (from a yml assembly) by default. The Go yaml library which we
use requires a tag on the anonymous field to achieve the same.
Signed-off-by: Ian Campbell <ijc@docker.com>
It appears that the `$GOPATH` in `working_directory` is being treated as a literal
`GOPATH` at least when processing the `state_artifacts.path`. Inlining it seems
to have worked, at the cost of some duplication.
Signed-off-by: Ian Campbell <ijc@docker.com>
Solv: Updated documentation to point out limits of
files section regarding /var, /run, and /tmp dirs.
Signed-off-by: Tristan Slominski <tristan.slominski@gmail.com>
Looks like a6b89f1137 ("Update linuxkit/mkimage-*") updated to a
non-existing tag.
linuxkit pkg show-tag tools/mkimage-iso-bios
linuxkit/mkimage-iso-bios:165b051322578cb0c2a4f16253b20f7d2797a502
and docker pull of that image works.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
These versions were created by https://github.com/linuxkit/linuxkit/pull/2607
which enables content trust, so drop the sha256 from all of them and ensure
DOCKER_CONTENT_TRUST is unconditionally set when running, since these
references are hardcoded we know they must be signed.
Signed-off-by: Ian Campbell <ijc@docker.com>
AFAICT none of the callers (which all involve one of `linuxkit/mkimage-*`) have
any reason to hit the network.
Signed-off-by: Ian Campbell <ijc@docker.com>
If the YAML file contains:
- path: etc/linuxkit.yml
metadata: yaml
in the fil section, the image was build with content trust,
then the linuxkit.yml file image contains fully qualified
image references (including the sha256).
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Instead of passing the image name as string use the a reference
to a containerd reference.Spec. This allows us, for example,
to update the reference in place when verifying content trust
with more specific information, such as the sha256
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
When constructing a Moby structure from a YAML also
extract a containerd reference.Spec for each image
and the kernel.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
We want to modify some of the content of the Image structure
and thus have to pass them by reference.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This is a tarball of the kernel, initrd and cmdline files, suitable for
sending to the mkimage images that expect this format.
Note you can't currently stream this output format using `-o` will clean this
up in future commits.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
The next commit will start using some components of containerd
so vendor the latest version.
The latest vndr also removed some un-needed files previously vendored.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
We are going to phase out the LinuxKit build option, in favour of keeping Docker
or a native Linux build option for CI use cases, as it is faster. So the
hyperkit option that only worked in one very limited use case is not needed.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Previously any Runtime specified in yml would completely override anything from
the image label, even if they set distinct fields. This pushes the merging down
to the next layer, and in the case of BindNS down two layers.
Most of the fields involved needed to become pointers to support this, which
required a smattering of other changes to cope. As well as the local test suite
this has been put through the linuxkit test suite (as of cc200d296a).
I also tested in the scenario which caused me to file #152.
Fixes#152.
Signed-off-by: Ian Campbell <ijc@docker.com>
This puts the build side in charge of the runtime layout, which enables
additional optimisations later, like sharing the rootfs if it is
used multiple times.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This could be used in LinuxKit now, as there are some examples, eg
https://github.com/linuxkit/linuxkit/blob/master/blueprints/docker-for-mac/base.yml#L33
which are creating containers to do a mount.
The main reason though is to in future change the ad hoc code that generates
overlay mounts for writeable containers with a runtime config which does
the same thing; this code needs to create both tmpfs and overlay mounts.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This adds a `runtime` section in the config that can be used
to move network interfaces into a container, create directories,
and bind mount container namespaces into the filesystem.
See also https://github.com/linuxkit/linuxkit/pull/2413
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Rather than using an initrd, unpack full filesystem for ISO BIOS.
Stream docker output direct to file rather than via a buffer, to save
memory.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
When we converted these to cpio we were not noticing that they
were invalid as they had incorrect paths as we converted the
path to a symlink anyway. Only the busybox images have hard links
in, the Alpine ones are symlinks anyway, which is why it was
less visible too.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Also do some code cleanup.
Related to #131 we need to read the OCI config to find if the container
is read only, not rely on the yaml, as it may just be set in the label.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
To work with truly immutable filesystems, rather than ones
we sneakily remount `rw`, we are going to use overlay for
writeable containers. To leave the final mount as `rootfs`,
in the writeable case we make a new `lower` path for the read
only filesystem, and leave `rootfs` as a mount point for an
overlay, with the writable layer and workdir mounted as a tmpfs
on `tmp`.
See https://github.com/linuxkit/linuxkit/issues/2288
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Unfortunately there are a lot of issues with resolv.conf as we
cannot actually write it into the image from any docker image, as docker will
always have something bind mounted in.
In addition, normally we expect the filesystem to br read only for images
that moby generates, so the actual etc/resolv.conf is likely not to be writeable.
Previously we were adding in a default resolv.conf into every image pointing at
Google's name servers but that is really a bad idea.
Instead, normal images now get an empty default, while images in the `init`
section will get a symlink, currently hard coded to `/run/resolvconf/resolv.conf`
but you can override this with the `files` section to be static or a different
link.
In future, if we have an easy way to build and extract images with user control
of this, we can drop this.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Some of these are arbitrary and just syncing for the sake of it, however the
image- and runtime-spec are relevant. Interesting changes:
- runtime spec:
- LinuxRLimit is now POSIXRLimit.
- Specs.Config is now a pointer.
- LinuxResources.DisableOOMKiller moved to
LinuxResources.LinuxMemory.DisableOOMKiller
- image spec:
- Platform.Features is removed (unused here).
Signed-off-by: Ian Campbell <ijc@docker.com>
This is a list of images to run on a clean shutdown. Note that you must not rely on these
being run at all, as machines may be be powered off or shut down without having time to run
these scripts. If you add anything here you should test both in the case where they are
run and when they are not. Most systems are likely to be "crash only" and not have any setup here,
but you can attempt to deregister cleanly from a network service here, rather than relying
on timeouts, for example.
Fix https://github.com/linuxkit/linuxkit/issues/1988
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Currently this supports "yaml" as the only option, which will output
the yaml config (as JSON) into the file specified in the image.
Fix#107
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Previously I was forcing them to be strings, which is horrible. Now you
can either specify a numeric uid or the name of a service to use the
allocated id for that service.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This removes the `lint` dependency from building Moby.
I've also added ineffassign to check ineffecutal assignments alongside
checks to ensure that both it and golint are installed.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
This includes https://github.com/moby/moby/pull/34040 which fixes Windows build
issues.
Note that this pulls in more than 500 (non merge) commits as well as the fix we
are interested in. A couple of new deps are pulled in, versions taken from
vendor/github.com/docker/docker/vendor.conf.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Continue to allow onboot to have duplicates as we do not run simultaneously
so that is ok (and we number them anyway), but services are run together
so we will get a runtime error if duplicated as this is the containerd/runc
id.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
We were pulling in this whole stack of packages just for `trust.ReleasesRole`.
Just define it locally.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Note that various fields have changed moved around in the JSON as a result:
* `Platform` has been removed.
* `Process` is now a pointer.
* `OOMScoreAdj` has moved into `Process`, from `Linux.Resources` (resolving a
TODO here).
Also updates golang.org/x/sys which is less critical.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
This adds the OCI parts needed into the yaml, but there are still
permissions issues in practise so marked as experimental.
It may just need further documentation to resolve the issues.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
In order to support not running containers as root, allocate
each of them a uid and gid, a bit like traditional Unix system
service IDs. These can be referred to elsewhere by the name of
the container, eg if you wish to create a file owned by a
particular esrvice.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Allow setting ambient capabilities, as a seperate option to the standard
ones. If you are running as a non root user you should use these.
Note that unless you add `CAP_DAC_OVERRIDE` and similar permissions you
need to be careful about file ownership. Added support to set ownership
in the `files` section to help out with this.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Rather than build the image and have something weird happen, let's check
that the capabilities specified are actually valid capabilities.
Signed-off-by: Tycho Andersen <tycho@docker.com>
- this is pretty much the smallest change to split this out and it
exposes a few things that can be improved later
- no change to logging yet
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- enable the hyperkit option by default on MacOS
- use it for creating raw disk images
fix#68
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This disables the code in LinuxKit's `/bin/rc.init` which attempts to detect an
unconfigured hostname and generate a unique (ish) version from the MAC address.
Anyone who wants a specific fallback hostname can populate `etc/hostname`
through the `files` stanza in their `yml` file.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
In the WIP code in `moby` we now have a standard base tarball format,
that includes the kernel and cmdline as files in `/boot` so that the
entire output of the yaml file can default to a single tarball. Then
this can be split back up by LinuxKit into initrd, kernel and cmdline
as needed. This will probably become the only output of the `moby build`
stage, with a `moby package` stage dealing with output formats.
We may remove the output format specification from the yaml file as well,
and just have it in the command.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Instead, make a hard link a symlink. This isn't much better, but it allows
some cases (e.g. installing GCC on moby via alpine) to work.
Signed-off-by: Tycho Andersen <tycho@docker.com>
This does not get everything where we want it finally, see #1266
nor the optimal way of building, but it gets it out of top level.
Added instructions to build if you have a Go installation.
Not moving `vendor` yet.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- remove remainder of editions code
- add a new check container to run tests without Docker
- switch over `make test` to use new command to build tests
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Also keep track of directory creation there, so you can explicitly
set directory permissions if required, and to avoid duplicates.
We should really keep track of files created elsewhere in the build
as well as we still might create some extras, but at least you can
set the write permisisons.
We can add uid, gid support too if required...
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This will add a Dockerfile which will build the contents into an
image and then call `tinit` to start it.
This is fairly experimental, but is a prototype for other non
LinuxKit outputs. The container will need to run as `privileged`
as `runc` needs quite a few capabilities and `containerd` needs to
mount.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- generally people refer to a plain disk image as `raw`
- `gcp` is shorter and it is the only image type supported
- remove `img-gz` as it is not needed. It does not really save space
as you have to build the full image and compress it anyway. On
many platforms the `raw` image will be a sparse file anyway,
even on the Mac soon.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This is a little ugly in terms of the validation now, but it is a move towards
splitting "build" and "package".
The "tar" output (and soon others) can output direct to a file or to stdout.
Obviously you can only build a single output format like this.
The LinuxKit output formats that build disk images cannot stream as they
have to build whole images. These allow multiple outputs.
In future we will probably change to
```
moby build | moby package
```
or similar, but that is a bit ugly, so currently have a compromise where
there are essentially two output types.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
GCP does not recognise the images, even though they appear identical to those made
by libguestfs and work on qemu fine. Their validation code does not like them for some
reason.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Each section will be appended in order of the CLI, other then
kernel where last specified one wins.
This is useful if you eg want to have a base version for (say)
AWS and GCP and then add your own image on top.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- does not require docker if user has qemu natively, will still fall back to docker
- allow specifying size for fixed size disk images
- add a raw disk output format
- more dogfooding
- marginally slower, but can be improved later
The images used to do the build are cached to make the process quicker.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Default to sharing net, ipc, uts namespaces between containers in config.
This makes most sense, as this is normal other than if we want to specifically
isolate system containers, in which case we will specify in config.
- explicitly support the value "new" if you want to isolate
- support the synonym "root" for "host" as in non LinuxKit setups it may
not actually be the host, it will be the current namespace.
- only support "none" as a synonym for "new" for network namespace where it is
carried over from Docker.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This removes outputs from yaml, instead you can do
```
moby build -output tar -output qcow2 file.yaml
```
or alternative syntax
```
moby build -output tar,qcow2 file.yaml
```
In future we may change this to be available in a `moby package`
step, but lets try this for now.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Using the label `org.mobyproject.config` will use that JSON
(or yaml, but it is very hard to get yaml into a label as newlines are
not respected) for parameters that are not explicitly set in the yaml file.
Had to change parameter definitions so override behaves as expected.
fix#16
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This is a fairly generic bootable disk with syslinux. Should
work if you dd it onto a USB stick, and should also work for AWS.
You need to uncompress it of course! Default size is 1G.
Will add cli option to set the size once I split out `moby build`
and `moby package` shortly.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Due to a missing else the tool would previously terminate with an error
message showing that the kernel or init image didn't exist, even if it
was pulled successfully. Invoking the tool again would continue to the
next image.
Signed-off-by: Magnus Skjegstad <magnus@skjegstad.com>
Add a canonical single tarball output format. This
adds kernel and cmdline to `/boot` where LinuxKit output
formats will find them.
Make the other output formats use that as a base.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
`docker create` will not pull an image so we need an additional fallback.
Rework the pull and trust code so it is in one place to facilitate this.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Also do not require `tar` to be in container, use the standard
image export code that we already have and find the files we
want.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This currently only changes the `gcp` target, but is the new
model - the `build` command will only do things locally, then
you need to `push` to an image store such as GCP or other ones
in order to `run` for platforms that cannot boot directly from
a local image.
Fix#1618
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
GCP defines some "standard" environment variables for project and
zone. Use them for 'moby run gcp'. Change the other environment
variables to follow the same pattern.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This uses the Packet.net API and iPXE to boot a Moby host.
There are several enhancements coming soon, such as SSH key
customisation, but this PR is sufficient to boot a host and
then use the web interface to get console access.
The user must currently upload the built artefacts to a public
URL and specify it via --base-url, e.g.:
moby run packet --api-key <key> --project-id <id> \
--base-url http://recoil.org/~avsm/ipxe --hostname test-moby packet
See #1424#1245 for related issues.
Signed-off-by: Anil Madhavapeddy <anil@docker.com>
This makes gcp behave in a similar way to the qemu backend.
The minimum size on GCP 1GB, whereas qemu uses 256MB.
Without this, the LTP tests fail on GCP.
Signed-off-by: Dave Tucker <dt@docker.com>
Adds an "access config" with a type of "ONE_TO_ONE_NAT" that
allows an instance to obtain an ephemeral IP address and access the
internet
Signed-off-by: Dave Tucker <dt@docker.com>
As suggested by @shykes these are clearer
- onboot for things that are run at boot time to completion
- services for persistent services
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This allows overriding the name used of the file in google storage,
image name or instance name. This will vary depending on how much `moby
run` is doing which is goverened by whether the positional argument
contains an `.img.tar.gz` or not.
For example:
`moby run gcp -img-name test-ea34d1 test` creates an instance called
`test-ea34d1` from the image `test`
`moby run gcp -img-name test-ea34d1` test.img.tar.gz` will upload the
file as `test-ea34d1.tar.gz`, create image `test-ea34d1` and create an
instance called `test-ea34d1`.
The use case for this is for CI to be able to spawn many concurrent test
machines and provide it's own name for them.
Signed-off-by: Dave Tucker <dt@docker.com>
- masked paths
- readonly paths
- allow attaching to existing namespaces, eg if bind mounted by a system container
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Pass version and git commit hash from the Makefile
into main.go. Add a 'version' subcommand to print
the information.
While at it also tweak the help output to only print the
command name and not the entire path.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Something like "moby-4.10.yml" did not work when invoked
like "moby build moby-4.10".
While at it, also allow .yaml as an extension.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This refactors the mount handling, without changing any defaults.
Any specification of a mount destination will override the default,
so if you want to make `sysfs` read only you can add
```
mounts:
- type: sysfs
options: ["ro"]
```
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This commit implements `moby run gcp` which allows for testing of moby
images on the Google Cloud Platform
This backend attaches (via SSH) to the serial console.
It generates instance-only SSH keys and adds the public key to the
image metadata. These are used by the `moby` tool only.
It will also automatically upload a file and creates an image if the prefix
given to `moby run` is a filename
Signed-off-by: Dave Tucker <dt@docker.com>
This commit uses the older GCP API as it supports both compute and
storage. As a result, we can now use either Application Default
Credentials that are generated using the `gcloud` tool or by supplying the
service account credentials in JSON format
Signed-off-by: Dave Tucker <dt@docker.com>
This adds every capability. We had this before the OCI changes as we
passed these values to Docker. Makes fully privileged containers less verbose.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
In the riddler change I changed "command" in the yaml to "args"
but did not change the files. In fact we basically used the
default command everywhere so this did not actually break.
Remove the unnecessary "command" lines to simplify yaml.
Revert the command to args change for now as I think I prefer
command, but its easier to switch now. Need to think if the
entrypoint/command distinction matters before finalizing.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
We are generally outputting to stdout pipe which the log driver does
not cope with very well; always did this in older builds.
Saves another 5% of build time.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Generated largely from the specified config; small parts taken from `docker image inspect`,
such as the command line.
Renamed some of the yaml keys to match the OCI spec rather than Docker Compose as
we decided they are more readable, no more underscores.
Add some extra functionality
- tmpfs specification
- fully general mount specification
- no new privileges can be specified now
For nostalgic reasons, using engine-api to talk to the docker cli as
we only need an old API version, and it is nice and easy to vendor...
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This is compatible with containerd 8353da59c6ae7e1933aac2228df23541ef8b163f
which was picked up by d2caae4c1a.
This required jiggering with riddler output some more to update to new OCI
config.json format for capabilities.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Add a -data option to the HyperKit "run" backend. This either
adds a string or a file to a ISO which is attached to the VM.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Separating command line option parsing from executing hyperkit
makes the code awkward with many parameters passed between functions.
Having everything in one function makes the code simpler.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This provides a consistent UX between build and run:
moby build foo # build from foo.yml
moby run foo # boot, e.g., foo-bzImage, foo-initrd.img
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Some users seem to have Docker for Mac/hyperkit in a non-standard
path. Allow them to specify the path to the hyperkit executable.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- Move HyperKit code into a separate file. It should be compilable
on all supported OSes now.
- Add a (optional) subcommand to "moby run" to select a backend
i.e., "moby run hyperkit [options] [prefix]"
- On macOS the default is "hyperkit" so that:
"moby run [options] [prefix]"
just works
- Add enough command line parsing to make it easy to add new
backends to the run command
Update help messages.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This formatter strips the prefix from Info() events to
make the default output of "moby build" more readable.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This adds log.Info() to the main steps of the "moby build"
process. By default the Info() output is shown to the user
so it provides some idea of progress and what is happening.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
docker-compose and other utilities use the .yml extension.
For consistency rename all .yaml to .yml
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
- this removes the use of riddler to extract the rootfs, use code
we were using for rootfs. riddler now just geenrates the config,
next stage is to generate this ourselves
- change the naming of the daemons so no longer include number as we
do not guarantee ordering as they start up simultaneously
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Corrected naming from vmware->vmdk and fixed Makfile
Fixed mistake outputting a vhd instead of a vmdk in output.go
Build vmdk image and added to Docker Hub, corrected link in output.go
Modified directories to confirm to standard mkimage-<imgType>
Signed-off-by: Dan Finneran <dan@thebsdbox.co.uk>
Removing the left over indirect creates that use the Docker socket
and run in containers not directly.
See #1347
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
'moby run' will use the kernel and initrd image produced
by 'moby build' and, on macOS, will run it inside a
hyperkit VM. This assumes that you have a recent version
of Docker for Mac installed as it re-uses the hyperkit
and VPNKit from it.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This does not get everything where we want it finally, see #1266
nor the optimal way of building, but it gets it out of top level.
Added instructions to build if you have a Go installation.
Not moving `vendor` yet.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Trying to find the relevant yaml file was an issue as we now support
`--name` and it might be in a different directory, so although it is
a bit verbose outputing a whole file at least it is more consistent.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- this needs improvements to make it more "platform native", in
particular GCP supports multiple users and more ssh key mangement
options.
- at present you can login as root with any platform ssh key
- add support for uts=host and ipc=host
- set the hostname from the metadata as well
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- the `public` option was not previously implemented
- add `replace` only for GCP images which will error otherwise. Only
recommended for use in development, in production use the `--name` option
to provide a different name eaxch time. Note only applies to GCP images,
will document these options properly soon.
- add a `family` option; this allows you to upload many images and the
user can select the latest using the `family` option instead of a specific
image.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This sets the base name of the built images which otherwise
defaults to the basename of your yaml file. This allows
building different versions easily eg adding git sha to the
output names.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This requires switching to the dosfstools from alpine:edge since neither the
busybox nor alpine:3.5 dosfstools supports the -C option (in fact alpine:3.5
only has mkfs.fat and not mkfs.vfat).
The 511k slack seems like a lot to me, but 256k was somehow not enough.
Fixes#1304.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
- the image upload uses the cloud API
- currently auth and image creation need the `gcloud` CLI tool.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- VHD is uncompressed VHD. Currently hard coded at 1GB, which may need to change. Use `format: vhd`
- GCE is the GCE compressed tarred raw image. Use `format: gce-img` - reserving `gce` for actually
uploading the image.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
from:
2017/03/07 09:59:30 Failed to extract kernel image and tarball
to
2017/03/07 10:06:04 Failed to extract kernel image and tarball: Unable to find image 'mobylinux/kernel:7fa748810d7866797fd807a5682d5cb3c9c98111' locally
Signed-off-by: Tycho Andersen <tycho@docker.com>
- remove remainder of editions code
- add a new check container to run tests without Docker
- switch over `make test` to use new command to build tests
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
Note that the EFI ISO is not yet automatically sized, and the
kernel command lines are currently hard coded in the builders.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- split out config processing a bit
- just use `capabilities` not `cap-add` and `cap-drop`
- allow use of CAP_ prefix on capabilities, as this is what `runc` uses
- add nginx to example config
- fix bind mounts
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
to build the example configuration. You can also specify different output formats, eg `linuxkit build -format raw-bios linuxkit.yml` to
output a raw BIOS bootable disk image, or `linuxkit build -format iso-efi linuxkit.yml` to output an EFI bootable ISO image. See `linuxkit build -help` for more information.
Since `linuxkit build` is built around the [Moby tool](https://github.com/moby/tool) the input yml files are described in the [Moby tool documentation](https://github.com/moby/tool/blob/master/docs/yaml.md).
### Booting and Testing
You can use `linuxkit run <name>` or `linuxkit run <name>.<format>` to
@@ -117,7 +115,7 @@ To customise, copy or modify the [`linuxkit.yml`](linuxkit.yml) to your own `fil
generate its specified output. You can run the output with `linuxkit run file`.
The yaml file specifies a kernel and base init system, a set of containers that are built into the generated image and started at boot time. You can specify the type
of artifact to build with the `moby` tool eg `linuxkit build -format vhd linuxkit.yml`.
of artifact to build eg `linuxkit build -format vhd linuxkit.yml`.
If you want to build your own packages, see this [document](docs/packages.md).
@@ -131,7 +129,7 @@ The yaml format specifies the image to be built:
-`services` is the system services, which normally run for the whole time the system is up
-`files` are additional files to add to the image
For a more detailed overview of the options see [yaml documentation](https://github.com/moby/tool/blob/master/docs/yaml.md)
For a more detailed overview of the options see [yaml documentation](docs/yaml.md)
@@ -37,6 +37,7 @@ A package source consists of a directory containing at least two files:
-`image`_(string)_: *(mandatory)* The name of the image to build
-`org`_(string)_: The hub/registry organisation to which this package belongs
-`arches`_(list of string)_: The architectures which this package should be built for (valid entries are `GOARCH` names)
-`extra-sources`_(list of strings)_: Additional sources for the package outside the package directory. The format is `src:dst`, where `src` can be relative to the package directory and `dst` is the destination in the build context. This is useful for sharing files, such as vendored go code, between packages.
-`gitrepo`_(string)_: The git repository where the package source is kept.
-`network`_(bool)_: Allow network access during the package build (default: no)
-`disable-content-trust`_(bool)_: Disable Docker content trust for this package (default: no)
git commit -a -s -m "pkgs: Update packages to latest alpine base"
git commit -a -s -m "pkgs: Update packages to the latest linuxkit/alpine"
git push $LK_REMOTE rel_$LK_RELEASE
```
@@ -232,6 +241,7 @@ git commit -a -s -m "Update package tags to $LK_RELEASE"
### Final preparation steps
- Update AUTHORS by running `./scripts/generate-authors.sh`
- Update the `VERSION` variable in the top-level `Makefile`
- Create an entry in `CHANGELOG.md`. Take a look at `git log v0.3..HEAD` and pick interesting updates (of course adjust `v0.3` to the previous version).
The `linuxkit build` command assembles a set of containerised components into in image. The simplest
type of image is just a `tar` file of the contents (useful for debugging) but more useful
outputs add a `Dockerfile` to build a container, or build a full disk image that can be
booted as a linuxKit VM. The main use case is to build an assembly that includes
`containerd` to run a set of containers, but the tooling is very generic.
The yaml configuration specifies the components used to build up an image . All components
are downloaded at build time to create an image. The image is self-contained and immutable,
so it can be tested reliably for continuous delivery.
Components are specified as Docker images which are pulled from a registry during build if they
are not available locally. The Docker images are optionally verified with Docker Content Trust.
For private registries or private repositories on a registry credentials provided via
`docker login` are re-used.
The configuration file is processed in the order `kernel`, `init`, `onboot`, `onshutdown`,
`services`, `files`. Each section adds files to the root file system. Sections may be omitted.
Each container that is specified is allocated a unique `uid` and `gid` that it may use if it
wishes to run as an isolated user (or user namespace). Anywhere you specify a `uid` or `gid`
field you specify either the numeric id, or if you use a name it will refer to the id allocated
to the container with that name.
```
services:
- name: redis
image: redis:latest
uid: redis
gid: redis
binds:
- /etc/redis:/etc/redis
files:
- path: /etc/redis/redis.conf
contents: "..."
uid: redis
gid: redis
mode: "0600"
```
## `kernel`
The `kernel` section is only required if booting a VM. The files will be put into the `boot/`
directory, where they are used to build bootable images.
The `kernel` section defines the kernel configuration. The `image` field specifies the Docker image,
which should contain a `kernel` file that will be booted (eg a `bzImage` for `amd64`) and a file
called `kernel.tar` which is a tarball that is unpacked into the root, which should usually
contain a kernel modules directory. `cmdline` specifies the kernel command line options if required.
To override the names, you can specify the kernel image name with `binary: bzImage` and the tar image
with `tar: kernel.tar` or the empty string or `none` if you do not want to use a tarball at all.
Kernel packages may also contain a cpio archive containing CPU microcode which needs prepending to
the initrd. To select this option, recommended when booting on bare metal, add `ucode: intel-ucode.cpio`
to the kernel section.
## `init`
The `init` section is a list of images that are used for the `init` system and are unpacked directly
into the root filesystem. This should bring up `containerd`, start the system and daemon containers,
and set up basic filesystem mounts. in the case of a LinuxKit system. For ease of
modification `runc` and `containerd` images, which just contain these programs are added here
rather than bundled into the `init` container.
## `onboot`
The `onboot` section is a list of images. These images are run before any other
images. They are run sequentially and each must exit before the next one is run.
These images can be used to configure one shot settings. See [Image
specification](#image-specification) for a list of supported fields.
## `onshutdown`
This is a list of images to run on a clean shutdown. Note that you must not rely on these
being run at all, as machines may be be powered off or shut down without having time to run
these scripts. If you add anything here you should test both in the case where they are
run and when they are not. Most systems are likely to be "crash only" and not have any setup here,
but you can attempt to deregister cleanly from a network service here, rather than relying
on timeouts, for example.
## `services`
The `services` section is a list of images for long running services which are
run with `containerd`. Startup order is undefined, so containers should wait
on any resources, such as networking, that they need. See [Image
specification](#image-specification) for a list of supported fields.
## `files`
The files section can be used to add files inline in the config, or from an external file.
```
files:
- path: dir
directory: true
mode: "0777"
- path: dir/name1
source: "/some/path/on/local/filesystem"
mode: "0666"
- path: dir/name2
source: "/some/path/that/it/is/ok/to/omit"
optional: true
mode: "0666"
- path: dir/name3
contents: "orange"
mode: "0644"
uid: 100
gid: 100
```
Specifying the `mode` is optional, and will default to `0600`. Leading directories will be
created if not specified. You can use `~/path` in `source` to specify a path in the build
user's home directory.
In addition there is a `metadata` option that will generate the file. Currently the only value
supported here is `"yaml"` which will output the yaml used to generate the image into the specified
file:
```
- path: etc/linuxkit.yml
metadata: yaml
```
Because a `tmpfs` is mounted onto `/var`, `/run`, and `/tmp` by default, the `tmpfs` mounts will shadow anything specified in `files` section for those directories.
## `trust`
The `trust` section specifies which build components are to be cryptographically verified with
[Docker Content Trust](https://docs.docker.com/engine/security/trust/content_trust/) prior to pulling.
Trust is a central concern in any build system, and LinuxKit's is no exception: Docker Content Trust provides authenticity,
integrity, and freshness guarantees for the components it verifies. The LinuxKit maintainers are responsible for signing
`linuxkit` components, though collaborators can sign their own images with Docker Content Trust or [Notary](https://github.com/docker/notary).
-`image` lists which individual images to enforce pulling with Docker Content Trust.
The image name may include tag or digest, but the matching also succeeds if the base image name is the same.
-`org` lists which organizations for which Docker Content Trust is to be enforced across all images,
for example `linuxkit` is the org for `linuxkit/kernel`
## Image specification
Entries in the `onboot` and `services` sections specify an OCI image and
options. Default values may be specified using the `org.mobyproject.config` image label.
For more details see the [OCI specification](https://github.com/opencontainers/runtime-spec/blob/master/spec.md).
If the `org.mobylinux.config` label is set in the image, that specifies default values for these fields if they
are not set in the yaml file. You can override the label by setting the value, or setting it to be empty to remove
the specification for that value in the label.
If you need an OCI option that is not specified here please open an issue or pull request as the list is not yet
complete.
By default the containers will be run in the host `net`, `ipc` and `uts` namespaces, as that is the usual requirement;
in many ways they behave like pods in Kubernetes. Mount points must already exist, as must a file or directory being
bind mounted into a container.
-`name` a unique name for the program being executed, used as the `containerd` id.
-`image` the Docker image to use for the root filesystem. The default command, path and environment are
extracted from this so they need not be filled in.
-`capabilities` the Linux capabilities required, for example `CAP_SYS_ADMIN`. If there is a single
capability `all` then all capabilities are added.
-`ambient` the Linux ambient capabilities (capabilities passed to non root users) that are required.
-`mounts` is the full form for specifying a mount, which requires `type`, `source`, `destination`
and a list of `options`. If any fields are omitted, sensible defaults are used if possible, for example
if the `type` is `dev` it is assumed you want to mount at `/dev`. The default mounts and their options
can be replaced by specifying a mount with new options here at the same mount point.
-`binds` is a simpler interface to specify bind mounts, accepting a string like `/src:/dest:opt1,opt2`
similar to the `-v` option for bind mounts in Docker.
-`tmpfs` is a simpler interface to mount a `tmpfs`, like `--tmpfs` in Docker, taking `/dest:opt1,opt2`.
-`command` will override the command and entrypoint in the image with a new list of commands.
-`env` will override the environment in the image with a new environment list. Specify variables as `VAR=value`.
-`cwd` will set the working directory, defaults to `/`.
-`net` sets the network namespace, either to a path, or if `none` or `new` is specified it will use a new namespace.
-`ipc` sets the ipc namespace, either to a path, or if `new` is specified it will use a new namespace.
-`uts` sets the uts namespace, either to a path, or if `new` is specified it will use a new namespace.
-`pid` sets the pid namespace, either to a path, or if `host` is specified it will use the host namespace.
-`readonly` sets the root filesystem to read only, and changes the other default filesystems to read only.
-`maskedPaths` sets paths which should be hidden.
-`readonlyPaths` sets paths to read only.
-`uid` sets the user id of the process.
-`gid` sets the group id of the process.
-`additionalGids` sets a list of additional groups for the process.
-`noNewPrivileges` is `true` means no additional capabilities can be acquired and `suid` binaries do not work.
-`hostname` sets the hostname inside the image.
-`oomScoreAdj` changes the OOM score.
-`rootfsPropagation` sets the rootfs propagation, eg `shared`, `slave` or (default) `private`.
-`cgroupsPath` sets the path for cgroups.
-`resources` sets cgroup resource limits as per the OCI spec.
-`sysctl` sets a map of `sysctl` key value pairs that are set inside the container namespace.
-`rmlimits` sets a list of `rlimit` values in the form `name,soft,hard`, eg `nofile,100,200`. You can use `unlimited` as a value too.
-`annotations` sets a map of key value pairs as OCI metadata.
There are experimental `userns`, `uidMappings` and `gidMappings` options for user namespaces but these are not yet supported, and may have
permissions issues in use.
In addition to the parts of the specification above used to generate the OCI spec, there is a `runtime` section in the image specification
which specifies some actions to take place when the container is being started.
-`cgroups` takes a list of cgroups that will be created before the container is run.
-`mounts` takes a list of mount specifications (`source`, `destination`, `type`, `options`) and mounts them in the root namespace before the container is created. It will
try to make any missing destination directories.
-`mkdir` takes a list of directories to create at runtime, in the root mount namespace. These are created before the container is started, so they can be used to create
directories for bind mounts, for example in `/tmp` or `/run` which would otherwise be empty.
-`interface` defines a list of actions to perform on a network interface:
-`name` specifies the name of an interface. An existing interface with this name will be moved into the container's network namespace.
-`add` specifies a type of interface to be created in the containers namespace, with the specified name.
-`createInRoot` is a boolean which specifes that the interface being `add`ed should be created in the root namespace first, then moved. This is needed for `wireguard` interfaces.
-`peer` specifies the name of the other end when creating a `veth` interface. This end will remain in the root namespace, where it can be attached to a bridge. Specifying this implies `add: veth`.
-`bindNS` specifies a namespace type and a path where the namespace from the container being created will be bound. This allows a namespace to be set up in an `onboot` container, and then
using `net: path` for a `service` container to use that network namespace later.
-`namespace` overrides the LinuxKit default containerd namespace to put the container in; only applicable to services.
An example of using the `runtime` config to configure a network namespace with `wireguard` and then run `nginx` in that namespace is shown below:
command: ["sh", "-c", "ip link set dev wg0 up; ip address add dev wg0 192.168.2.1 peer 192.168.2.2; wg setconf wg0 /etc/wireguard/wg0.conf; wg show wg0"]
runtime:
interfaces:
- name: wg0
add: wireguard
createInRoot: true
bindNS:
net: /run/netns/wg
services:
- name: nginx
image: nginx:alpine
net: /run/netns/wg
capabilities:
- CAP_NET_BIND_SERVICE
- CAP_CHOWN
- CAP_SETUID
- CAP_SETGID
- CAP_DAC_OVERRIDE
```
### Mount Options
When mounting filesystem paths into a container - whether as part of `onboot` or `services` - there are several options of which you need to be aware. Using them properly is necessary for your containers to function properly.
For most containers - e.g. nginx or even docker - these options are not needed. Simply doing the following will work fine:
```yml
binds:
- /var:/some/var/path
```
Please note that `binds` doesn't **add** the mount points, but **replaces** them.
You can examine the `Dockerfile` of the component (in particular, `binds` value of
`org.mobyproject.config` label) to get the list of the existing binds.
However, in some circumstances you will need additional options. These options are used primarily if you intend to make changes to mount points _from within your container_ that should be visible from outside the container, e.g., if you intend to mount an external disk from inside the container but have it be visible outside.
In order for new mounts from within a container to be propagated, you must set the following on the container:
1.`rootfsPropagation: shared`
2. The mount point into the container below which new mounts are to occur must be `rshared,rbind`. In practice, this is `/var` (or some subdir of `/var`), since that is the only true read-write area of the filesystem where you will mount things.
Thus, if you have a regular container that is only reading and writing, go ahead and do:
```yml
binds:
- /var:/some/var/path
```
On the other hand, if you have a container that will make new mounts that you wish to be visible outside the container, do:
log.Printf("Error creating symlink from %s to %s: %v",varLogLink,logDir,err)
}
logger.Symlink(varLogLink)
returnstatus
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
