[Issue #2495] Set points and sprint on close

[widal001]

Summary

Adds new linter to set a default value for points and sprint if those fields are unset when an issue is closed.

Fixes #2495

Time to review: 5 mins

Changes proposed

What was added, updated, or removed in this PR.

• Adds linters/scripts/set-points-and-sprint.sh
• Adds associated queries:
  • linters/queries/getFieldMetadata.graqphql
  • linters/queries/getItemMetadata.graphql

Context for reviewers

Testing instructions, background context, more in-depth details of the implementation, and anything else you'd like to call out or ask reviewers. Explain how the changes were verified.

This action will trigger every time an issue is closed in the repo.

Questions

1. Do we only want to apply this to issues with a certain type (e.g. bug, task, etc.)
2. Should we post a comment to the ticket if these field values are set?
3. Are there other instances when this action shouldn't run (even if these fields are unset)?

TODO

• Update script to handle dry run mode
• Add CI test to ci-project-linters.yml
• Potentially update script based on questions above

Additional information

Screenshots, GIF demos, code examples or output to help show the changes working as expected.

Here's an example of this action from our sandbox repo

Screen.Recording.2024-10-18.at.9.31.55.AM.mov

Here's an example of a dry run within this repo:

[coilysiren]

@widal001

Do we only want to apply this to issues with a certain type (e.g. bug, task, etc.)

a) You can either include:

• Bug
• Task
• Enhancement
• Deliverable

b) Or exclude

• Epic

Option (a) sounds safer

Should we post a comment to the ticket if these field values are set?

Yes that sounds great! I love clarifying comments from bots

Are there other instances when this action shouldn't run (even if these fields are unset)?

If you can only include tick where { author is users in this repo with the permission level write access }, that would be ace. But we might get that for free? I dunno.

[widal001]

@coilysiren Thanks for the feedback above! I've implemented most of it in the following commits:

• ci: Updates set-points-and-sprint.sh
• ci: Adds set-points-and-sprint.sh to linter CI checks

With two notes:

a) You can either include:

Bug
Task
Enhancement
Deliverable

I'm also skipping deliverable because Deliverable is meant to be a parent to Epic, and shouldn't really ever live in a given sprint.

If you can only include tick where { author is users in this repo with the permission level write access }, that would be ace. But we might get that for free? I dunno.

This is a bit trickier to do, but helpful to note. Maybe we can revisit if we find a lot of issues being accidentally added because they were closed by open source contributors.

Examples of new behavior

Here's an example of skipping an update because an issue is an Epic:

And here's a sample comment Note: Unfortunately unless we switch to a different auth structure for GitHub actions, the automations tied to my PAT will continue to be shown as coming from me, hence the "beep boop".

[coilysiren]

Unfortunately unless we switch to a different auth structure for GitHub actions, the automations tied to my PAT will continue to be shown as coming from me

@widal001 we definitely have a ticket for this... but I can't find it!

[coilysiren]

Can you expand on what UNSET_ISSUE means here?

[widal001]

Great callout! Just added some comments in this commit: docs: Explains what UNSET_ISSUE is in ci-project-linters.yml

[coilysiren]

Looks good, just have a clarity comment

[coilysiren]

Excited for this!