-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
An empty release (no issues) should lead to a draft instead of a release error - configurable #495
Comments
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. |
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 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. Relevant repo - a custom Raspberry Pi image for deploying my project: |
How about a configuration setting that would allow developers to specify if they want to allow milestones without issues.
I'll submit a PR with this new Boolean setting. |
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
The text was updated successfully, but these errors were encountered: