chore: [M3-10396] - Release Label Automation

[jaalah-akamai]

Description 📝

Adds a GitHub Action that automatically labels new PRs with their target release date based on our bi-weekly Tuesday release schedule.

How it works:

• Triggers when PRs are opened against develop AND not in draft mode
• Calculates next release date + 14-day cycles
• Skips code freeze periods
• Release candidate cutoff: PRs opened on Wednesday (6 days before release) get labeled for the next release cycle
• Adds label like release:2025-08-26

Why:
Makes it easy to see which release a PR will ship in without manual tracking.

Testing:
Starting on develop branch - can disable via Actions tab if issues arise.

Changes 🔄

• New release-labeling.yml file for github actions

Target release date 🗓️

N/A

[jaalah-akamai]

✅ See passing test: jaalah-akamai#12

I need to look into the failure in this repo 👀

May need more permissions

[jdamore-linode]

This is a really cool improvement! Thanks @jaalah-akamai!

[jdamore-linode]

✅ See passing test: jaalah-akamai#12

I need to look into the failure in this repo 👀

May need more permissions

This is a security feature of the pull_request event type where PRs from forks get a read only token regardless of the requested permissions :/

https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflows-in-forked-repositories

Iirc, GitHub's official workaround is to use the pull_request_target event type instead, but it has serious security implications -- the big warning paragraph in the docs goes into more detail (I caused a security incident using pull_request_target once.)

[jaalah-akamai]

Iirc, GitHub's official workaround is to use the pull_request_target event type instead, but it has serious security implications -- the big warning paragraph in the docs goes into more detail (I caused a security incident using pull_request_target once.)

Ok so I just read the docs, I think we should be "ok" in this instance since:

• we're no longer checking out the repository (thank you!)
• we're using cli commands to manage labels
• we're reading from context variables
• dates are done using shell commands

thoughts?

[jdamore-linode]

Iirc, GitHub's official workaround is to use the pull_request_target event type instead, but it has serious security implications -- the big warning paragraph in the docs goes into more detail (I caused a security incident using pull_request_target once.)

Ok so I just read the docs, I think we should be "ok" in this instance since:

• we're no longer checking out the repository (thank you!)
• we're using cli commands to manage labels
• we're reading from context variables
• dates are done using shell commands

thoughts?

That looks good to me!

[linode-gh-bot]

Cloud Manager UI test results

🔺 1 failing test on test run #10 ↗︎

❌ Failing	✅ Passing	↪️ Skipped	🕐 Duration
1 Failing	700 Passing	4 Skipped	138m 18s

Details

Failing Tests
	Spec	Test
❌	linode-storage.spec.ts	Cloud Manager Cypress Tests→linode storage tab » linode storage tab

Troubleshooting

Use this command to re-run the failing tests:

pnpm cy:run -s "cypress/e2e/core/linodes/linode-storage.spec.ts"

[mjac0bs]

I like the release:date label idea, though I've got some additional thoughts:

