Currently, once a release is completed, it is locked and no further changes can be made. In our team, we frequently run dry runs or test executions from tagged templates for POC or feature development purposes. As a result, these non-production runs are included in release metrics and visualisations, which can skew dashboard insights.
It would be beneficial to allow users with appropriate permissions to add or remove tags after a release has completed, mainly for housekeeping and to ensure more accurate reporting.
by: YINFENG X. | 4 months ago | Templates & Releases
Comments
Thank you for the suggestion. To better understand the use case, we have a few questions:
1/ When you run a dry-run or test execution, is there a reason the release cannot be tagged before it starts, or does the need to add a tag come up only after the run completes?
2/ How are you using reporting today where these releases cause issues? For example, are you filtering or excluding releases by tag in the Release dashboards, or exporting data for use in an external tool?
3/ Do you need to keep these dry-run releases in the system after they complete, or would deleting them after review be an option?
4/ How often does this happen - is it occasional testing or a regular part of your team's workflow?
Thanks for the questions.
1. For templates managed by our team, we do try to apply the correct tags before creating releases. However, there are also POC and development templates created by other teams that we don't control, so tags are not always managed consistently.
2. We primarily use the reporting and dashboards within Release. As far as I'm aware, there is currently no way to exclude releases based on tags in those dashboards (please correct me if I've missed this capability).
3. These releases are typically only needed during development or experimentation and could be archived or deleted once they have served their purpose.
4. This is a regular part of the template development lifecycle. Users often clone existing production templates to develop or test new functionality, which also copies the production tags. The resulting dry-run releases then appear alongside genuine production executions in dashboards and metrics, which can make reporting less accurate. Allowing tags to be adjusted after completion would provide a simple way to keep historical reporting clean and accurate.