Is there anyway for a user to be able to choose package version when running a runbook without having edit rights on the runbook (which is something that we don´t want the generel people to have)?
Hey @p_liljecrantz , thanks for reaching out!
Can you tell me a little more about your use case? Runbooks are intended to be created with a snapshot that locks the package version along with the remainder of the process, similar to release snapshots. What sort of runbook task are you executing that needs different packages?
Hey! Sorry for the late reply.
The problem we have is that if a team updates the code in the repo that the runbook uses, the published version of the runbook still uses the old package even if the new code is built, packaged and deployed to Octopus Deploy, meaning that we need to publish the runbook again with the latest code before the team can run the runbook with the latest code. OR give edit access to the team so that the can choose to run a non-published version of the runbook and then choose the latest package themselves. We don´t want to give that type of access right to everyone as they can change the runbook at will and change it to do whatever in production without anyone reviewing and they might not be following our standards which will make troubleshooting harder if everyone does things without considering any standards.
This is why it would be great if it was possible to choose the package version when running the runbook without edit rights.
BR, Petra
Thanks Petra, the additional context you provided was very helpful!
There are a couple of pieces here I want to talk about independently that might help you out here -
Firstly, you mentioned runbook snapshots when the runbook uses external code that may also need to be updated. One of the most common solutions here is actually using another runbook! We have a sample API script here that works to update runbook snapshots to reference the latest packages. You could set this script in a separate runbook that runs on a set schedule to update the packages for these runbooks in particular.
The second part is around runbook permissions in general and needing to be cautious - it may be worth looking into fine tuning your runbook permissions. For instance, you can give a user the RunbookConsumer role, then scope that role to non-production environments. That would allow your users to run those runbooks (and make edits as needed), but only in “safe” environments. Generally speaking, the first approach is more automated and less maintenance around permission wrangling, but both may be useful for different reasons.
Let me know if either of those can help you get to the outcome you’re striving for - if you have more questions or concerns, I’m happy to help continue looking!