When we deploy a website we need to grant the user running the IIS application pool access to the deployment directory. Similarly, when deploying a windows service, we need to grant the user running the service filesystem permissions to the deployment directory.

It would be great to add a Feature to "Deploy to IIS" and "Deploy to a Windows Service" that would set the file system permissions for the user associated with the App Pool or Windows Service.

We like to set file system permissions during deployments so we have one less environment-specific issue to worry about (ex: oops, the user running the service in the test environment had file system permissions but the one in production did not causing the application to fail in production).

This issue is particularly important with the "Deploy to a Windows Service". The service will not start until the file system permissions are granted for the user running the service. So we have to use 4 steps instead of 1:
1. Deploy a Windows Service (startup set to manual)
2. Grant file system permissions (using a community step template)
3. Set the Windows Service Startup Type to automatic (using a community step template)
4. Start the Windows Service (using a community step template)

This is a lot of complexity for deploying a windows service and it would be much better if the "Deploy a Windows Service" process worked in this order:
1. Deploy the package & extract
2. Grant file system permissions on the installation directory
3. Install & start the windows service

It would be great if Ocotpus could support as an external package feed:

https://inedo.com/support/documentation/upack/tools-and-libraries/upack-cli

This is because using `upack` cross platform cli it is easy to create and publish packages containing applications, to a proget universal format feed. Octopus has an in built zip file feed, but we want to standardise our artifacts feeds to proget as it is purpose built for feed management.

Nuget cli is not good at packaging up for example a single exe to push somewhere - like an apk file - because you first have to generae a nuspec file, and then you have to update that file, and then pack it - this is too much overhead for something that should be trivial, like the zip mechanism.

As of Octopus 2018.2.3, I'm experiencing a limitation for defining variables per tenant and environment.

The current ability to define variable templates per project is nice (so we can change the value per environment as the project is deployed to those environments). However, it would be nice to have the ability to define a common variable template that is shared across all projects in the deployment per tenant, but can change per environment.

I understand this can easily be done via variable sets, but it would be nice to be able to define everything in one place--not simply dividing configured values between templates and variable sets.

Hi,

The overview page seems to show a variable amount of releases. On one project it is showing 4, where only the oldest and newest deployments were pushed to prod. On another project it is only showing 3, again where the oldest and newest were to production.

Could we simplify this and just have it show a paginated list of all the releases? You could then use the filters to filter the rows down (rather than columns as it does now, which isn't a filter if we're honest!).

By doing this it will make this screen much more usable in terms of getting a quick overview of what went out where and when. Releases page doesn't help because I have to drill into each and every release to see where it went.

Thanks

I would like to create a step template to run some Postman test suite. For this I thought to pass the test files and environment files to the package. Extract the package somewhere, run powershell in the extracted package and call newman (command line runner for postman).

But I can't add a 'Package variable' to a step template (like for a deployment step.

It would be nice to have this as variable for a step template. In the process, you would then get a dropdown with the available packages, and a dropdown with the possible packagefeeds. The script would then automatically extract the package on the selected deployment target(s), and run powershell inside the context of that package.
This way I could specify relative paths to the files needed as input for the script.

We have dev and prod instances of Octopus Deploy. I’ve created a deployment project on the dev and then we needed to copy it to prod. We didn’t find Export/Import buttons in project UI. My colleague opened https://octopus.com/docs/api-and-integration/octo.exe-command-line/export page and told, that it’s too complicated and it will be easier to manually duplicate all steps on the prod Octopus Deploy.

Could you please add to project Octopus UI Export/Import buttons , that will provide same behaviour as octo.exe CLI. It’s ok to implement just the simplest scenario with default parameters and have a note “if you need more control, use octo.exe export“

Similar requests in the past
https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6677232-allow-option-to-export-import-project-steps-only
https://help.octopus.com/t/export-import-octopus-project-between-different-octopus-deploy-servers/3550
https://help.octopus.com/t/copying-a-project-between-two-octopus-servers/7453/5