https://garden.io logo
Join Discord
Powered by
<@729320201803530341> or <@347097380039950347> any...
# 💻｜contributing
c
@alert-helicopter-61082 or @swift-garage-61180 any chance for a quick pairing session today? I found a bug with versioning between action resolution stages that's causing problems down the line
The action spec validation[1] actually changes the spec in some cases (applies defaults etc). It seems that in some cases version string is calculated before and sometimes after, resulting in different versions. Can be reproduced by running 
gdev exec backend 'echo hello'
in the demo project Here's my diy call stack
Copy code
js
BaseAction.getFullVersion {
  name: 'backend',
  kind: 'Build',
  resolved: false,
  configVersion: 'v-b3c54e2cba',
  versionString: 'v-ef871fb126'
}
BaseAction.getFullVersion {
  name: 'backend',
  kind: 'Deploy',
  resolved: false,
  configVersion: 'v-0932abf706',
  versionString: 'v-013ea2e12a'
}
ResolveActionTask.process: validateSpec
BaseAction.getFullVersion {
  name: 'backend',
  kind: 'Build',
  resolved: true,
  configVersion: 'v-3a23be21fb',
  versionString: 'v-343eafe5f7'
}
ResolveActionTask.process: validateSpec
BaseAction.getFullVersion {
  name: 'backend',
  kind: 'Deploy',
  resolved: true,
  configVersion: 'v-b7658cb3a4',
  versionString: 'v-5ae88504ff'
}
compareDeployedResources { localManifestV: 'v-5ae88504ff', deployedV: 'v-5ae88504ff' }
compareDeployedResources { localManifestV: 'v-5ae88504ff', deployedV: 'v-5ae88504ff' }
compareDeployedResources { localManifestV: 'v-5ae88504ff', deployedV: 'v-5ae88504ff' }
BaseAction.getFullVersion {
  name: 'backend',
  kind: 'Deploy',
  resolved: true,
  configVersion: 'v-faf39fe647', // NEW CONFIGVERSION
  versionString: 'v-fc876cd88e', // NEW VERSIONSTRING
}
compareDeployedResources { localManifestV: 'v-fc876cd88e', deployedV: 'v-5ae88504ff' }
This is the diff that causes the changed configVersion (added by schema validation):
Copy code
diff
   variables: {
   },
   spec: {
+    buildArgs: {
+    },
+    dockerfile: "Dockerfile",
   },
   dependencies: [
   ],
1. https://github.com/garden-io/garden/blob/0.13-action-resolution/core/src/tasks/resolve-action.ts#L167
slack formatting is awesome
I'm signing off for today but I'd like to figure this out on Monday, will ping you then
a
It is expected that validation adds fields in some cases. There are scenarios where a resolved action should have a different version than the unresolved one. It's a little hard to read your log there, not sure when/where some of that is being logged.
Can you point to two cases where the version comes out different? A repro, basically
Then I can more easily dig in over the weekend
c
Maybe this is a bit more of a clear log 
gdev exec backend 'echo hello'
in demo-project
Copy code
Running command echo hello in service undefined runner

ℹ garden                    → Running in environment local.default
ℹ providers                 → Getting status...
✔ providers                 → Cached (in 0.8 sec)
ℹ providers                 → Run with --force-refresh to force a refresh of provider statuses.
ℹ graph                     → Resolving actions and modules...
✔ graph                     → Done (in 0.1 sec)
ℹ build.backend             → Build type=container name=backend is ready, nothing to do.
ℹ deploy.backend            → Deploying version v-5ae88504ff...
ℹ deploy.backend            → Deploying version v-5ae88504ff...
ℹ deploy.backend            → Waiting for resources to be ready...
ℹ deploy.backend            → Deployment/backend: Started container backend
ℹ deploy.backend            → Resources ready
✔ deploy.backend            → Done (in 5.2 sec)
ℹ deploy.backend            → Ingress: http://demo-project.local.app.garden/hello-backend
trying to run exec in deploy.backend v-2dee648ec6
âś– Deploy type=container name=backend is not running
Basically somewhere along the line either one of the versions is different due to the schema modifications
@alert-helicopter-61082 I think ^ should be clear enough The build.backend version changes causing a version in the deploy down the line in the middle of the exec command execution
a
Yup, that should be enough, thanks
Turns out the configuration was being modified by the plugin handler
PreviousNext
Powered by