An empty release (no issues) should lead to a draft instead of a release error - configurable

[davidzwa]

Detailed Description

I currently experience trouble releasing releases that carry no issues. In my PoV GRM should not decide that this is not allowed. The same holds for non-existing milestones.

Context

In my opinion GRM should simply be a passthrough for existing Github actions that create a release (f.e. the archived action https://github.com/actions/create-release/releases). If things are not according to what GRM was designed for (no issues, only excluded issues, no milestone), it would be lovely if the tool could still create the release but in draft mode.

My scenario: I have expensive 1 hour builds that fail due to misconfigured github labels. I tried to mitigate a lot, but I've come to the conclusion that without the strictness on GRM's end I would not have to wait for long builds/releases to complete to be presented with a release creation error. (This is not a rant, purely describing my situation)

Possible Implementation

We could simply toggle createDraftNoIssues, ignoreNoIssues ignoreNoMilestone. We could also add a warning text to the release body "No issues were closed for milestone/release x.y.z".
Alternatively we could easily add mutually exclusive configuration options that allow users to choose.

Your Environment

• Version Used:
• Edition Used: .NET Core (Github Actions, git-actions dist)
• Operating System and version: Ubuntu 20.04

[gep13]

Hmm, this is an interesting idea. When we first started GitReleaseManager it was intended as a very opinionated tool which would fail if the repository wasn't in the "correct" state in order for release generation to happen.

Looking back, I can see that it might be been setup to be too aggressive. I don't think I would be against the idea of relaxing these restrictions through configuration options though.

I am curious though... if you are not at a release point, i.e. there aren't any closed issues, why are you running GitReleaseManager? For example, when I am ready to run it, I normally use something like the application of a tag to trigger the execution. Curious what you workflow looks like.

[davidzwa]

Hmm, this is an interesting idea. When we first started GitReleaseManager it was intended as a very opinionated tool which would fail if the repository wasn't in the "correct" state in order for release generation to happen.

Looking back, I can see that it might be been setup to be too aggressive. I don't think I would be against the idea of relaxing these restrictions through configuration options though.

Im glad to hear that. I propose to make the default very tolerant or respecting the user's mistakes or learning curve, and making 'fail fast mode' to be configurable if they so desire. I do see the point for some scenarios.

I am curious though... if you are not at a release point, i.e. there aren't any closed issues, why are you running GitReleaseManager? For example, when I am ready to run it, I normally use something like the application of a tag to trigger the execution. Curious what you workflow looks like.

I agree that sometimes 'fail fast' is better than 'fail silently'. In this case my workflow is different: my releases contain so little change that an issue is not justified. You could call it lazy as well, but in some cases I want to automate it.
In my case the releases are automated or nightlies which have no issues attached and the content of the release is a big payload that needs to be attached to a release (otherwise the users cannot easily download it).

Relevant repo - a custom Raspberry Pi image for deploying my project:
https://github.com/fdm-monster/MonsterPi
Currently I'm manually adding the attachments to a release.

[Jericho]

How about a configuration setting that would allow developers to specify if they want to allow milestones without issues.

• When this setting is set to false (which would be the default value), the current behavior is preserved. Meaning: we throw a InvalidOperationException when we detect that the milestone is not associated with any issues.
• When this setting is true and the milestone does not have any associated issues, the release is created.

I'll submit a PR with this new Boolean setting.

[gep13]

@Jericho I think this is a good start, and adding the configuration option to allow the creation of an empty release makes sense.

When I had originally thought about this issue, I had envisioned a new empty release template, which would give the user the option to control the contents of the empty release wording. The default, would be something along the lines of:

This release had no issues associated with it

What are your thoughts on this?

[Jericho]

Sure no problem. One quick note though:

The current GRM logic determines which template will be used BEFORE any data is fetched from GitHub/GitLab which means that we don't know whether there are any issues associated with the milestone. This logic is in VcsService.CreateReleaseFromMilestoneAsync. The data is fetched in ReleaseNotesBuilder.BuildReleaseNotesAsync.

All this to say that, in order to implement your suggestion, I will have to move the "template choosing" logic from VcsService.CreateReleaseFromMilestoneAsync to ReleaseNotesBuilder.BuildReleaseNotesAsync.

[gep13]

@Jericho said...
All this to say that, in order to implement your suggestion, I will have to move the "template choosing" logic from VcsService.CreateReleaseFromMilestoneAsync to ReleaseNotesBuilder.BuildReleaseNotesAsync.

I don't think I have any objections to this happening. Will review the PR when I have some time.