ci: extract "slim" container to run functional tests and add multiprocess and tsan, drop unneeded packages
#6604
Conversation
kwvg
force-pushed
the
ci_slim
branch
5 times, most recently
from
e721036 to
55a0d0d
Compare
|
GitHub Actions run for 55a0d0d, https://github.com/kwvg/dash/actions/runs/13594731463 |
WalkthroughThis pull request implements updates across container configuration files, CI workflows, and build scripts. In the 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
ci/dash/test_integrationtests.sh (1)
67-67: Log File Handling: Switching fromcptomv
Changing from copying to moving the log files is acceptable if you intend to remove the source files after processing. Please verify that no subsequent process relies on the original log files remaining in the source directory.ci/dash/build_src.sh (1)
69-73: Conditional Linting Execution
Delegating linting to${BASE_ROOT_DIR}/ci/dash/lint-tidy.shwhenRUN_TIDYis true and not running in GitHub Actions is a cleaner approach. Please ensure that the linting script correctly propagates any errors so that lint failures aren’t silently ignored.contrib/containers/README.md (1)
3-4: Documentation Grammar Correction
The sentence “Containers that depends on other containers require BuildKit…” should be updated to “Containers that depend on other containers require BuildKit…” for correct subject-verb agreement.🧰 Tools
🪛 LanguageTool
[grammar] ~3-~3: The plural noun “Containers” expects the verb form “depend”.
Context: ...n files for containers. Containers that depends on other containers require BuildKit to...(NNS_THAT_VBZ)
contrib/containers/ci/ci.Dockerfile (1)
36-39: Update Alternatives Command Chain
The block that sets alternatives for MinGW compilers includes anexit 0at the end. This command is unnecessary and might mask potential errors in the preceding commands. Consider removingexit 0to ensure proper error propagation during the build.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
.dockerignore(1 hunks).github/workflows/build-container.yml(2 hunks).github/workflows/build-depends.yml(1 hunks).github/workflows/build-src.yml(2 hunks).github/workflows/build.yml(2 hunks).gitlab-ci.yml(3 hunks)ci/dash/build_src.sh(3 hunks)ci/dash/lint-tidy.sh(1 hunks)ci/dash/slim-workspace.sh(1 hunks)ci/dash/test_integrationtests.sh(1 hunks)contrib/containers/README.md(1 hunks)contrib/containers/ci/Dockerfile(0 hunks)contrib/containers/ci/ci-slim.Dockerfile(1 hunks)contrib/containers/ci/ci.Dockerfile(1 hunks)contrib/containers/develop/Dockerfile(2 hunks)
💤 Files with no reviewable changes (1)
- contrib/containers/ci/Dockerfile
✅ Files skipped from review due to trivial changes (1)
- ci/dash/slim-workspace.sh
🧰 Additional context used
🪛 LanguageTool
contrib/containers/README.md
[grammar] ~3-~3: The plural noun “Containers” expects the verb form “depend”.
Context: ...n files for containers. Containers that depends on other containers require BuildKit to...
(NNS_THAT_VBZ)
🔇 Additional comments (28)
.dockerignore (1)
2-3: Dockerfile Inclusion Update
The explicit inclusion ofci.Dockerfileandci-slim.Dockerfilealigns with the updated container build processes. Ensure that these are the only Dockerfiles meant to be included in the build context.ci/dash/build_src.sh (1)
14-14: Environment Cleanup Simplification
Combining the unsetting ofCC,CXX, andDISPLAYinto a single line improves conciseness and clarity.contrib/containers/README.md (1)
6-12: Container Table Clarity
The table clearly outlines the dependencies and purposes of the containers, which aids in understanding the build configuration.contrib/containers/ci/ci.Dockerfile (5)
1-4: Dockerfile Inheritance and Syntax Directive
Starting with the syntax directive and inheriting from./ci-slim.Dockerfileis correctly done. Please verify that the relative path is accurate within the build context.
41-55: Clang/LLVM Installation and Alternatives Setup
The installation commands for Clang, LLVM, and related tools are comprehensive. Just ensure that the package names and the variable${LLVM_VERSION}reflect the intended versions available in the base image.
65-67: LD_LIBRARY_PATH and IWYU Build Process
SettingLD_LIBRARY_PATHand building “include-what-you-use” is well organized. Verify that removing the cloned repository post-installation does not impact any debugging needs.
75-81: Cache Directory and Ownership Setup
The creation of cache directories and adjusting ownership using${USER_ID}and${GROUP_ID}is implemented correctly. Double-check that these variables are set appropriately to avoid permission issues.
82-84: Reverting to Non-Privileged User
Switching back to the non-privileged userdashis a sound security practice once all required installations are completed.ci/dash/lint-tidy.sh (5)
1-9: Initialization and Environment Setup Are ClearThe shebang, copyright notice, locale setting, and strict bash options are set up correctly. These early lines ensure portability and robust error handling.
10-13: Clear Warning and Prerequisite GuidanceThe warning comments (lines 10–12) clearly notify users about the need to generate the compilation database and set the correct build parameters before executing the script.
14-15: Directory Navigation and Linting ExecutionThe change directory command using
${BASE_ROOT_DIR}and${BUILD_TARGET}(line 14) and the subsequent execution ofrun-clang-tidypiped throughgrep(line 15) are implemented correctly.
Suggestion: Ensure that environment variables likeBASE_ROOT_DIRandMAKEJOBSare reliably defined in all runtime contexts.
17-25: IWYU Analysis IntegrationThe use of
iwyu_tool.pywith multiple paths and the mapping file (lines 18–25) is well structured. Redirecting the output to a temporary file usingteeis appropriate for subsequent processing.
27-29: Automatic Include Fixing and Diff ReportingCalling
fix_includes.pywith the IWYU output and displaying the differences viagit diff(lines 27–29) provides a streamlined post-processing step..github/workflows/build-src.yml (2)
73-76: Updated CCache Key with New Dockerfile ReferenceThe cache key now references
contrib/containers/ci/ci.Dockerfilealong with other dynamic inputs (lines 73–76), ensuring proper cache invalidation when the Dockerfile or dependent packages change.
90-97: Addition of Linting Step for Multiprocess BuildsThe new “Run linters” step (lines 90–97) for builds with the
linux64_multiprocesstarget is integrated correctly. It correctly exportsBUILD_TARGET, sources the matrix script, and calls the newlint-tidy.shscript..github/workflows/build.yml (3)
173-178: Transition to Slim Container for TestingUpdating the
test-linux64job (lines 173–178) to depend oncontainer-slimand using its output forcontainer-pathis a well-aligned change to leverage the slimmer build environment.
Follow-up: Verify that the slim container includes all the necessary binaries and dependencies for running these tests.
179-187: Addition of Multiprocess Test JobThe new
test-linux64_multiprocessjob (lines 179–187) follows a similar pattern by sourcing the container path fromcontainer-slim. This change is consistent and supports the refactored CI strategy for multiprocess builds.
207-214: TSAN Test Job Using Slim ContainerThe configuration for the
test-linux64_tsanjob (lines 207–214) correctly usescontainer-slim. This ensures that TSAN-specific tests run in the intended environment..gitlab-ci.yml (2)
32-33: Enablement of Docker BuildKitThe export of the environment variable
DOCKER_BUILDKIT=1(line 32) is an important addition that enables BuildKit for improved build performance and capabilities on GitLab CI.
60-61: Correct Dockerfile Reference for Cache KeyUpdating the cache key to reference
contrib/containers/ci/ci.Dockerfile(lines 60–61) assures that caching is based on the correct, updated Dockerfile..github/workflows/build-container.yml (2)
5-17: Introduction of Dynamic Inputs for Build ContextThe addition of new required input parameters (
context,file, andname) (lines 5–17) significantly enhances configurability. This allows dynamic specification of the build context and Dockerfile, which improves maintainability and reusability of the workflow.
60-70: Dynamic Docker Build and Caching ConfigurationThe modified “Build and push Docker image” step (lines 57–72) now dynamically references the inputs for context and file, sets multiple tags using both the repository and provided container name, and updates caching options. This flexibility supports a more robust CI process.
.github/workflows/build-depends.yml (1)
73-77: Updated Cache Keys AlignmentThe cache key and restore keys in the “Restore cached depends” step have been updated to reference
contrib/containers/ci/ci.Dockerfileinstead of the old path. This change correctly aligns the caching mechanism with the new Dockerfile naming convention. Please verify that any similar references in other workflows have also been updated for consistency.contrib/containers/ci/ci-slim.Dockerfile (2)
1-19: Effective Multi-Stage Build for CppcheckThe builder stage effectively compiles Cppcheck from source using a lightweight Debian-based image. The use of
set -exand subsequent cleanup (removal of temporary files and apt cache) are well implemented, ensuring a minimal build stage.
20-119: Comprehensive Setup for CI Slim ContainerThe final image stage uses
ubuntu:nobleas its base and correctly integrates the compiled Cppcheck binary, configuration files, and environment settings. The Dockerfile installs the essential packages, sets up Python via Pyenv, adds tools such as ShellCheck, and configures LLVM for sanitizer builds. Cleanup commands are in place to reduce image size.Optional improvement: Consider combining certain RUN commands to further minimize image layers, though the current implementation is already effective.
contrib/containers/develop/Dockerfile (3)
1-4: Syntax Directive and Base Image UpdateThe syntax directive is now updated to
devthefuture/dockerfile-xand the base image is set to./ci/ci.Dockerfile. This change is essential for proper Dockerfile inheritance and aligns with the objectives of the PR.
9-33: Enhanced Package Installation for Dash Qt SupportThe updated RUN command now installs additional libraries (e.g., various libxcb packages) required for supporting Dash Qt. The command sequence—including package installation with
${APT_ARGS}, followed by cleanup—is well-structured and clear.
42-47: GDB Configuration and Non-Privileged User SetupThe consolidated RUN step now handles several tasks: adding the
dockergroup, appending a sudoers entry for password-less sudo access, creating the GDB configuration directory, setting the auto-load safe path, and ensuring correct ownership of the home directory. This approach streamlines the configuration process.Suggestion: If more commands are added in the future, consider splitting them into separate RUN instructions to ease debugging and enhance readability.
|
Building container step fails in CI |
|
CI will fail because the tags used to fetch the container have been revised ( Since it's using Best way to test this PR would be to fork branch and run locally (comment). |
| - name: Run linters | ||
| if: inputs.build-target == 'linux64_multiprocess' | ||
| run: | | ||
| export BUILD_TARGET="${{ inputs.build-target }}" | ||
| source ./ci/dash/matrix.sh | ||
| ./ci/dash/lint-tidy.sh | ||
| shell: bash |
There was a problem hiding this comment.
why is this only for multiprocess?
There was a problem hiding this comment.
nevermind, it's because we only do the bear / clang stuff in this build for iwyu
|
CI on my branch is ok: https://github.com/PastaPastaPasta/dash/actions/runs/13902703835. |
|
This pull request has conflicts, please rebase. |
1 similar comment
|
This pull request has conflicts, please rebase. |
The upcoming slim container will be installing fewer packages than default to allow for TSan to work. Also lets us drop a few packages.
We don't need multiple (cross) compilers to run tests and GitHub Actions currently hamstrings our ability to thin down the runner using conventional means, so we thin down the container itself.
They don't need to be done in two separate layers, should save us a bit of time.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
contrib/containers/develop/Dockerfile (1)
9-33: Expanded package installation for Dash Qt support
The apt-get install command now includes several libraries (e.g.,libxcb-icccm4,libxcb-image0,libxcb-keysyms1, etc.) required for running Dash Qt. Please confirm that these additions are necessary and compatible with the overall environment.contrib/containers/README.md (1)
3-4: Grammar improvement suggestion
The sentence “Containers that depends on other containers…” should use the plural verb “depend” for subject–verb agreement. Consider updating it to: “Containers that depend on other containers require BuildKit to be enabled…”🧰 Tools
🪛 LanguageTool
[grammar] ~3-~3: The plural noun “Containers” expects the verb form “depend”.
Context: ...n files for containers. Containers that depends on other containers require BuildKit to...(NNS_THAT_VBZ)
contrib/containers/ci/ci.Dockerfile (1)
36-39: Error handling in alternatives update
The RUN command for setting update-alternatives ends withexit 0, which suppresses potential errors. Consider using a more granular approach (for example, appending|| trueto individual commands) to avoid masking underlying issues that could affect the build.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
.dockerignore(1 hunks).github/workflows/build-container.yml(2 hunks).github/workflows/build-depends.yml(1 hunks).github/workflows/build-src.yml(2 hunks).github/workflows/build.yml(2 hunks).gitlab-ci.yml(3 hunks)ci/dash/build_src.sh(3 hunks)ci/dash/lint-tidy.sh(1 hunks)ci/dash/slim-workspace.sh(1 hunks)ci/dash/test_integrationtests.sh(1 hunks)contrib/containers/README.md(1 hunks)contrib/containers/ci/Dockerfile(0 hunks)contrib/containers/ci/ci-slim.Dockerfile(1 hunks)contrib/containers/ci/ci.Dockerfile(1 hunks)contrib/containers/develop/Dockerfile(2 hunks)
💤 Files with no reviewable changes (1)
- contrib/containers/ci/Dockerfile
🚧 Files skipped from review as they are similar to previous changes (9)
- ci/dash/slim-workspace.sh
- ci/dash/test_integrationtests.sh
- ci/dash/build_src.sh
- .dockerignore
- .github/workflows/build-src.yml
- ci/dash/lint-tidy.sh
- .gitlab-ci.yml
- contrib/containers/ci/ci-slim.Dockerfile
- .github/workflows/build-depends.yml
🧰 Additional context used
🪛 LanguageTool
contrib/containers/README.md
[grammar] ~3-~3: The plural noun “Containers” expects the verb form “depend”.
Context: ...n files for containers. Containers that depends on other containers require BuildKit to...
(NNS_THAT_VBZ)
🔇 Additional comments (25)
contrib/containers/develop/Dockerfile (4)
1-1: Update Dockerfile syntax directive
Switching todevthefuture/dockerfile-xis in line with the new container build strategy. Ensure that team members are aware of any subtle syntax differences compared to the previous tool.
3-3: Changed base image reference
UsingFROM ./ci/ci.Dockerfileto inherit from a local Dockerfile now leverages a custom base image. Verify that this approach works consistently across all build targets.
42-47: Consolidated privilege and configuration commands
The single RUN step now appends to the sudoers file, creates the GDB configuration directory, sets an auto-load safe path, and changes ownership for/home/dash. This consolidation improves maintainability. Ensure that the environment variables (USER_IDandGROUP_ID) are correctly passed to avoid permission issues.
49-57: Secure user switch after configuration
Switching back to the non-privileged userdashis a good security practice. Verify that no further privileged operations are required after this point.contrib/containers/README.md (4)
6-12: Clear presentation of container roles and dependencies
The table neatly outlines container names, their dependencies, and their purposes. Double-check that these descriptions remain in sync with the actual container configurations in the repository.
16-18: Updated usage instructions for BuildKit and syntax extensions
Referencing [devthefuture/dockerfile-x] and Docker BuildKit enhances clarity for users. Please ensure the provided links and instructions are kept up-to-date with the latest recommendations.
24-27: Set up environment variables for Docker BuildKit
The instructions to exportDOCKER_BUILDKITandCOMPOSE_DOCKER_CLI_BUILDare well placed. Confirm that these settings are required for your specific Docker version and build context.
29-36: Clear container build and run instructions
The usage guide now shows straightforward commands for building and running the container with Docker Compose. Make sure the container name and configuration match the updated Dockerfile paths and settings in the repository.contrib/containers/ci/ci.Dockerfile (8)
1-1: New CI Dockerfile syntax directive
Correctly usingdevthefuture/dockerfile-xensures consistency with the new build configuration across the CI containers.
3-3: Base image layering on slim container
SettingFROM ./ci-slim.Dockerfilebuilds this image on top of the slim container, aligning with the goal to reduce image size while still including necessary build tools.
9-34: Installation of essential development packages
The RUN command installs a comprehensive set of packages (e.g., autoconf, automake, cmake, various compilers, etc.) needed for the build environment. Confirm that all installed packages are required and that${APT_ARGS}is defined in the build context.
41-55: Installation and configuration of Clang/LLVM tools
The steps for installing Clang, LLVM, and related tools—including setting up update-alternatives—are detailed and appear robust. Make sure that the variableLLVM_VERSIONis consistently defined and that the alternatives are correctly applied to all necessary binaries.
56-66: Setting LLVM library path
DefiningLD_LIBRARY_PATHto include/usr/lib/llvm-${LLVM_VERSION}/libis essential for runtime linking. Verify that this path exists and is appropriate for the installed LLVM version.
67-74: Integrating include-what-you-use build
Cloning, building, and installinginclude-what-you-useensures better code analysis during builds. Remember to monitor the repository branch (clang_${LLVM_VERSION}) for any updates that might conflict with your build process.
75-81: Creating and securing cache directories
The creation and chown-ing of/cache/ccache,/cache/depends, and/cache/sdk-sourceshelps optimize build caching. Ensure thatUSER_IDandGROUP_IDare set in the build environment to avoid permission issues.
82-84: Switch back to non-privileged user
Reverting toUSER dashis a sound security measure after performing privileged operations..github/workflows/build-container.yml (3)
5-17: Introduction of dynamic input parameters
New inputs (context,file, andname) increase the workflow’s configurability by allowing dynamic specification of the Docker build context, Dockerfile path, and container name. This change should streamline usage across different container builds.
19-22: Dynamically generated image tag
The output for the built container image now uses the dynamic inputs, which will help in identifying and caching the correct image version. Verify that the interpolation ofrepo,name, andtagproduces the expected image names in your registry.
60-70: Flexible Docker build and cache configuration
Replacing hardcoded paths with${{ inputs.context }}and${{ inputs.file }}ensures that the build step can be reused for different containers. The tagging and caching configuration usinghashFiles(inputs.file)and prepared outputs reinforces reproducible builds..github/workflows/build.yml (6)
16-23: Maintain legacy container build with updated parameters
Thecontainerjob still builds the main container (dashcore-ci-runner) using the updatedbuild-container.ymlworkflow. Confirm that any dependent jobs that still rely on this job properly reference its outputs.
24-31: Introduction of the slim container build job
The newcontainer-slimjob builds a slimmer image (dashcore-ci-slim) usingci-slim.Dockerfile. This aligns with the PR goal to reduce disk usage and improve build efficiency. Ensure that all test jobs now reference this new slim container where appropriate.
170-178: Updated dependency in linux64 test job
Thetest-linux64job now depends oncontainer-slim(instead of the original container) and onsrc-linux64. Verify that the output path fromcontainer-slimis being correctly propagated to subsequent test jobs.
179-187: Multiprocess test job configuration
The newtest-linux64_multiprocessjob leverages the slim container output and links tosrc-linux64_multiprocess. This configuration must be tested thoroughly to ensure that the multiprocess builds run as expected without the additional weight of the full container.
197-205: Consistent container-paths in additional test jobs
For jobs liketest-linux64_nowallet,test-linux64_sqlite, andtest-linux64_tsan, the updated configuration now consistently points to${{ needs.container-slim.outputs.path }}. This change should streamline dependency management across various test scenarios.
215-223: Uniform configuration for ubsan test job
Thetest-linux64_ubsanjob also uses the output fromcontainer-slim. As with the other test jobs, confirm that any downstream caching keys or build targets remain in alignment with the new slim container workflow.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
contrib/containers/README.md (3)
3-4: Fix grammatical error in container description.
The sentence "Containers that depends on other containers require BuildKit..." should use "depend" instead of "depends" to agree with the plural subject "containers".🧰 Tools
🪛 LanguageTool
[grammar] ~3-~3: The plural noun “Containers” expects the verb form “depend”.
Context: ...n files for containers. Containers that depends on other containers require BuildKit to...(NNS_THAT_VBZ)
20-23: Clarify BuildKit opt-in instructions.
The instructions for setting environment variables to enable BuildKit are clear. Consider mentioning which Docker versions require this opt-in behavior, as users might benefit from knowing the context or version constraints.
29-30: Enhance clarity in IDE extension usage.
The guidance on using Visual Studio Code's [Remote Containers] extension is helpful. To reduce redundancy, you may consider rephrasing "to run terminal commands from inside the terminal" to simply "to manage terminal commands" or similar.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.github/workflows/build-src.yml(2 hunks)ci/dash/build_src.sh(3 hunks)ci/dash/lint-tidy.sh(1 hunks)contrib/containers/README.md(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- ci/dash/lint-tidy.sh
- ci/dash/build_src.sh
- .github/workflows/build-src.yml
🧰 Additional context used
🪛 LanguageTool
contrib/containers/README.md
[grammar] ~3-~3: The plural noun “Containers” expects the verb form “depend”.
Context: ...n files for containers. Containers that depends on other containers require BuildKit to...
(NNS_THAT_VBZ)
🔇 Additional comments (2)
contrib/containers/README.md (2)
6-12: Review the container table layout.
The table clearly lists the container names, their dependencies, and purposes. Ensure that these details remain consistent with the actual container configurations as the project evolves.
16-17: Confirm the usage ofdockerfile-xsyntax extension.
The text now correctly references [devthefuture/dockerfile-x] and its role in leveraging Docker BuildKit. Verify that related documentation and Dockerfile updates align with this change.
|
GitHub Actions run for 76f99cd, https://github.com/kwvg/dash/actions/runs/14011864737 |
…r` and `develop` b8236c8 docs: add build badge from GitHub Actions runs on `master` and `develop` (Kittywhiskers Van Gogh) Pull request description: ## Motivation Since [dash#6604](#6604), we haven't seen GitHub Actions runners experience sporadic failures that aren't the result of test failures. In comparison, GitLab CI has been showing greater instability with its runners ([build](https://gitlab.com/dashpay/dash/-/jobs/9960288430), [build](https://gitlab.com/dashpay/dash/-/jobs/9922122668)). As GitHub Actions runners are now at coverage parity with GitLab CI, this pull request adds status badges for it in the same vein as [dash#3915](#3915). ## How Has This Been Tested?  ## Checklist - [x] I have performed a self-review of my own code **(note: N/A)** - [x] I have commented my code, particularly in hard-to-understand areas **(note: N/A)** - [x] I have added or updated relevant unit/integration/functional/e2e tests **(note: N/A)** - [x] I have made corresponding changes to the documentation **(note: N/A)** - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: UdjinM6: LGTM, utACK b8236c8 Tree-SHA512: 705f1be11274689c590029c0695737f2da2e47f2e8591b2a5113de91a2473eef6a24195d5d1918f5dcdaad63d364ac75867ddc3bf2b914d57fba22de1fcad4d8
Motivation
dash#6583 introduced functional tests to GitHub Actions and due to a combination of limited disk space available on runners and restrictions on ways to free up said disk space (as described in dash#6583),
multiprocessandtsanbuilds had to be excluded (commit).Despite measures to reign in disk usage (source), we are experiencing sporadic failures due to space exhaustion (build, build). To take care of this, we are going to extract portions of our
cicontainer intoci-slim, containing only the parts needed to run (sanitizer-enabled) binaries, functional tests and (some) linters.Additional Information
We have used
edrevo/dockerfile-plusto allow container definitions inherit other container definitions, which has allowed for a ready-to-use interactive container (develop) to be built on top of our CI container (ci) with ease (introduced in dash#4336).Unfortunately, since then, there has been little activity at
edrevo/dockerfile-plus, last code contribution was ~4 years ago (commit) and as this PR splits offcitoci-slim, it appearsdockerfile-plushas difficulty in working withDockerfilesthat inherit otherDockerfiles(see below).Error message:
To mitigate this, we are switching over to
devthefuture/dockerfile-x, which come with minor changes in syntax.devthefuture/dockerfile-x(likeedrevo/dockerfile-plus) relies on BuildKit, it has been explicitly enabled for GitLab, without which, it fails (build).As scoping in
Dockerfiles are relative to theDockerfileitself (source),develop/Dockerfilecan includeci/Dockerfileby setting the context one directory behind (which is possible for the rootDockerfile) but whenci/Dockerfileis parsed, it will search within thecifolder and not from the context folder set earlier and so, includingci-slim/Dockerfilewould come up empty as it would resolve toci/ci-slim/Dockerfile, which doesn't exist.To work around this, both
ciandci-slimdefinitions need to share the same directory and to allow for that,ci/Dockerfileis nowci/ci.Dockerfile, so thatdevelop/Dockerfilecan set the context a directory behind, findci/ci.Dockerfile, which will search withincifor./ci-slim.Dockerfile, which will be found successfully.We have switched away from using the official LLVM installation script to importing the repository manually as we need only a select few packages to run sanitizer-enabled builds and functional tests and the script only gives you a choice between default packages and all packages.
ci-slimcontainer was most desirable, doing so breaks sanitizer builds (build)Space occupied by containers.
Calculated by modifying
develop/docker-compose.ymlto point at differentDockerfiles and building them withdocker compose, then passing them to dive v0.12.0.cidevelop(26ea618)developdevelop(26ea618)ci-slimcidevelopChecklist