Using slowcheetah with our projects we have transform files like App.{Environment}.config.
It would have been awesome if OctoPack could rename these transform files to what OD expects. Or if OD can identify app.{Environment}.config and apply these transformations.
I know to of the extra config transformations we can put in like app.#{Octopus.Environment.Name}.config => app.config
But we would like not to have this defined inside octopus deploy and be closer to source and really not worry about it as we currently having a post build event to copy all files into the format OD understands.
I can provide a pull request but would understand if this will be viable and where would it be appropiate in octopack or OD itself.
When you say we currently having a post build event to copy all files into the format OD understands, what do you mean by format exactly? Octopus relies 100% on the name of the config file, and gives you the option of A) having the file with the exact same name of the environment on the file name or B) adding an extra config rule if your files don’t match the environment name.
I believe Octopus provides enough flexbility for pretty much all use cases. What prevents you from adding the extra config transform rule in the format app.#{Octopus.Environment.Name}.config => app.config if your files dont 100% match the environment name?
What does your current post build event exactly do to your file names? I’m asuming it only changes their names, but from what to what?
I meant the file name format, we take for example App.Production.config and rename it to MyApp.exe.Product.config and include them through the nuspec files for OctaPack to include into the package. This is kind of a pain point for every project/deploy we create. Nothing prevents us from adding the extra config transform rule, it just adds extra complexity, the one extra thing that we need to remember creating a new deploy. If we can strive to not worry about this, like web projects, it would just make it that little bit simpler.
One thing I don’t understand is why do you rename App.Production.config to MyApp.exe.Product.config and then include them through nuspec files for Octopack to grab it.
Couldn’t you rename the file in source control so its already named MyApp.exe.Product.config during the build process, and also mark the file’s Build Action property to “Content” so Octopack always includes it on the package without the need of a Nuspec file?
I honestly don’t see us adding a config rename task to Octopack, so what I’m trying to recommend here is to rename the file in Source Control to whatever Octopus expects, so the file already has the final name that It’ll need during the deployment.
Now, if you don’t want to go through the renaming process, I’m afraid that adding the rule in the Octopus step would be the only way to go. That’s something you’ll only have to do once though (neither the rule or the config file will change in the future).
Dalmiro, the reason we don’t rename the file in source control to be already named MyApp.exe.Production.config is because we use SlowCheetah that does build transforms on App.config and that of remembering to rename files when we have to rename projects.
I’m afraid the only way around this in Octopus is to either name the files MyApp.exe.Production.config or add the explicit rules in the “additional config transform” field. This seems to cover pretty much all the cases for your users, as its not that common to rename config files and change the deployment process too often.
If you’d like I can reach out to one of our devs and ask him to point you into the right direction to add this custom task in the code. Please know that I’m not 100% if this functionality is exposed in one of our OSS projects.
Thank you for getting in touch and offering to add the feature. If we have that feature on by default, I’d be concerned that we break other people who rely on that behaviour not being there. If we didn’t have it on by default, you would still need to remember to switch it on for each project. Another wrinkle may be figuring out what the correct executable is.
The code involved is open source (https://github.com/OctopusDeploy/OctoPack) and you can create a fork for your customisation. As mentioned, depending on the knock on effects, we may decide not to accept that feature back into the main repository.
An alternative, which may be easier, is to create a custom msbuild step that does the copying of the files for you. You can then package that up as a nuget, take a dependency on the Octopack nuget and pull that package into any new project.