• Not sure that it will make any less work for the Fire Chief (they may now spend their time looking through this list of PRs, manually checking the description for the Target Release Date, and either removing the label or tracking down the PR author if the description says something different)
• I don't think there's a way to link to a persistent list of PRs with the label including a dynamic date. (is:open is:pr label:"release*" and is:open is:pr label:release* doesn't work for a partial label match. (See: https://github.com/orgs/community/discussions/15298) This would prevent us from linking to the list of PRs scheduled for the release in Slack in any automated reminder, though the Fire Chief could do it by hand.
  • Not sure what this comment means, though: https://github.com/orgs/community/discussions/15298#discussioncomment-12010501
• Looks like we went this route because it is a security concern to parse the PR description, so date calculations are our only option.

Questions:

• We're going to end up with ~25 additional labels a year, one per release. Are we going to manually clean up the labels?
• Should we keep the current "Urgent" label around, or delete it? (What would its expected use cases be?)

Other Notes:

• Code-freeze dates are going to change year-to-year. If this label automation works well for us, then we may need a Slack reminder to update this script annually.
• We will need to update the automated Slack message based on this new process (at least updating the mention of the Urgent label).
• Once this is merged, we should probably let contributors know in the collaboration channels or overall channel, too.

[jaalah-akamai]

• I don't think there's a way to link to a persistent list of PRs with the label including a dynamic date. (is:open is:pr label:"release*" and is:open is:pr label:release* doesn't work for a partial label match. (See: https://github.com/orgs/community/discussions/15298) This would prevent us from linking to the list of PRs scheduled for the release in Slack in any automated reminder, though the Fire Chief could do it by hand.

Two options that we can automatically apply:

1. Option 1, we add two labels:
   • For Next Release (already have)
   • release:<date>
2. Option 2, we just use static label:
   • For Next Release (already have)

We would still need to handle stale release labels in two scenarios:

• Stale labels on merged/closed PRs: PRs that were excluded from a release but still have the old release label because it wasn't manually removed.
• Existing open PRs: These PRs would keep their old release labels since the action only runs when PRs are opened, so users would need to manually remove the old label and add the new one.

Maybe we can address these later?

• We're going to end up with ~25 additional labels a year, one per release. Are we going to manually clean up the labels?

I thought about deleting the labels, but then I thought it may be good for historical context.

• Should we keep the current "Urgent" label around, or delete it? (What would its expected use cases be?)

I don't see a need for it with the above approach

• Code-freeze dates are going to change year-to-year. If this label automation works well for us, then we may need a Slack reminder to update this script annually.

Freeze dates are github context variables that admins can update yearly. If we forget to update freeze dates, it still works as normal.

• We will need to update the automated Slack message based on this new process (at least updating the mention of the Urgent label). * Once this is merged, we should probably let contributors know in the collaboration channels or overall channel, too.

Agreed for both. 👍

[hana-akamai]

What about just using the For Next Release label instead of creating and maintaining new release date labels?

I thought about deleting the labels, but then I thought it may be good for historical context.

I think the github release page is good enough for historical context

[mjac0bs]

✅ Approving so we can give it a try and further refine as needed; still curious about others' thoughts though.

💭

We would still need to handle stale release labels in two scenarios:

Stale labels on merged/closed PRs: PRs that were excluded from a release but still have the old release label because it wasn't manually removed.
Existing open PRs: These PRs would keep their old release labels since the action only runs when PRs are opened, so users would need to manually remove the old label and add the new one.

Maybe we can address these later?

TLDR: It's going to be complicated and still somewhat manual no matter what, so my preference is Option 0 (what you have - one dynamic label with release date) after considering this more. FC would just need to manually link the list based on the current tag if we want to socialize that.

Because:

PRs that were excluded from a release but still have the old release label because it wasn't manually removed.

What about PRs that are included in a release and merged? If I'm remembering correctly, the main reason we went with "Urgent" over "For Next Release" in our current process is because tagging (almost) everything "For Next Release" as it's created would result in every PR we ever merge having a "For Next Release" label on it. I guess there's no reason we couldn't do that. The impact is visual clutter in the list of closed PRs (unless we also add automation to remove the "For Next Release" label for every PR that had it after the date the release goes out?).

Option 1 (2 labels) would help the fire chief distinguish between their release and the next release, but to get an accurate "For Next Release" list, the next FC will still have to go back and add "For Next Release" manually to PRs opened on the day of the (previous release's) branch cut. Maybe that's what you were getting at in "Existing open PRs".

I think the github release page is good enough for historical context

I agree with Hana. And we can click on any individual PR and see what release PR it went out in. That being said: I can't find anything documented about Github's limits on labels (I highly doubt we'd ever hit it), so cleaning them up would purely be for DX when trying to browse the list.

[jaalah-akamai]

Closing for time being