Skip to content

pull_request_template.md

Latest commit

 

History

History
65 lines (45 loc) · 3.82 KB

pull_request_template.md

File metadata and controls

65 lines (45 loc) · 3.82 KB

Risk assessment

For internal use only. Please select the risk level of this change:

  • Low risk: Changes are fully under feature flags, or have been fully tested and validated in pre-production environments and are highly observable, or are documentation or test only.
  • High risk: Changes are not fully under feature flags, have limited visibility and/or cannot be tested outside of production.

Which use cases does this change impact?

  • Advanced setup - Impacts users who have custom workflows.
  • Default setup - Impacts users who use default setup.
  • Code Scanning - Impacts Code Scanning (i.e. analysis-kinds: code-scanning).
  • Code Quality - Impacts Code Quality (i.e. analysis-kinds: code-quality).
  • Third-party analyses - Impacts third-party analyses (i.e. upload-sarif).
  • GHES - Impacts GitHub Enterprise Server.

How did/will you validate this change?

  • Test repository - This change will be tested on a test repository before merging.
  • Unit tests - I am depending on existing unit test coverage (i.e. tests in .test.ts files).
  • End-to-end tests - I am depending on PR checks (i.e. tests in pr-checks).
  • New / updated tests - I have added or updated unit / end-to-end tests to cover new or changed functionality (summarize below) OR I am providing a justification below for why test updates are not required.
  • Other - Please provide details.
  • None - I am not validating these changes (provide justification below).

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

  • Feature flags - All new or changed code paths can be fully disabled with corresponding feature flags.
  • Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix.
  • Other - Please provide details.

How will you know if something goes wrong after this change is released?

  • Telemetry - I rely on existing telemetry or have made changes to the telemetry.
    • Dashboards - I will watch relevant dashboards for issues after the release. Consider whether this requires this change to be released at a particular time rather than as part of a regular release.
    • Alerts - New or existing monitors will trip if something goes wrong with this change.
  • Other - Please provide details.

Merge / deployment checklist

  • Confirm this change is backwards compatible with existing workflows.
  • Tests (unit and/or end-to-end) have been added or updated as needed and are passing, OR a justification for not adding tests has been provided.
  • Consider adding a changelog entry for this change.
  • Confirm the readme and docs have been updated if necessary.