A naive solution to enforce Milestone for every pull request would be to
fail Github CI if no milestone is set for that.
----
on:
pull_request:
branches:
- main
types: [synchronize, opened, reopened, milestoned, demilestoned]
jobs:
check-milestone:
name: Check Milestone
runs-on: ubuntu-latest
steps:
- if: github.event.pull_request.milestone == null
run: exit 1
----
But adding this simple CI job to the central repo may introduce a large
amount of noise (it is not exactly a "CI").
A more sophisticated method could be to use Octokit Request Action to
gently remind maintainers to set a Milestone before closing the issue/pr,
though, I've never tried it.
https://github.com/MeilCli/actions/blob/master/.github/workflows/check-has-milestone.yml
2023年5月11日(木) 22:45 Michael McCandless <luc...@mikemccandless.com>:
> Hi Team,
>
> [spinoff from this java-user thread:
> https://markmail.org/thread/mmx22s7lysxqh6wm]
>
> In the good old Jira days, when we resolved an issue, the workflow
> encouraged us to also mark the Fix Version that this fix will be released
> in.
>
> This metadata is very helpful to future users wanting to know which Lucene
> version has the fix.
>
> GitHub issues/PRs have the Milestone tag instead, but the workflow doesn't
> encourage us to record it, from what I can see. Looking at our recently
> closed issues (
> https://github.com/apache/lucene/issues?q=is%3Aissue+is%3Aclosed) I can
> see some are tagged with a Milestone, but most are not.
>
> I am furthest from a GitHub expert! So maybe I'm just missing something
> obvious? E.g. is it possible via a commit message to "Closes #XXX in
> Milestone YYY"? Do we just have to rely on "best effort" to remember to
> set a Milestone on an issue when we close it?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
