-
Notifications
You must be signed in to change notification settings - Fork 273
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
fix(module-conversion): always include build deps #5671
Conversation
Does this account for the fact that build dependencies can be specified as:
and
I'm assuming that's normalized earlier in the flow but just wanted to confirm. |
8f65982
to
8f9a0f9
Compare
Good question—yeah, that's indeed handled by the conversion logic. The build & runtime dependencies are passed through these helpers, respectively: https://github.com/garden-io/garden/blob/main/core/src/resolve-module.ts#L742-L762 |
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 fixing this! 👍
Before this fix, build dependencies weren't being transferred to the generated actions in all cases. This was a problem e.g. if using a `helm` module with a build dependency on a `container` module, whose built image was referenced in the chart (since the missing build dependency meant that the image wasn't necessarily ready by the time the deploy started). This was fixed by simply ensuring that any explicit build dependencies (i.e. under `module.build.dependencies`) are included in the dependencies of any generated runtime actions (Deploys, Tests and Runs). This reflects the 0.12-era semantics, where every test, service and task had a build dependency on the module's build step, which in turn respected any build dependencies declared on the module (under `build.dependencies`).
In the module conversion logic for the `persistentvolumeclaim` type, we don't generate any Build actions (just a single Deploy). This means we shouldn't declare a build dependency for it (since we'd be declaring a dependency on an action that won't exist after the conversion).
Sometimes, it's convenient to see the logger output while debugging test suites. By default, we use the `quiet` logger (which doesn't log anything). Here, we introduce two new env vars for testing, `GARDEN_TESTS_SHOW_LOGS` and `GAREDEN_TESTS_LOG_LEVEL`.
8f9a0f9
to
dddad42
Compare
This is a follow-up to #5671 (see `47c24d5`). We also need to remove the added dependencies on the build steps of `persistentvolumeclaim` modules, since the converted actions there don't include a Build action. Although this hasn't been reported yet, this would result in missing dependency errors when executing Runs or Tests that come from `container` modules which mount a `persistentvolumeclaim` module (using the `volumes` config field for `container` module services).
* fix(module-conversion): more fixes to PVC type This is a follow-up to #5671 (see `47c24d5`). We also need to remove the added dependencies on the build steps of `persistentvolumeclaim` modules, since the converted actions there don't include a Build action. Although this hasn't been reported yet, this would result in missing dependency errors when executing Runs or Tests that come from `container` modules which mount a `persistentvolumeclaim` module (using the `volumes` config field for `container` module services). * test: fix tests --------- Co-authored-by: Vladimir Vagaytsev <[email protected]>
What this PR does / why we need it:
Before this fix, build dependencies weren't being transferred to the generated actions in all cases.
This was a problem e.g. if using a
helm
module with a build dependency on acontainer
module, whose built image was referenced in the chart (since the missing build dependency meant that the image wasn't necessarily ready by the time the deploy started).This was fixed by simply ensuring that any explicit build dependencies (i.e. under
module.build.dependencies
) are included in the dependencies of any generated runtime actions (Deploys, Tests and Runs).This reflects the 0.12-era semantics, where every test, service and task had a build dependency on the module's build step, which in turn respected any build dependencies declared on the module (under
build.dependencies
).Which issue(s) this PR fixes:
Fixes #5667