-
Notifications
You must be signed in to change notification settings - Fork 2
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
Rework dockerization #16
Conversation
Under California law, all project contributions committed by me are copyright Google. This does not affect the license my patches are available under (Apache 2 / MIT), nor does it affect the contributions of any other individuals. This only applies for contributions I author while employed at Google. This does not grant Google the right to revoke my contributions from the project in the future.
This Dockerfile describes a multi-stage build that downloads a Racket prerelease Linux installer script and runs it in “in place” mode, resulting in a Docker image with `racket`, `raco`, `scribble`, etc. available from the command line. Build arguments allow customizing the base image used as well as the specific installer variant downloaded. Unix-style installs are not included yet due to difficulty in ensuring the installer itself is not included in the final image’s layers.
This Dockerfile installs the packages needed to run all non-GUI release tests. Running a release tester container executes those tests. Individual test commands are placed in a `test.sh` script, but ideally all of these tests would run with a single `raco test` command. Some non-GUI release tests still need adaptation to run properly in a container.
Doesn’t work yet. Requires a properly containerized xvfb server and installing several GUI-related foreign libraries.
These tests currently fail and need to be fixed in some way. Reasons for failure include known bugs and issues running inside a container, among other things.
The Racket installer and release tester dockerfiles download all the files they need from remote sources (except for the test scripts), so we use an “opt-in” rather than an “opt-out” ignore configuration. Note that Dockerfiles themselves must be included in the build context.
This tests four variants of a prerelease installer: one for each combination of a full or minimal distribution for either the x86_64 or i386 platforms. For each variant, the test verifies that: - An in-place install completes successfully - Racket code can be evaluated - Packages can be installed over HTTPS - The working non-GUI tests pass Tests still need to be included for the following: - Unix-style installations - Generated uninstall scripts - From-source builds, both with and without pre-built packages - GUI tests - `linux-natipkg` installers (which seem to have OpenSSL issues) Unfortunately, `docker-compose up —build` doesn’t work as nicely as it should because that runs tests in parallel, resulting in four parallel runs of the intensely memory-hungry database tests. Results in termination of containers with extreme prejudice.
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.
Woo!
Dockerfile.test
Outdated
|
||
FROM ${RACKET_IMAGE} | ||
|
||
RUN raco pkg install --auto --installation \ |
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 we should just install main-distribution-test
instead of most of these.
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.
Done, I think.
Actually, can you also fix the readme so that I know what to run? |
Ok, there are a few things missing from this:
I think that's it that this misses from the code I've written. |
It appears that the `distro-build-test` package isn’t included in the main distribution or its tests.
Would you prefer we add those cases before merging this PR or after? |
We can merge this PR first. There's a while before the next release cycle. |
I think we can merge this, and start working on further improvements. |
This PR changes how Docker is used to be more in line with Docker's philosophical assumptions and best practices. More pragmatically, it's now much easier to run the release tests for every installer variant, not just one. In-depth change descriptions can be found in each commit message.
Closes #2
Closes #3 (I think)
Closes #4
Closes #5
Closes #8
Closes #9
Closes #11
Closes #14
Copyright Google, see first commit for details.