OctopusDeploy
Octopus.Deployment.ForcePackageDownload and Octopus.RunbookRun.ForcePackageDownload variable values aren't respected
Team
- [X] I've assigned a team label to this issue
Severity
No customers blocked
Version
2021.3.7124
Latest Version
I could reproduce the problem in the latest build
What happened?
When setting the variable Octopus.RunbookRun.ForcePackageDownload on a runbook, and Octopus.Deployment.ForcePackageDownload on a deployment, it appears that these values don't affect the way Octopus forces the package to be downloaded from the Built-in repository or external feed.
Reproduction
Set the project variables Octopus.RunbookRun.ForcePackageDownload and Octopus.Deployment.ForcePackageDownload to True.
Set a deployment process to deploy a package. Deploy once, then repeat again to force a cache of the package. Note that the deployment or runbook ignores the variable value
Error and Stacktrace
No response
More Information
Internally, a discussion was had (private link) that suggested the UI option effectively set the variable to the value True/False rather than being able to control its value by use of a Project variable.
At a minimum, we should confirm what the expected behavior of these variables are since they are documented here with the following description:
If true, the package will be freshly downloaded from the feed/repository regardless of whether it is already present on the endpoint (Boolean)
Workaround
From testing the only way to force a runbook or deployment is to toggle the Package download option to be Re-download packages from feed:
This allows the package to be downloaded:
However, this results in the two variables having no ability to change Octopus behavior when downloading packages from the feed.
Customer report of this issue: https://octopus.zendesk.com/agent/tickets/82971
I was on a call with a user last Friday and the customer(tangentially to the call problem) said he would prefer it always downloaded the package, and unfortunately, this variable wasn't working for us on the call when we attempted to use it.
Got another customer who has reported this (https://octopus.zendesk.com/agent/tickets/87662 - internal)
@mik-ky - Should #15914 allow the behavior to be altered by using the two variables in a project e.g. like so:
Running a quick test on 2023.2.2072 (where the new option is in Deployment Settings) doesn't show the variables having any effect.
Another report of this issue [internal]: https://octopus.zendesk.com/agent/tickets/142053
Another report of this (internal) - https://octopus.zendesk.com/agent/tickets/171192 This is affecting customer deployments and they are not able to use the force package download project settings as it is not working for them for some reason.
They are running Octopus version 2023.4.8154 and I can replicate this on my own instance of 2023.4.8279 with a basic parent child project setup.
The customer had luck when they put debugging variables on their project, which did force the task to honour the forcepackage variable, but after taking the debugging variables off again, the project went back to using the cache.
Diving into this a bit more with Clare, we were able to determine there is a bit of a hierarchy for what controls the ForcePackageDownload variable.
From our testing, we found the following was true, were the leftmost item takes precedence:
Project settings -> Runtime settings (via the Deploy release page) -> Explicitly set variable
When using the Deploy a Release step, we found that the child Project inherits the value as follows: Projects settings of parent -> Runtime settings of parent -> Explicitly set variable on parent (maybe) -> Anything set on the child project
Perhaps there is an opportunity to approach this variable/feature slightly differently. Below is a screenshot mockup of a thought I had:
In this case, the default would be the Project settings and any other option selected when deploying a Release would overwrite the variable with the explicitly selected option. I don't think there any changes are necessary for child projects as I can't think of a better way to "trickle down" to a child project than the current implementation.
