#2999: add monitor to workflows - MS

[Matt-Spence]

Ticket

Resolves nothing, this is step 1 for #2999

Changes

• Adds the GH Monitor action to all jobs in all workflows

Context for reviewers

Our GH token permission will be changing soon from a permissive default to a strict one, meaning we will need to define our permissions explicitly in each job/workflow. In order to figure out what permissions we need, the easiest thing to do is use GH's Monitor action, which will give us a report after each action is run on what permissions it needs. After that, we will update the permissions and remove the Monitor Action in a future PR.

Setup

Code Review Verification Steps

This can't truly be tested until merge, but the documentation for Monitor is here. Also make sure that I didn't miss any jobs.

As the original developer, I have

Satisfied acceptance criteria and met development standards

• Met the acceptance criteria, or will meet them in a subsequent PR
• Created/modified automated tests
• Update documentation in READMEs and/or onboarding guide

Ensured code standards are met (Original Developer)

• If any updated dependencies on Pipfile, also update dependencies in requirements.txt.
• Interactions with external systems are wrapped in try/except
• Error handling exists for unusual or missing values

Validated user-facing changes (if applicable)

• Tag @dotgov-designers in this PR's Reviewers for design review. If code is not user-facing, delete design reviewer checklist
• Verify new pages have been added to .pa11yci file so that they will be tested with our automated accessibility testing
• Checked keyboard navigability
• Tested general usability, landmarks, page header structure, and links with a screen reader (such as Voiceover or ANDI)

As a code reviewer, I have

Reviewed, tested, and left feedback about the changes

• Pulled this branch locally and tested it
• Verified code meets all checks above. Address any checks that are not satisfied
• Reviewed this code and left comments. Indicate if comments must be addressed before code is merged
• Checked that all code is adequately covered by tests
• Verify migrations are valid and do not conflict with existing migrations

Validated user-facing changes as a developer

Note: Multiple code reviewers can share the checklists above, a second reviewer should not make a duplicate checklist. All checks should be checked before approving, even those labeled N/A.

• New pages have been added to .pa11yci file so that they will be tested with our automated accessibility testing
• Checked keyboard navigability
• Meets all designs and user flows provided by design/product
• Tested general usability, landmarks, page header structure, and links with a screen reader (such as Voiceover or ANDI)
• (Rarely needed) Tested as both an analyst and applicant user

As a designer reviewer, I have

Verified that the changes match the design intention

• Checked that the design translated visually
• Checked behavior. Comment any found issues or broken flows.
• Checked different states (empty, one, some, error)
• Checked for landmarks, page heading structure, and links

Validated user-facing changes as a designer

• Checked keyboard navigability
• Tested general usability, landmarks, page header structure, and links with a screen reader (such as Voiceover or ANDI)
• Tested with multiple browsers (check off which ones were used)
  • Chrome
  • Microsoft Edge
  • FireFox
  • Safari
• (Rarely needed) Tested as both an analyst and applicant user

References

• Code review best practices

Screenshots

[abroddrick]

LGTM

[abroddrick]

@Matt-Spence The two things 1.) is that I believe for all new workflows may need this added in temporarily to verify the right permissions are added to them. To me that sounds like something to call out in a readme doc. Referring to this line in the PR checklist " Update documentation in READMEs and/or onboarding guide". #2, make sure to check off all the boxes on the PR checklist for "the original developer"

[Matt-Spence]

@Matt-Spence The two things 1.) is that I believe for all new workflows may need this added in temporarily to verify the right permissions are added to them. To me that sounds like something to call out in a readme doc. Referring to this line in the PR checklist " Update documentation in READMEs and/or onboarding guide". #2, make sure to check off all the boxes on the PR checklist for "the original developer"

That's a fair point. I'll update the README in the next PR where I address the actual permissions.