Cleanup of crate-universe tags

[dfreese]

The number of crate-universe tags and releases is quickly going to start getting messy. We'll need a story for how those are cleaned up.

[UebelAndre]

I think this is going to require some resolution on #680.

[dfreese]

The discussions there and limiting the number of cargo_universe-* tags largely seem orthogonal from my perspective. Is there a specific question that you would need to see addressed?

[illicitonion]

Just to understand the motivation here - is the concern general messiness and noise, or are there specific problems this is causing beyond that?

From my perspective the most annoying thing seems to be that draft releases show up above actual releases on https://github.com/bazelbuild/rules_rust/releases (I'm not sure how much that page is used, given our lack of current releases, but as we start doing actual releases that will definitely be a major annoyance).

[UebelAndre]

If we start doing real releases then we could likely stop doing these tag releases. The discussion in that thread, to my understanding, is trying to figure out what to do about the binaries and until we come up with a better solution I think the crate_universe-* pre-releases should stick around. Though, because they are pre-releases, they can be deleted. So already there's a path in place to clean them up.

[dfreese]

No specific problems, just that I have the expectation that tags/releases tend to be significant and distinct from commits, however if there's a lot of work in cargo_universe, then the correlation becomes less distinct.

It seems like only the last N need to be kept around, as an example. I don't think setting the expectation that these will continue to stick around is a good one, and doesn't feel like good stewardship of the repository to leave tags up if they aren't needed.

[UebelAndre]

It seems like only the last N need to be kept around, as an example. I don't think setting the expectation that these will continue to stick around is a good one, and doesn't feel like good stewardship of the repository to leave tags up if they aren't needed.

When this becomes more matured I'd want to guarantee that any version of the resolver that we release stays around. I do totally agree with your sentiments though. I'm just not sure what options we have. I'd be happy doing regular releases and only releasing new binaries with releases of the rules.

[dfreese]

Another alternative could be nightlies for the last week plus a -latest. Given that it is considered experimental, I do think there are some options for removing old binaries and tags. Are there any options that you'd consider acceptable?

[illicitonion]

Short term

I don't think anyone actually needs these tags, right? They're just an accidental side effect which is required in order to create a GitHub release, which is an accidental side-effect of needing somewhere to store some binaries. I just tried deleting a tag (crate_universe-2) and it deleted the associated release, so deleting the tags is destructive.

I think "Keep at most N tags" where N is any single-digit number would be reasonable. We could perhaps have the publish GitHub action prune before pushing a new one, or a cron GitHub Action clean up old ones.

Adding "-prerelease" or "-nightly" or similar to the tag name would also make sense.

Long term

When we have releases, I think we should probably only publish binaries for actual releases, which will make this problem completely go away.

[UebelAndre]

Are there any options that you'd consider acceptable?

I don't think cleaning up/deleting binaries is an appropriate thing to do long term. Again, we can delete these pre-releases but I think they're fine for the time being until we have something better in place. My gut reaction is to only publish binaries for full releases of the rules and I'd expect those to never be deleted. How's that sound to you?

[UebelAndre]

When we have releases, I think we should probably only publish binaries for actual releases, which will make this problem completely go away.

Implementing some action to do pruning feels a bit like negative work. I've been spending all my free time on crate_universe but can stop to move releases forward if that's what we think will solve this issue.

[dfreese]

Happy to work on this, if we think that, short-term, at least, cleaning up old tags/releases would be acceptable. (Accidentally left this comment sitting after unassigning you, @UebelAndre, sorry! Intention was to say I'd do the work)

Longer-term, if there are binaries that are generate for a release, I'm fine with those staying there.

[UebelAndre]

😃 all good. I'm thrilled to hear you're helping out! Having thought about it more, I do think it'd be awesome to have cycling builds of crate_universe so users can immediately benefit from merged PRs until we publish a new release. Then all tags and releases from two releases prior get deleted? Or something to that effect (of release based cycling)? Either way, very excited 😀

[UebelAndre]

I think the tags can be cleaned up after #415 is closed and we've shipped a release.

[UebelAndre]

This is done now that release 0.1.0 is being created.