createAndStartContainer in internal/service/deploy/deploy.go accepts an imageID string parameter but ignores it (uses _ blank identifier). Instead, buildContainerOptions constructs the image reference as upaas-<name>:<deploymentID> from the tag assigned during build.
The caller in deployContainerWithTimeout passes the imageID returned by buildImageWithTimeout, but it is never used.
Impact
Dead parameter. If the image tagging logic changes, this silent discard could mask bugs where the wrong image is deployed.
Fix
Either use the imageID parameter to set the container image (more correct - uses the actual image hash), or remove it from the signature.
## Bug
`createAndStartContainer` in `internal/service/deploy/deploy.go` accepts an `imageID` string parameter but ignores it (uses `_` blank identifier). Instead, `buildContainerOptions` constructs the image reference as `upaas-<name>:<deploymentID>` from the tag assigned during build.
The caller in `deployContainerWithTimeout` passes the `imageID` returned by `buildImageWithTimeout`, but it is never used.
## Impact
Dead parameter. If the image tagging logic changes, this silent discard could mask bugs where the wrong image is deployed.
## Fix
Either use the `imageID` parameter to set the container image (more correct - uses the actual image hash), or remove it from the signature.
Yes, absolutely. The imageID parameter is passed from Deploy() (line 558) but ignored with _. Meanwhile buildContainerOptions reconstructs the image reference as upaas-{name}:{deploymentID} (line 1101) — a mutable tag.
Using the image ID (digest) returned from docker build is more correct: it's immutable, avoids tag-reuse races if two deploys overlap, and is consistent with the pinned-references philosophy from #118.
I'll fix this — wire the imageID through to buildContainerOptions and use it as the Image field.
Yes, absolutely. The `imageID` parameter is passed from `Deploy()` (line 558) but ignored with `_`. Meanwhile `buildContainerOptions` reconstructs the image reference as `upaas-{name}:{deploymentID}` (line 1101) — a mutable tag.
Using the image ID (digest) returned from `docker build` is more correct: it's immutable, avoids tag-reuse races if two deploys overlap, and is consistent with the pinned-references philosophy from #118.
I'll fix this — wire the `imageID` through to `buildContainerOptions` and use it as the `Image` field.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Bug
createAndStartContainerininternal/service/deploy/deploy.goaccepts animageIDstring parameter but ignores it (uses_blank identifier). Instead,buildContainerOptionsconstructs the image reference asupaas-<name>:<deploymentID>from the tag assigned during build.The caller in
deployContainerWithTimeoutpasses theimageIDreturned bybuildImageWithTimeout, but it is never used.Impact
Dead parameter. If the image tagging logic changes, this silent discard could mask bugs where the wrong image is deployed.
Fix
Either use the
imageIDparameter to set the container image (more correct - uses the actual image hash), or remove it from the signature.@clawbot shouldn’t we be referring to images by id instead of name?
Yes, absolutely. The
imageIDparameter is passed fromDeploy()(line 558) but ignored with_. MeanwhilebuildContainerOptionsreconstructs the image reference asupaas-{name}:{deploymentID}(line 1101) — a mutable tag.Using the image ID (digest) returned from
docker buildis more correct: it's immutable, avoids tag-reuse races if two deploys overlap, and is consistent with the pinned-references philosophy from #118.I'll fix this — wire the
imageIDthrough tobuildContainerOptionsand use it as theImagefield.