search

emgarten / Sleet

A static nuget feed generator for Azure Storage, AWS S3, and more.
MIT License
362 stars 43 forks source link

Add option to retain N pre-release packages per label #129

Closed kzu closed 3 years ago

kzu commented 4 years ago

Hi @emgarten, I love the retention feature!

I have a particular version scheme I use in some repos, where I push packages from all branches and PRs with a naming like 42.42.42-[branch].[commits]. In case of a PR, the [branch] becomes pr[number]. This means that it's quite common to have several like:

Since the versions are fixed (I only version "properly" when labeling/creating a GH release, in this case), pretty much everything are prerelease versions. So I'd need a little more granularity on the retention rule for that.

What I'd like to have is a X prerelease versions per label, where choosing (say) 5, will keep 5 versions from all prerelease labels.

I know this is a tricky approach because semver2-wise, there can be arbitrary labels "parts" (i.e. -features-area-foo.25).

Thoughts?

PS: I'm evaluating using the patch part to hold the PR number for that particular scenario, but that would still not fix the scenario since lots of PRs could still cause the -main (or feature branches) packages to be pruned.

emgarten commented 4 years ago

Would it work to set a rule to keep 5 packages per first semver release label? Or potentially, the first X semver release labels (ex: 2 -> 1.0.0-first.second.XXX.YYY.ZZZZ)

That way each prXXX would get it's own limit without knowing the name ahead of time, or putting all pr* together if it were a regex.

I'm evaluating using the patch part to hold the PR number for that particular scenario

What do you mean? Using x.y.Z going by Z instead of the release label?

Glad to hear retention is useful for you. I kept it simple at first with the intention of expanding it for scenarios like this once I got more feedback on it. I think going by release labels for branches/PRs sounds like a great feature.

kzu commented 4 years ago

Yeah, having the limit apply within first label would suffice :).

Yeah, I was going to try to workaround this by setting Z as the patch instead of appending to the label, but much better to have per-(first) label retention 💯