-
Notifications
You must be signed in to change notification settings - Fork 24.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce packaging tests for Docker #46599
Introduce packaging tests for Docker #46599
Conversation
Add packaging tests for our Docker images, similar to what we have for RPMs or Debian packages. This works by running a container and probing it e.g. via `docker exec`. Test can also be run in Vagrant, by exporting the Docker images to disk and loading them again in VMs. Docker is installed via `Vagrantfile` in a selection of boxes.
Pinging @elastic/es-core-infra |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work this is really needed after integrating the Docker parts from the old separate repo!
I took an initial pass and left some comments.
qa/os/src/test/java/org/elasticsearch/packaging/util/Docker.java
Outdated
Show resolved
Hide resolved
qa/os/src/test/java/org/elasticsearch/packaging/util/Docker.java
Outdated
Show resolved
Hide resolved
qa/os/src/test/java/org/elasticsearch/packaging/util/Docker.java
Outdated
Show resolved
Hide resolved
Vagrantfile
Outdated
@@ -183,6 +183,35 @@ def deb_common(config, name, extra: '') | |||
install_command: 'apt-get install -y', | |||
extra: extra_with_lintian | |||
) | |||
deb_docker(config) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed privately, there's not much value running this on all distros (and not all support Docker like centos-6) so better be specific about where we call this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be better to bake this into the image rather than install on-demand.
The CI packaging images already have docker ( at least the ones that support it ),
so we would need to add it to vagrant images only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll sync with Infra about this, and remove it from Vagrantfile
once the boxes include Docker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking this on!
Unfortunately we don't have Pr checks for running these directly on jenkins workers, so it would be nice to test this before merging to make sure the CI jobs don't break.
Vagrantfile
Outdated
@@ -183,6 +183,35 @@ def deb_common(config, name, extra: '') | |||
install_command: 'apt-get install -y', | |||
extra: extra_with_lintian | |||
) | |||
deb_docker(config) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be better to bake this into the image rather than install on-demand.
The CI packaging images already have docker ( at least the ones that support it ),
so we would need to add it to vagrant images only.
buildSrc/src/main/java/org/elasticsearch/gradle/DistributionDownloadPlugin.java
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,2 @@ | |||
// This file is intentionally blank. All configuration of the | |||
// export is done in the parent project. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need a project for the extraction ? Could it just be a task on parent ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's to do with DistributionDownloadPlugin
- as far as I can tell, it's written to create depdencies between ES distributions and the default
config on a project. I'm new to Gradle, but it looks like it doesn't depend on a task because the plugin needs to be able to locate the built archives. I'd be very happy to be pointed at better ways of doing this. I had to spend a while deciphering what was going on between DistroTestPlugin
and DistributionDownloadPlugin
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, the same pattern is used in :distribution:packages
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, it's a bit strange that this we have projects for export only here, but I'll defer to @rjernst
qa/os/src/test/java/org/elasticsearch/packaging/test/PackagingTestCase.java
Show resolved
Hide resolved
@elasticmachine run elasticsearch-ci/1 |
@elasticmachine run elasticsearch-ci/packaging |
Mysterious - for some reason, the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a few more contents related to the Vagrantfile.
Vagrantfile
Outdated
@@ -185,6 +191,34 @@ def deb_common(config, name, extra: '') | |||
) | |||
end | |||
|
|||
def deb_docker(config) | |||
config.vm.provision 'install Docker using apt', run: 'always', type: 'shell', inline: <<-SHELL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is run: 'always'
here on purpose? Do we intend to attempt to install docker on every vagrant up/reload
operation? Details here.
Thanks @dliappis - facepalms aplenty. 🤦♂ |
@elasticmachine update branch |
@elasticmachine run elasticsearch-ci/packaging |
@elasticmachine run elasticsearch-ci/packaging as there was a transient error. |
@elasticmachine run elasticsearch-ci/packaging as Jenkins restarted. |
It turns out that it's not the same as Debian.
CI is green if someone would like to give me a LGTM? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
We still have to make sure this works with the new workers.
If #46924 is merged, PR checks for it are coming soon, if this happens to be merged before, I'll re test to make sure before merging mine.
@atorok is your PR close to merging? I don't mind waiting if it is. |
Yes it is. |
@elasticmachine update branch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the work here! Better testing of our docker images is greatly needed.
After reading through this, it appears we are running docker within each VM. At first I was confused by this, but I guess this matches up with docker being another distribution, and we want to test it on each platform (similar to how we test java on each platform).
One general thing I noticed though is we seem to have duplicated a lot of the assertions that exist within the archive tests. This would mean making any change to the archive structure would require changing multiple tests. Could we reuse these assertions?
@@ -370,7 +370,8 @@ private static void addDistro(NamedDomainObjectContainer<ElasticsearchDistributi | |||
if (type == Type.ARCHIVE) { | |||
d.setPlatform(platform); | |||
} | |||
d.setBundledJdk(bundledJdk); | |||
// We don't test Docker images with a non-bundled JDK | |||
d.setBundledJdk(type == Type.DOCKER || bundledJdk); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be handled outside of addDistro, otherwise we are adding the same distribution twice? ie around line 325 where this method is called
distro.getPlatform(), | ||
distro.getFlavor(), | ||
// We don't test Docker images with a non-bundled JDK | ||
type == Type.DOCKER || distro.getBundledJdk()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't be necessary, see my previous comment about where we add the distros. We should never add a docker distro with bundledJdk=false
distribution/docker/build.gradle
Outdated
if (subProject.name.contains('docker-export')) { | ||
apply plugin: 'distribution' | ||
|
||
def oss = subProject.name.startsWith('oss') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use static types. It makes the code easier to reason about, eg String here.
/** | ||
* Check that a keystore can be manually created using the provided CLI tool. | ||
*/ | ||
public void test40CreateKeystoreManually() throws InterruptedException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't really match with the pattern we've been working towards. We want test classes for categories of checks, like keystore related (which @williamrandolph has been splitting out in a separate PR). Which distribution is being used should not matter to the test, only that we know how to do primitive operations for the given distribution (eg start, stop, run cli tool, etc)
* Check whether the elasticsearch-certutil tool has been shipped correctly, | ||
* and if present then it can execute. | ||
*/ | ||
public void test90SecurityCliPackaging() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We definitely don't want to have copies of every test in archive tests. Most of that class needs to be broken up. I wonder if in the interum ArchiveTests could be adapted to run when docker type is used?
@@ -57,12 +64,17 @@ public boolean isPackage() { | |||
return packaging == Packaging.RPM || packaging == Packaging.DEB; | |||
} | |||
|
|||
public boolean isDocker() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this needed? It doesn't seem any clearer than packaging == Packaging.DOCKER
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest I was copying the pattern of the existing code. e.g. isArchive()
is only called in one place 🤷♂. I can remove it.
).forEach(dir -> assertPermissionsAndOwnership(dir, p755)); | ||
|
||
Stream.of( | ||
"elasticsearch", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should copy everything that is in Archives. This can (and will) get out of sync. I think we need to think more about how to decouple the checks so they can run agnostically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about I do that in a follow-up PR? This one has been waiting to merge for a while. I can then take the time to refactor the packaging tests more generally.
@pugnascotia sorry I missed this during review, we really want to back-port testing and build related changes like this, especially anything that changes the build code needs to be back-ported so the code doesn't diverge making it easy to port improvement to older branches that are still built in CI. |
No problem, happy to backport. Re: the CI failure, it looks like the |
I added more details to #47639 there's more to it, and some of the tests fail too |
Closes elastic#37617. Add packaging tests for our Docker images, similar to what we have for RPMs or Debian packages. This works by running a container and probing it e.g. via `docker exec`. Test can also be run in Vagrant, by exporting the Docker images to disk and loading them again in VMs. Docker is installed via `Vagrantfile` in a selection of boxes.
Backport of #46599 and #47640. Add packaging tests for Docker. * Introduce packaging tests for Docker (#46599) Closes #37617. Add packaging tests for our Docker images, similar to what we have for RPMs or Debian packages. This works by running a container and probing it e.g. via `docker exec`. Test can also be run in Vagrant, by exporting the Docker images to disk and loading them again in VMs. Docker is installed via `Vagrantfile` in a selection of boxes. * Only define Docker pkg tests if Docker is available (#47640) Closes #47639, and unmutes tests that were muted in b958467. The Docker packaging tests were being defined irrespective of whether Docker was actually available in the current environment. Instead, implement exclude lists so that in environments where Docker is not available, no Docker packaging tests are defined. For CI hosts, the build checks `.ci/dockerOnLinuxExclusions`. The Vagrant VMs can defined the extension property `shouldTestDocker` property to opt-in to packaging tests. As part of this, define a seperate utility class for checking Docker, and call that instead of defining checks in-line in BuildPlugin.groovy
Closes #37617. Add packaging tests for our Docker images, similar to what we have for RPMs or Debian packages. This works by running a container and probing it e.g. via
docker exec
. Test can also be run in Vagrant, by exporting the Docker images to disk and loading them again in VMs.Notes:
Vagrantfile
in a selection of boxes. We could change the boxes built by Infra if we felt it was worthwhile, I wasn't sure.