Closed gereon77 closed 6 years ago
Hi @gereon77 by reading in the documentation "Builds that are deployed as part of releases are also governed by the release retention policy." I always thought that if I do mark a release as to be retained indefinitely, it will automatically apply the same on the related builds.
Now that you raised this question, I checked the documentation again and I do read the following:
The build linked to a release has its own retention policy, which may be shorter than that of the release. If you want to retain the build for the same period as the release, set the Retain build checkbox for the appropriate environments. This overrides the retention policy for the build, and ensures that the artifacts are available if you need to redeploy that release.
This being said, I took a look in one of my releases and indeed there is an option on the release that will make it retain the artifacts:
Wouldn't this be sufficient without going to mark the associated builds with the retain indefinitely check?
It is not a difficult thing to implement, however I would like to make sure that is really a wise thing to do.
Well, to be honest I was aware of this flag and usually it's ticked by default. But what I don't like is the fact that the build is "kept forever" internally without this lock symbol in the builds list. So I guess it's also not exact the same technique. That's why I would prefer to do it with the real keep forever function because then the lock is visible and it's clear why the build isn't deleted by the retention policy. But of course it should be optional in the extension settings. :) Thank you so much.
Ok, sound good. I'll test some code in the upcoming days. Once ready, I'll poke you via this thread.
Hi again,
right now I showed my DevLead your extension and how it helped in our environment and there I saw that I was not right. The lock symbol is shown if a release holds a build artifact:
So due to this I think it is not necessary at all but probably nice to have...
Sorry for the inconvenience...
Best regards, Gereon
Ok, good one as I had no time to actually verify it. Considering that this is a built in option, I will not try to override that behavior with my task.
Thanks
Hi Mario,
your extension is great. But please provide an option to retain the associated artifacts also. I wrote a PowerShell script for TFS2015 which did the trick for me. Unfortunately it doesn't work on VSTS. But that's how it could work:
The trick was that $env:BUILD_BUILDID pointed to the associated artifact during Release phase also so this worked.
Thanks you very much in advance.