Have a scenario where I need to deploy the same package multiple times **on the same set of servers** under different custom directories and different IIS web applications. There are role scoped variables which get picked up for custom installation directory and also appsettings.

I understand that the documentation under https://octopus.com/docs/key-concepts/machine-roles clearly states:

"This means that the step will only execute on Tentacles with at least one of those roles. This does not mean that if the step is scoped to multiple roles that it will run for each role. Instead it will run that step for all machines that have any roles that match any of the step roles."

This would be fine if target machines have only one of the roles which are assigned to the same step. The only way to get this working the way I want it is by cloning the steps and assigning one role per cloned step. As you can imagine, it can get rather long.

Would be great to have octopus loop the same step if it finds that multiple of its roles are assigned to a same target machine AND role scoped variables are defined.

I cannot not use /p:OctoPackEnforceAddingFiles=True with MSBuild. This parameter is absolutely indispensable. It is not even an option.

However I do not want all the files in the build to be included in the package.

The nuspec file and the exclusions ability therein does not allow to exclude files that were added by OctoPackEnforceAddingFiles.

The effect of this is that I can’t use one of the best features of Octo : deploying to IIS.

Because of a few files that I can’t exclude from the build, I need to deploy to a folder, remove the files that I want, and then copy that modified folder to the folder that the IIS site is pointing to.

I completely lose the ability to have IIS setup of a site safely in a system, backed up , effectively documented as it is the single source of everything – all because there is a file in a nupkg that I can’t get rid of.

Please consider allowing an option to remove specific files that OctoPackEnforceAddingFiles added. Even if this is in the nuspec file. This is incredibly important.

I love the Let's Encrypt integration with the OD server. Setting up SSL for the server is so simple, and I don't even have to worry about renewals as this is taken care of for me.

Now imagine this same functionality for all of your IIS sites.

This is how I envision it could work

- I go to Library > Certificates > Add certificate
- I'm given the option of importing a cert (i.e. the current functionality), or I can chose to use Let's Encrypt
- After picking Let's Encrypt, I'm prompted for a bit of info- domain, email address, verification process (see below), and do I accept the TOS?
- This would then allow OD to create the cert
- Now, I go to my Project's process tab, edit the IIS deployment step, and scroll to the Bindings section. From there, if I bind on HTTPS, I'd be able to pick one of my Let's Encrypt certs from a select list.

That's it- OD will automagically renew the certs for me once they get close to expiring.

Notes on verification process: OD could automatically handle the HTTP challenge, or it could allow users to pick DNS challenge. There's a step in the library that you could take inspiration from: http://library.octopusdeploy.com/step-templates/bc81b8a6-dc56-4769-87b5-650af7a38162/actiontemplate-lets-encrypt-create-ssl-certificate

As of version 3.7.12 it is possible to use the "Transfer package" step and use the selected package on custom steps (e.g. push it to an s3 bucket).

However, when it comes to docker "packages" the only way to select a docker feed is by using one of the 3 default docker steps.

It would be nice to have a basic step which would allow us to select only the docker feed and have that step export the image+version (tag) to other steps.

In my case, this would allow me control the deployment of a specific image using custom templates (e.g. updating an AWS ECS service).

The ReleaseEdit Role permits for updating the release variables, but it also allows for editing the release version, the deployment package that it deploys, and the Release Notes.

The ability to update the release variables should be a separate role, say: ReleaseUpdateVariables, from editing the release version and package versions.

ReleaseEdit should cover updating the release version, and the deployment package version it deploys.

I'd also suggest adding third role for updating the release notes: ReleaseupdateNotes for appending to (but not otherwise modifying) the release notes.

The idea is that different user should be able to be responsible for updating the release variables, the release notes, and its version/deployment package version.

Updating the release variables can happen often as a part of a release, updating or appending to the release note could occur even more often (as dependencies are relieved for example), while updating the release version or its deployment package should almost never happen, perhaps only in the most grave of emergencies.