I’m not quite sure what we are missing ? Other than the fact this is a Web App deploy rather than a deploy to an IaaS VM it does not seem massively different/complex ?
It looks like you’ve setup everything correctly. Azure Web App targets behave just like regular targets and should be scoped in during your deployment as you expect.
Could you please confirm what version of Octopus you’re running?
We noticed those PayoutApiTroxy targets are scoped to environments, which I understand has been blurred for privacy reasons. But could you please confirm that the environment you’re deploying to matches one of the environment scopings for your targets?
We can’t see any sort of typo happening with the role between the target and the step, so the environment scopings is the only thing that stands out as a potential candidate.
If you take off the environment scope from one of those targets (I.e. the integration target) and re-run your deployment, does the target then get included?
In terms of it not failing the deployment, could you confirm if your project Deployment Target settings are set to “Deployments with no targets are not allowed”?
To help us get a closer look at your roles, we’ll need to take a look at your raw task log for that deployment, and it would also help if we could see your database tables so we can confirm the role and environment scopings.
We’ve created a private upload location here. Could you please let us know when you’ve uploaded your raw task log and database (.bak) file? This will only be viewed by Octopus staff and deleted immediately after we’ve finished reviewing.
I would point out the backend DB is an Azure PaaS SQL SB, so there will be some extra “bits” in there that we have no control over (we see this on the ‘Diagnostics’ area of Octopus)
You were completely correct about the “Deployments with no targets are not allowed” * setting. I have changed this and the deployment now fails (well, it refuses
to start) owing to not finding am enabled healthy machine in the environment*
There’s a leading space at the start of the PayoutApiProxy role, which is causing the issue.
To fix this, you’ll need to delete that role from your targets, re-add it without any leading or trailing white-space, and save. You’ll then need to review any project steps that are using the old role, clear the role, then re-select the newly-added role. This should then unblock you.
This is definitely a bug and is something we will fix so that white-space will be trimmed properly. We have created a GitHub issue here that you can track to be notified when a fix is available, so this won’t accidentally occur in the future.
