the feature Composite Step Templates has started which should meet most of these requirements. The underlying templates will still be linked so that they can be updated as per normal step templates.
This would be great. The TeamCity model works well, with the ability to use a Process template. but then in the Process using the template, you can disable Steps or insert extra Steps (before/after/between any template Steps).
It would be great to combine this with timeouts for Steps. So if an idempotent Step gets stuck, it can eventually timeout and retry. Currently your Step can wedge for _days_. And you can only cancel the whole Task, not the Step.
Aggravated by this again. The required unnecessary menu and embedded advertising seems like a decision made for marketing purposes rather than for the benefit of users.
As well as the useless top-left menu, having access to a single spaces also causes the 'Configuration' menu item to appear for every user, even though there is nothing they can configure. There is a single section 'Spaces' with a single entry for their one Space.
Upgraded to 2019.x and immediately hit this. It's basically a great big ad in the middle of the application.
Users with access to only one space should not have to put up with the ad or have the prime top-left location wasted on something they have no use for.
Related to this I've suggested adding SemVer 2.0.0 support for build information to Channel Version Rules.
This would enable you to match the Channel experimental builds (built with extra debug stuff included) using the build information rather than using version numbers ranges as a proxy for the build metadata.
Until we implement this feature, the work around would be to monitor the deployment using the API and cancel it if a timeout has been reached.
I have written up a script (https://octopus.com/blog/automating-octopus-with-azure-functions) that retrieves all running deployments for a project and cancels it if:
- it has been running for more that 30 minutes
- the first step has been running fro more than 20 minutes
- the first step has not output any logs in 5 minutes
This can run as a scheduled task. Alternatively you can use the subscriptions feature to kick off a piece of code (eg Azure function) that does this polling, as described in this blog post: https://octopus.com/blog/automating-octopus-with-azure-functions
— Robert W
This forum issue also has Octopus suggesting you run your own scheduler and script outside of Octopus to polyfill for the lack of timeout functionality.
Unfortunately all these work-arounds cancel the whole Task, not just the Step. So there is no opportunity to run on-fail/recovery/clean-up/notify Steps later in the Task. So there is really no solution or complete workaround to achieve Step Timeouts still.
Found it. I know it was somewhere obscure. It is tucked under the Acceptable User Policy:
"Storage for artifacts, task logs, packages and package cache is limited to 50 GiB."
It is worth reading thw AUP actually. There is not way to backup or migrate from Octopus Deploy Cloud right now, so when the policy says "we reserve the right to suspend or terminate your access to our services without any prior warning or notice." That makes it quite a business risk to adopt the Cloud product.
Hi @Bryan I couldn't find documentation either but I did find the info somewhere unexpected - I forget where now sorry - and it said the ODC package storage limit was 50GB. There was no mention of any option to extend that. It would be nice to know how close to the limit we are.
Why does git support need to be per-proprietary service and not just support any git repo?