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 https://github.com/camunda/camunda-modeler/issues/4311

Checklist

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

• [x] 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}

[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 :runner:

[nikku]

https://github.com/camunda/camunda-modeler/pull/4400#issuecomment-2188822689

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`

:arrow_up: 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. https://github.com/camunda/camunda-modeler/pull/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.