Notice about delayed notifications
Codecov delays notifications to make sure all reports are uploaded. Learn more at Merging Reports.
Customization of pull request comments?
If you are looking to customize your
comments, including turning them
off, please see Pull Request Comments
Codecov can send notifications to a variety of different services, all outlined below. For each service, there are a collection of standard fields in addition to fields custom to that service.
This page will first define the custom fields common to all notification systems and then define each service level notification setting in its relevant provider category.
Current supported notification providers out of the box are:
You may be able to interact with other types of notification providers using our Standard Notification Fields (below).
Standard Notification Fields
Note that these standard fields can be supplied for any of the providers defined below.
url: "https://url.to.service" branches': - master - dev - staging threshold': 1% flags: - backend - frontend base: "parent" only_pulls: false paths: "*/**/*"
The url to the service, not necessarily applicable to all providers, such as IRC.
The branches you for which you would like to send notifications. Defaults to all branches
The coverage threshold on which you would like to send a notification. If the coverage changes by more than the amount in the threshold field, a notification will be sent, otherwise it will not. Default to
None, which means that notifications will always be sent regardless of coverage change amount.
Specify the flags for which you would like notifications to be sent. Defaults to all flags. see: Flags
The base commit type to which you would like to send notifications. Options are
parent: compare the commit being notified on to its direct parent
- 'pr': compare the commit being notified on to the base of a PR if the commit is in a PR.
- 'auto': automatically choose the appropriate comparison. If the commit being notified on is in a PR,
prwill be used, otherwise
parentwill be used. This is the default.
Notify only on pull requests, default is
Only send a notification if the specified file paths change. Augments the flags setting. If both
paths are specified, a notification will be triggered if files covered by the supplied flags OR paths change.
Below is a basic configuration for adding a Slack notification.
coverage: notify: slack: default: url: "https://hooks.slack.com/services/abc/123" threshold: 1% only_pulls: false branches: - "master" flags: - "unit" paths: - "src"
Create a Slack Webhook URL
- Navigate to https://slack.com/apps.
- Search for
incoming webhookand click on the Incoming WebHooks result.
- Click Add Configuration.
- Follow the instructions to select a room and click Add Incoming Webhooks Integration.
- Copy the Webhook URL into your yaml.
Here is demonstrated the basic configuration for adding a Gitter notification.
coverage: notify: gitter: default: url: "https://webhooks.gitter.im/e/9d1957r0a481787c756z" threshold: 1% only_pulls: false branches: - "master" flags: - "unit" paths: - "src"
Create a Gitter Integration URL
- Navigate to your room in Gitter. ex. https://gitter.im/codecov/support.
- Click Room Settings icon (top-right corner).
- Click Integrations from the dropdown.
- Click on Codecov from the integration list.
- Copy the webhook url into your yaml.
All Codecov notifications can be customized. The advanced configuration shown below can be applied to any of the notifications services.
You may create additional notifications that post to different channels with different coverage metrics.
coverage: notify: slack: frontui: url: "https://hooks.slack.com/services/T04KHQ16W/B225J94BG" flags: - frontend - ui backunit: url: "https://hooks.slack.com/services/T04KHQ16W/B225J94BG" threshold: 2% # allow coverage to drop by 2% without posting a notification flags: - backend
Notice how we added two unique notifications. Each of them are measuring different reports based on Flags.
Preventing notifications until after
You may want to prevent any notifications until after a known number of builds. The
after_n_builds option delays notifications for a given commit until a certain number of uploads have been received and processed by Codecov. Some common use cases are:
- Parallel CI setups
- Long running CI pipelines that upload to Codecov multiple times
after_n_builds in your YAML, follow this example:
codecov: notify: after_n_builds: 5 # do not notify until at least 5 builds have been uploaded from the CI pipeline # you can also set after_n_builds on comments independently comment: after_n_builds: 4
In this YAML, at least 5 builds would need to be received before Codecov would push a notification.
Updated about 2 years ago