chore(CI): automatically create and assign Milestones

[marstamm]

Proposed Changes

This PR introduces 2 new actions. I tested these in a private repo to verify they work

ASSIGN_MILESTONE.yml

• Runs for every closed Issue/PR
• Gets the Milestone starting with "M"
• Assigns the PR/issue to the Milestone, if it does not have one assigned manually

RELEASE_ISSUE.yml > createMilestone

• Closes Milestone attached to Release issue
• Creates a new milestone with increased version number (Schema M<number>)
• Assigns new milestone to created release issue

closes #4311

Checklist

To ensure you provided everything we need to look at your PR:

• Brief textual description of the changes present
• Visual demo attached
• Steps to try out present, i.e. using the @bpmn-io/sr tool
• Related issue linked via Closes {LINK_TO_ISSUE} or Related to {LINK_TO_ISSUE}

[barmac]

Shouldn't this be enclosed in ${{ }}?

[marstamm]

For if clauses, using the expression syntax is optional (cf. https://docs.github.com/en/actions/learn-github-actions/expressions).
We can use the syntax for consistency. I think it looks cleaner without it, especially for multi-line conditions

[barmac]

Let's try this out!

[marstamm]

🤞

[barmac]

We are now in the code freeze, and the release will happen only next week. Will the script assign the current milestone to the issues closed in the meantime? I assume so, but we'd rather not assign the current milestone to the issues that will be released only with the next release.

[marstamm]

The new Milestone will only be created when the Release issue is closed. I am fine with changing the procedure to close the issue once main tasks are done and only the release presentation is still to be done.

I would assume not many issues will be closed in that time (in the modeler)

[nikku]

So eager to try this in practice 🏃

[nikku]

#4400 (comment)

Do we/did we address this? We'll otherwise risk a bunch of false positives, working on issues for the next iteration. What we could do instead of reacting on close is to react on a checkbox being checked in the release list, opening a new milestone already while the old one is still open.

* [ ] Merge `dev` to `main`

⬆️ Once checked, already create a new milestone (because DEV is essentially unfrozen at this point).

[marstamm]

react on a checkbox being checked in the release list

That feels rather hacky and could break due to many things, like renaming of branches, manual changes to the template, etc. I also feel like Checking of something in the list having side-effects is unexpected magic.

Alternatively, I would rather keep milestone closing a manual step and only automate creating + assigning the new milestones.

[nikku]

So then let's close the milestone eagerly, manually, once all (main) release activities concluded? That would work for me as well. I just want to prevent that issues are moved unnoticed into a wrong milestone.

[marstamm]

I'll create a follow-up PR

[barmac]

Regarding magic of checkbox, this is already how it works with renovate rebase, e.g. #4387

[marstamm]

For renovate, it is clear what the expectation is, and is it the only interactable element in the issue body. The checkbox also feels like a workaround and is used instead of a button.

For the release issue, we have 10s of checkboxes that do nothing, IMO it feels weird that one should be magic.