Thanks for getting in touch with us regarding packaging and deployments!
If I understand correctly, you are trying to unpack the archived files, modify them, repackage & upload them with a new package ID, and then deploy them to Azure? As you’ve pointed out, package acquisition fails if it cannot find packages up front, and modifying packages fails the process too.
I think you have some options here that could work. However, to best help you some other details could provide me some context.
Is the environment that performs the package modifications special in some way?
I’m also keen to understand why the built in replacement features don’t/won’t work for you?
In a very general sense I think your options at this stage are one of the following:
Have two separate projects, one used for modifying the initial package and re-uploading it to Octopus, and one for deployment to Azure. You could automate triggering the second release using octo.exe, for example.
Consider leaning on your CI server and build chain to do the package modifications for you, and have one project in Octopus that only performs the Azure deployment. The build chain could upload both versions of the package if that was important for other deployments.
We’ve decided to separate Azure deployment to its own project and use “custom deployment scripts” and “custom installation directory” features as this seems do all the work we now do in separate steps.