I’ve inherited a build where Octopack is being used to package up a Web (MVC) application at build time via the OctoPack.targets that comes as part of the Octopack NuGet package. I’ve configured the EnsureOctoPackImported target occurs before the target AfterPublish which ensures the configuration transforms have already been run and the build output for the application has been produced and dropped in a .\Publish folder inside of the project root.
I notice that the nuget package is being created and pushed to the bin folder, as one might expect, however, it’s not being produced from the publish output. The transforms as well as the original configuration files are all included in the nuget package - I assume because the intended way to run the transforms in Octopus’s perspective is at deploy time.
I’d like to be tokenizing our web.config from web.release.config at build time and then have these tokens hydrated at deploy time by Octopus Deploy. The application of the transform files appears much more forgiving under MSBuild than it appears to be under Octopus and allows us to simplify by only needing a single transform for each configuration. For instance, if items in the transform don’t find corresponding items in the target configuration, it raises only a warning under MSBuild, but terminates the deployment under Octopus with a failure.
Can you advise on the intended stage of build and deployment Octopus intended development configurations to be tokenized and subsequently hydrated with target environment values?
Also, if we continue to do things this way where our publish folder contains the post-transformed configurations and binaries, is there a way to get Octopack to pack this Publish folder instead of consuming the web project files in project root?