Settings and activity
5 results found
-
215 votes
An error occurred while saving the comment -
68 votes
casterlight
supported this idea
·
An error occurred while saving the comment casterlight
commented
I hear ya Erik. Utilize your variable snapshots within the release to lay them back down or retrieve the old one but this sounds like the way we always have done it.
Sensitive variables. I have had to re-deploy a previous release with the old variable value un-encrypted then jump on the box to get the plain text value then run my encryption again.
Variables in my opinion are what make Octopus truly great. I just went from 2018.5.1 to 2019.10 LTS. All that time and not much change in the variables was made. I think what Adam is asking for is AWESOME. Take some time and improve your core functionality. Variables needs an overhaul and leverage some of those features from within the variables screen and not outside of it with audits, or snapshots.
-
55 votes
An error occurred while saving the comment casterlight
commented
Meh, crank your task cap up on your node. I'm willing to bet your server can handle it. Leverage workers and add more tentacles to your boxes and scope your roles accordingly and you shouldn't have this issue.
-
1 votecasterlight
shared this idea
·
-
366 votescasterlight
supported this idea
·
A band-aid i would recommend trying for people who have these kinds of steps that routinely fail is to just clone the step and on the clone just update the Run Condition to "Failure:only run when a previous step failed"
Furthermore if you have other steps that may fail beyond the one you know works with a retry just leverage the output variable run condition "Variable: only run when the variable expression is true" This is probably the cleanest way to gauge this but is more advanced for some. You can add a custom script with some powershell to define a true or false value.