Skip to main content

Fixing code quality findings before merging your pull request

Learn how GitHub Code Quality helps you catch and fix quality issues before they reach your default branch, and how Correctif automatique Copilot and Agent de codage Copilot can help you quickly address any findings.

Qui peut utiliser cette fonctionnalité ?

Users with write access

GitHub Code Quality is available for:

  • Public repositories on GitHub.com
  • Organization-owned repositories on GitHub Team or GitHub Enterprise Cloud

Remarque

GitHub Code Quality is currently in public preview and subject to change. During public preview, Code Quality will not be billed, although Code Quality scans will consume GitHub Actions minutes.

Introduction

This tutorial shows you how to work with GitHub Code Quality on pull requests to identify code quality issues that your changes may otherwise inadvertently introduce, and how to address and resolve code quality findings with Copilot Autofix and Copilot coding agent.

Benefits of catching issues early

Catching code quality issues early keeps your team's codebase in shape. GitHub Code Quality checks your code for:

  • Reliability: For example, logic errors, unsafe error handling, or race conditions that could cause your app to crash or behave unpredictably. By addressing this type of issue early, you make your software more robust and dependable for users.
  • Maintainability: For example, duplicated code, overly complex logic, unused variables, or violations of coding best practices. Fixing these issues makes your code cleaner and easier to read, so future changes are faster and less risky.

1. Understand how GitHub Code Quality works on pull requests

When you open a pull request, GitHub Code Quality automatically scans your changes for quality issues like those described above.

The results of the scan are reported as comments on your pull request, left by the github-code-quality[bot]. Each comment corresponds to a specific code quality problem that was detected in your changes, and comes with a suggested autofix.

Comments are labeled by severity (Error, Warning, Note), so you can see which findings are the most critical to address.

2. Prioritize fixes based on severity

Scan through the comments and identify the findings that have the highest severity level ("Error") first.

If there are no "Error" findings, look for findings of the next severity level ("Warning"), and so on.

High severity findings indicate more serious code quality issues that are more likely to introduce reliability or maintainability problems in your codebase. By resolving high severity findings, you're doing the most impactful work to maintain the quality of your team's code.

Remarque

A repository administrator may have set a code quality gate that blocks merging on your pull request, if the pull request contains Code Quality findings of a particular severity level or above. See Resolving a block on your pull request.

3. Leverage Copilot Autofix or Copilot coding agent to fix findings

Copilot Autofix

Comments on the pull request include a suggested autofix that you can commit directly to your pull request. Carefully review the suggested autofix for logic, security, and style, then click Commit suggestion.

You don't need a Copilot license to apply these suggestions.

Copilot coding agent

Alternatively, if you have a Copilot license, you can delegate the remediation work to Copilot coding agent. Comment on the pull request mentioning @Copilot and request that Copilot fix the detected issues.

Screenshot showing a PR comment that invoked Copilot coding agent.

Copilot responds with an eyes emoji (👀) to your comment, starts a new agent session, and opens a pull request with the necessary fixes.

You can track Copilot coding agent's work:

You need a Copilot license to invoke Copilot coding agent.
Sign up for Copilot

4. Dismiss irrelevant findings

You can dismiss a finding if it isn’t relevant or actionable in the context of your codebase. Common reasons to dismiss a finding include:

  • The finding is in legacy code that’s no longer maintained.
  • It’s a known exception to your team’s coding standards.
  • It’s a false positive that doesn’t pose a real quality risk.

Dismissing irrelevant alerts keeps your quality checks focused on meaningful issues.

5. Push changes and wait for the scan

After fixing or dismissing findings, push your changes to the branch associated with your pull request. GitHub Code Quality will automatically re-scan your changes and update the comments on your pull request accordingly.

6. Check your repository's code quality ratings

Anyone with write access can view the overall code quality ratings for a repository, which summarize the state of the code's reliability and maintainability across the default branch.

To view your repository's ratings, navigate to the Security tab of your repository, expand Code quality in the sidebar, then click Standard findings.

By resolving issues before merging your pull request, you've directly contributed to maintaining these ratings.

Next steps