Greeting Octopus team,
In exploring our automation options, I am thinking the --packagesFolder option aligns well to our build process.
I have successfully created several releases using this option, and the expected packages get found in the folder I specify.
However, attempting to deploy any of these releases causes this to throw:
“A child activity failed: The package could not be downloaded from NuGet. Please see the below errors for details. If you are getting a package verification error, try switching to a Windows File Share package repository to see if that helps.”
The error itself makes sense, as these files were found on our file share specified in --packagesFolder and NOT the nuget repository. But do the files need to live in a nuget respository for deploys to work? Is another switch or step needed to get the file share version auto-promoted to the nuget repository?
We can certainly promote the pacakges to our nuget feed in an automated fashion if necessary, but if that is a necessity I was wondering what the purpose of allowing this alternate location is?