GHA: Sort closed issues to correct column

[Aveline-art]

Overview

As a developer, we have to ensure that our kanban board is organized for all teams so that productivity is high. For this issue, we are creating a sorter that will move closed issues and PRs to the correct column by their labels when they are closed.

Psudo-code

• When an issue/PR is closed:
  • If the issue/PR contains a label from the hard label list:
    • Place the issue/PR in the column marked 'Done'.
  • Else if the issue/PR contains a label from the soft label list:
    • If the issue also contains a label from the soft label counter list:
      • Place the issue/PR in the column marked 'UAT'
    • Else:
      • Place the issue/PR in the column marked 'Done'.
  • Else:
    • Place the issue/PR in the column marked 'UAT'.
• Hard label list: any labels involving refactoring
• Soft label list: 'role: back end' label, 'Feature: Analytics'
• Soft label counter-list: 'role: front end'

Checks

• An issue containing only 'role: back end' and 'role: front end' labels closes -> UAT.
• An issue containing only 'role: front end' closes -> UAT.
• An issue containing only 'Feature: Refactor CSS', 'Feature: Refactor JS / Liquid', and 'P-Feature: Home page' -> Done.
• An issue containing no label -> UAT
• Make sure the labels are placed in the code in such a way that we can easily add, edit, or delete labels
• The columns id should ideally be a secret, so that they are not exposed. When the id is found, please consult an admin to add it to our secrets. Columns id can be retrieved as a link, from the columns settings menu, for example . Please retrieve the id from there.
• In the PR, request the reviewer to, after merging, test that the board automation does not intercept or supercede this GHA. If so, the team leads will need to remove the default automation to allow this one to work.

Note: The purpose of this issue is to sort closed issues into 2 categories. The "there are visual changes to the website"(C) and "no change"(NC) categories. Anything that is C needs to be in UAT, whereas anything that is NC belongs in Done. If any labels fit the NC category, feel free to tack it onto this issue, but be sure to justify it in your PR.

Resources/Instructions

Never done GitHub actions? Start here!

Note that you might want to do something outside the scope of the above psudo-code. If so, be sure to leave comments in your PR or this issue that justifies your reasoning. If you feel you need guidance, be sure to reach out! We cannot foresee whether this issue is solvable, or what hard decisions have to be made, but we would love to hear and help you!

Additional resources:

Events that trigger workflows
Workflow syntax for GitHub Actions
actions/github-script
GitHub RESTAPI
GitHub GraphQL
Encrypted secrets

[Aveline-art]

@ExperimentsInHonesty As per our discussion earlier today concerning automation on the UAT column, I want to make sure that we are creating automation that meets stakeholder demands, and would not conflict with the PM team's need. This current automation performs this task:

This automation

If a closed issue or pull request contains a label that indicates no changes to the website's appearance (for example, the "role:backend" or the "refactor:js" label), the issue goes straight to "Done" and "UAT" otherwise.

However, today you asked for a new automation that performs this task:

New proposed automation

If a closed issue's linked pull request contains github image links, send the issue to "UAT" and add the "visual changes" label. Otherwise, send the issue to "UAT" and add the "no visual changes" label.

These two automation when working together will create the following scenarios:

• an issue has no image links, and is not refactor: js -> go to UAT with "no visual changes" label
• an issue has image links and is not refactor: js-> go to UAT with "visual changes" label
• an issue has no image links, and is refactor: js-> go to Done with "no visual changes" label
• an issue has image links and is refactor: js-> go to ??? with "visual changes" label (realistically, would not happen)

Does this scenario follow what you have in mind? Please indicate which automation should proceed:

• This automation
• New proposed automation
• Both
• Neither, please specify
• Other, please specify

Also, how should the GHA manage the possibility of human error, such as issues being mislabeled (a possibility, as labels are becoming increasingly complex), or images not being put in the PR when they should (developers usually do not insist on photos since pulling it locally is often easier)?

---

On an adjacent note: Between issue creation, to approval, to assignment, to review, it can take anywhere from 2 weeks to 2 month before a GHA is fully implemented, by which time it might become defunct. For example, with the wins-feature-1 branch merged, this GHA involving feature branches has become potentially irrelevant for the foreseeable future. With our plans for creating a Dev and UAT version of the website, will UAT automations become irrelevant as well?

Also, will the GHA still be valuable after the backlog in the UAT column has been cleared?

I apologize if this is a lot to think over. I want to set expectations because it sounds like the UAT backlog might be a temporary problem, in which case a GHA might arrive too late to help.

[Aveline-art]

@blakes24 As per today's meeting, I have reworded the issue to better match PM intentions. Feel free to continue this issue and undraft your PR when it is ready for review. Thank you so much for working on this issue!

[github-actions]

@blakes24

Please add update using the below template (even if you have a pull request). Afterwards, remove the 'To Update !' label and add the 'Status: Updated' label.

1. Progress: "What is the current status of your project? What have you completed and what is left to do?"
2. Blockers: "Difficulties or errors encountered."
3. Availability: "How much time will you have this week to work on this issue?"
4. ETA: "When do you expect this issue to be completed?"
5. Pictures: "Add any pictures of the visual changes made to the site so far."

If you need help, be sure to either: 1) ask for help at your next meeting, 2) put a "Status: Help Wanted" label on your issue and pull request, or 3) put up a request for assistance on the #hfla-site channel.

_{You are receiving this comment because your last comment was before Tuesday, September 21, 2021 at 12:02 AM PST.}

[blakes24]

Progress: I have made the requested changes and updated my PR
Blockers: none
Availability: 5 hours
ETA: pending review
Pictures: NA

[ExperimentsInHonesty]

@macho-catt when you review the code, if it seems like there are two many conditionals, ask @blakes24 to review this summary which Matthew, Adam and I came up with during our lead meeting today.

All issue/PR that contain the following go to UAT:
front end that are not hard label
back end issues that are soft label