ProGet Release Retention Policies + API Delete

[mness_8576]

I was looking for settings to be able to set up retention policies for releases in Reporting & SCA for ProGet 2023.6 without BuildMaster, and I didn't come across anything in Administration or find any documentation around that. I was planning to fall back on writing a tool for this myself, but SCA Projects & Releases API documentation doesn't appear to include an endpoint for deleting releases. If you would please let me know

1. whether it's possible to configure retention policies for ProGet Reporting & SCA releases at this time without using BuildMaster and where to find that setting if it is and
2. whether there's an API that I might have missed that would allow me to automate retention myself by writing tooling to delete ProGet releases as they become stale (maybe an update action that sets the active flag to false is equivalent to a delete?)

I'd appreciate it. Thanks!

[atripp]

Hi @mness_8576 ,

For now, archiving is the way to do it. Looking at the code too, it doesn't look like there's even an API to do it...

Here is the code that BuildMaster uses, which clearly just sets the archive flag:

    /// <summary>
    /// Creates or updates the specified release with the specified data
    /// </summary>
    public async Task EnsureRelease(string projectName, string releaseNumber, string? releaseUrl, bool? active, CancellationToken cancellationToken = default)
    {
        using var response = await this.http.PostAsJsonAsync(
            "api/sca/releases",
            new
            {
                project = projectName,
                version = releaseNumber,
                url = releaseUrl,
                active
            },
            cancellationToken
        ).ConfigureAwait(false);

        response.EnsureSuccessStatusCode();
    }

Otherwise, we don't have automated deletion or retention policies for archived SCA releases; they don't take up much space (relatively speaking), and we didn't want to commit to retention rules so early on in the feature.

If they become a problem (UI, performance, etc.), it's easy enough to delete a bunch via SQL for the time being... and that'll help us learn how to create policies. And we can add to API and all that :)

Cheers,
Alana

[mness_8576]

Thanks @atripp, I appreciate the help! We're more concerned about reducing UI clutter than about space usage in this case, in particular because we're pushing data about pre-release builds in addition to production so we can catch issues ahead of releases but we don't need pre-release data to stick around. I'll keep in mind that SQL is another option for removing these and reclaiming space, though personally I'd prefer to stick with the API approach unless space becomes an issue.

[atripp]

@mness_8576 thanks! We definitely welcome feedback on the UI/UX - this is a new feature, so there's a lot of room to improve :)