diff --git a/feed_rss_created.xml b/feed_rss_created.xml index 99d338f0f5..b404f83ea5 100644 --- a/feed_rss_created.xml +++ b/feed_rss_created.xml @@ -1 +1 @@ - Codacy docsDocumentation for the Codacy automated code review tool.https://docs.codacy.com/support@codacy.com (Codacy Support)https://github.com/codacy/docsen Tue, 20 Aug 2024 10:25:32 -0000 Tue, 20 Aug 2024 10:25:32 -0000 1440 MkDocs RSS plugin - v1.15.0 https://docs.codacy.com/assets/images/codacy-logo.png Codacy docshttps://docs.codacy.com/ Cloud July 2024 Release notes for Codacy Cloud July 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-07/ Mon, 19 Aug 2024 15:46:32 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-07/ Cloud June 2024 Release notes for Codacy Cloud June 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-06/ Mon, 15 Jul 2024 09:06:20 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-06/ Self-hosted v14.0.0 Release notes for Codacy Self-hosted v14.0.0.https://docs.codacy.com/release-notes/self-hosted/self-hosted-v14.0.0/ Wed, 26 Jun 2024 10:05:13 +0000Codacy docshttps://docs.codacy.com/release-notes/self-hosted/self-hosted-v14.0.0/ Cloud May 2024 Release notes for Codacy Cloud May 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-05/ Fri, 07 Jun 2024 14:54:54 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-05/ Cloud April 2024 Release notes for Codacy Cloud April 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-04/ Tue, 07 May 2024 16:32:07 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-04/ Cloud March 2024 Release notes for Codacy Cloud March 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-03/ Tue, 09 Apr 2024 12:24:00 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-03/ Cloud February 2024 Release notes for Codacy Cloud February 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-02/ Thu, 07 Mar 2024 17:51:38 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-02/ Cloud January 2024 Release notes for Codacy Cloud January 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-01/ Mon, 05 Feb 2024 16:15:35 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-01/ Discontinuation of SSH keys for GitHub repositories January 15, 2024 For increased security, Codacy is discontinuing the usage of repository SSH keys for Git operations on GitHub in favor of installation access tokens.https://docs.codacy.com/release-notes/cloud/cloud-2024-01-15-gh-repository-ssh-keys-discontinuation/ Mon, 15 Jan 2024 17:53:25 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-01-15-gh-repository-ssh-keys-discontinuation/ Cloud December 2023 Release notes for Codacy Cloud December 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-12/ Fri, 05 Jan 2024 09:59:01 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-12/ Cloud November 2023 Release notes for Codacy Cloud November 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-11/ Wed, 06 Dec 2023 17:03:53 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-11/ Removal of Jira, Slack, and Webhooks repository integrations November 13, 2023 On the week of November 13th 2023 we removed the option to create, configure, and delete Jira, Slack, and Webhooks integrations for your repositories. These integrations were available on the repository Settings, tab Integration.https://docs.codacy.com/release-notes/cloud/cloud-2023-11-13-jira-slack-webhooks-repo-integrations-removal/ Wed, 29 Nov 2023 10:05:21 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-11-13-jira-slack-webhooks-repo-integrations-removal/ Rollout of new Coverage engine November 23, 2023 As part of an ongoing effort to improve the speed and value of the insights provided by Codacy, we've been working on a new Coverage engine and started its deployment on November 23rd, 2023. The rollout to use the new engine across Codacy will be phased across several months and will gradually impact the coverage data you see on the Git provider, UI, and API.https://docs.codacy.com/release-notes/cloud/cloud-2023-11-23-new-coverage-engine-status-checks/ Thu, 23 Nov 2023 16:14:05 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-11-23-new-coverage-engine-status-checks/ Self-hosted v13.0.0 Release notes for Codacy Self-hosted v13.0.0.https://docs.codacy.com/release-notes/self-hosted/self-hosted-v13.0.0/ Thu, 23 Nov 2023 15:58:41 +0000Codacy docshttps://docs.codacy.com/release-notes/self-hosted/self-hosted-v13.0.0/ Cloud October 2023 Release notes for Codacy Cloud October 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-10/ Wed, 08 Nov 2023 09:11:28 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-10/ Deprecation of CSSLint, JSHint, Faux Pas, Tailor, TSLint October 25, 2023 On October 25th 2023 we deprecated the following tools: CSSLint, Faux Pas, JSHint, Tailor, and TSLint.https://docs.codacy.com/release-notes/cloud/cloud-2023-10-25-csslint-jshint-fauxpas-tailor-tslint-deprecation/ Wed, 25 Oct 2023 08:30:25 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-10-25-csslint-jshint-fauxpas-tailor-tslint-deprecation/ Deprecation of bundler-audit October 13, 2023 On October 13th 2023 we deprecated the tool bundler-audit in favor of Trivy, a more complete and actively maintained tool for detecting vulnerabilities in Ruby gems and other languages, with a vulnerability database that's updated daily.https://docs.codacy.com/release-notes/cloud/cloud-2023-10-13-bundler-audit-deprecation/ Fri, 13 Oct 2023 13:55:57 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-10-13-bundler-audit-deprecation/ Cloud September 2023 Release notes for Codacy Cloud September 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-09/ Fri, 06 Oct 2023 14:00:41 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-09/ Cloud August 2023 Release notes for Codacy Cloud August 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-08/ Thu, 07 Sep 2023 15:16:38 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-08/ Cloud July 2023 Release notes for Codacy Cloud July 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-07/ Fri, 04 Aug 2023 13:22:26 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-07/ \ No newline at end of file + Codacy docsDocumentation for the Codacy automated code review tool.https://docs.codacy.com/support@codacy.com (Codacy Support)https://github.com/codacy/docsen Tue, 27 Aug 2024 08:59:47 -0000 Tue, 27 Aug 2024 08:59:47 -0000 1440 MkDocs RSS plugin - v1.15.0 https://docs.codacy.com/assets/images/codacy-logo.png Codacy docshttps://docs.codacy.com/ Cloud July 2024 Release notes for Codacy Cloud July 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-07/ Mon, 19 Aug 2024 15:46:32 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-07/ Cloud June 2024 Release notes for Codacy Cloud June 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-06/ Mon, 15 Jul 2024 09:06:20 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-06/ Self-hosted v14.0.0 Release notes for Codacy Self-hosted v14.0.0.https://docs.codacy.com/release-notes/self-hosted/self-hosted-v14.0.0/ Wed, 26 Jun 2024 10:05:13 +0000Codacy docshttps://docs.codacy.com/release-notes/self-hosted/self-hosted-v14.0.0/ Cloud May 2024 Release notes for Codacy Cloud May 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-05/ Fri, 07 Jun 2024 14:54:54 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-05/ Cloud April 2024 Release notes for Codacy Cloud April 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-04/ Tue, 07 May 2024 16:32:07 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-04/ Cloud March 2024 Release notes for Codacy Cloud March 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-03/ Tue, 09 Apr 2024 12:24:00 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-03/ Cloud February 2024 Release notes for Codacy Cloud February 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-02/ Thu, 07 Mar 2024 17:51:38 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-02/ Cloud January 2024 Release notes for Codacy Cloud January 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-01/ Mon, 05 Feb 2024 16:15:35 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-01/ Discontinuation of SSH keys for GitHub repositories January 15, 2024 For increased security, Codacy is discontinuing the usage of repository SSH keys for Git operations on GitHub in favor of installation access tokens.https://docs.codacy.com/release-notes/cloud/cloud-2024-01-15-gh-repository-ssh-keys-discontinuation/ Mon, 15 Jan 2024 17:53:25 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-01-15-gh-repository-ssh-keys-discontinuation/ Cloud December 2023 Release notes for Codacy Cloud December 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-12/ Fri, 05 Jan 2024 09:59:01 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-12/ Cloud November 2023 Release notes for Codacy Cloud November 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-11/ Wed, 06 Dec 2023 17:03:53 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-11/ Removal of Jira, Slack, and Webhooks repository integrations November 13, 2023 On the week of November 13th 2023 we removed the option to create, configure, and delete Jira, Slack, and Webhooks integrations for your repositories. These integrations were available on the repository Settings, tab Integration.https://docs.codacy.com/release-notes/cloud/cloud-2023-11-13-jira-slack-webhooks-repo-integrations-removal/ Wed, 29 Nov 2023 10:05:21 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-11-13-jira-slack-webhooks-repo-integrations-removal/ Rollout of new Coverage engine November 23, 2023 As part of an ongoing effort to improve the speed and value of the insights provided by Codacy, we've been working on a new Coverage engine and started its deployment on November 23rd, 2023. The rollout to use the new engine across Codacy will be phased across several months and will gradually impact the coverage data you see on the Git provider, UI, and API.https://docs.codacy.com/release-notes/cloud/cloud-2023-11-23-new-coverage-engine-status-checks/ Thu, 23 Nov 2023 16:14:05 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-11-23-new-coverage-engine-status-checks/ Self-hosted v13.0.0 Release notes for Codacy Self-hosted v13.0.0.https://docs.codacy.com/release-notes/self-hosted/self-hosted-v13.0.0/ Thu, 23 Nov 2023 15:58:41 +0000Codacy docshttps://docs.codacy.com/release-notes/self-hosted/self-hosted-v13.0.0/ Cloud October 2023 Release notes for Codacy Cloud October 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-10/ Wed, 08 Nov 2023 09:11:28 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-10/ Deprecation of CSSLint, JSHint, Faux Pas, Tailor, TSLint October 25, 2023 On October 25th 2023 we deprecated the following tools: CSSLint, Faux Pas, JSHint, Tailor, and TSLint.https://docs.codacy.com/release-notes/cloud/cloud-2023-10-25-csslint-jshint-fauxpas-tailor-tslint-deprecation/ Wed, 25 Oct 2023 08:30:25 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-10-25-csslint-jshint-fauxpas-tailor-tslint-deprecation/ Deprecation of bundler-audit October 13, 2023 On October 13th 2023 we deprecated the tool bundler-audit in favor of Trivy, a more complete and actively maintained tool for detecting vulnerabilities in Ruby gems and other languages, with a vulnerability database that's updated daily.https://docs.codacy.com/release-notes/cloud/cloud-2023-10-13-bundler-audit-deprecation/ Fri, 13 Oct 2023 13:55:57 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-10-13-bundler-audit-deprecation/ Cloud September 2023 Release notes for Codacy Cloud September 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-09/ Fri, 06 Oct 2023 14:00:41 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-09/ Cloud August 2023 Release notes for Codacy Cloud August 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-08/ Thu, 07 Sep 2023 15:16:38 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-08/ Cloud July 2023 Release notes for Codacy Cloud July 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-07/ Fri, 04 Aug 2023 13:22:26 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-07/ \ No newline at end of file diff --git a/feed_rss_updated.xml b/feed_rss_updated.xml index 4ba2e1c1bd..3d9fc38fdd 100644 --- a/feed_rss_updated.xml +++ b/feed_rss_updated.xml @@ -1 +1 @@ - Codacy docsDocumentation for the Codacy automated code review tool.https://docs.codacy.com/support@codacy.com (Codacy Support)https://github.com/codacy/docsen Tue, 20 Aug 2024 10:25:32 -0000 Tue, 20 Aug 2024 10:25:32 -0000 1440 MkDocs RSS plugin - v1.15.0 https://docs.codacy.com/assets/images/codacy-logo.png Codacy docshttps://docs.codacy.com/ Codacy release notes Index of release notes for Codacy Cloud and Codacy Self-hosted.https://docs.codacy.com/release-notes/ Mon, 19 Aug 2024 15:46:32 +0000Codacy docshttps://docs.codacy.com/release-notes/ Cloud July 2024 Release notes for Codacy Cloud July 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-07/ Mon, 19 Aug 2024 15:46:32 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-07/ Cloud June 2024 Release notes for Codacy Cloud June 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-06/ Mon, 15 Jul 2024 09:06:20 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-06/ Self-hosted v14.0.0 Release notes for Codacy Self-hosted v14.0.0.https://docs.codacy.com/release-notes/self-hosted/self-hosted-v14.0.0/ Wed, 26 Jun 2024 10:17:57 +0000Codacy docshttps://docs.codacy.com/release-notes/self-hosted/self-hosted-v14.0.0/ Self-hosted v12.0.0 Release notes for Codacy Self-hosted v12.0.0.https://docs.codacy.com/release-notes/self-hosted/self-hosted-v12.0.0/ Wed, 26 Jun 2024 10:05:13 +0000Codacy docshttps://docs.codacy.com/release-notes/self-hosted/self-hosted-v12.0.0/ Self-hosted v13.0.0 Release notes for Codacy Self-hosted v13.0.0.https://docs.codacy.com/release-notes/self-hosted/self-hosted-v13.0.0/ Wed, 26 Jun 2024 10:05:13 +0000Codacy docshttps://docs.codacy.com/release-notes/self-hosted/self-hosted-v13.0.0/ Cloud May 2024 Release notes for Codacy Cloud May 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-05/ Fri, 07 Jun 2024 14:54:54 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-05/ Rollout of new Coverage engine November 23, 2023 As part of an ongoing effort to improve the speed and value of the insights provided by Codacy, we've been working on a new Coverage engine and started its deployment on November 23rd, 2023. The rollout to use the new engine across Codacy will be phased across several months and will gradually impact the coverage data you see on the Git provider, UI, and API.https://docs.codacy.com/release-notes/cloud/cloud-2023-11-23-new-coverage-engine-status-checks/ Fri, 07 Jun 2024 08:17:50 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-11-23-new-coverage-engine-status-checks/ Cloud January 2022 Release notes for Codacy Cloud January 2022.https://docs.codacy.com/release-notes/cloud/cloud-2022-01/ Wed, 08 May 2024 16:36:15 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2022-01/ Cloud January 2023 Release notes for Codacy Cloud January 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-01/ Wed, 08 May 2024 16:36:15 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-01/ Cloud April 2024 Release notes for Codacy Cloud April 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-04/ Tue, 07 May 2024 16:32:07 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-04/ Cloud March 2024 Release notes for Codacy Cloud March 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-03/ Tue, 09 Apr 2024 12:24:00 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-03/ Cloud March 2023 Release notes for Codacy Cloud March 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-03/ Thu, 14 Mar 2024 17:34:50 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-03/ Cloud February 2024 Release notes for Codacy Cloud February 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-02/ Thu, 07 Mar 2024 17:51:38 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-02/ Cloud December 2023 Release notes for Codacy Cloud December 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-12/ Mon, 19 Feb 2024 16:04:14 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-12/ Cloud October 2023 Release notes for Codacy Cloud October 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-10/ Thu, 15 Feb 2024 17:22:38 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-10/ Cloud January 2024 Release notes for Codacy Cloud January 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-01/ Wed, 07 Feb 2024 09:59:24 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-01/ Discontinuation of SSH keys for GitHub repositories January 15, 2024 For increased security, Codacy is discontinuing the usage of repository SSH keys for Git operations on GitHub in favor of installation access tokens.https://docs.codacy.com/release-notes/cloud/cloud-2024-01-15-gh-repository-ssh-keys-discontinuation/ Wed, 17 Jan 2024 13:49:02 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-01-15-gh-repository-ssh-keys-discontinuation/ Cloud November 2023 Release notes for Codacy Cloud November 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-11/ Wed, 06 Dec 2023 17:03:53 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-11/ Removal of Jira, Slack, and Webhooks repository integrations November 13, 2023 On the week of November 13th 2023 we removed the option to create, configure, and delete Jira, Slack, and Webhooks integrations for your repositories. These integrations were available on the repository Settings, tab Integration.https://docs.codacy.com/release-notes/cloud/cloud-2023-11-13-jira-slack-webhooks-repo-integrations-removal/ Wed, 29 Nov 2023 10:05:21 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-11-13-jira-slack-webhooks-repo-integrations-removal/ \ No newline at end of file + Codacy docsDocumentation for the Codacy automated code review tool.https://docs.codacy.com/support@codacy.com (Codacy Support)https://github.com/codacy/docsen Tue, 27 Aug 2024 08:59:47 -0000 Tue, 27 Aug 2024 08:59:47 -0000 1440 MkDocs RSS plugin - v1.15.0 https://docs.codacy.com/assets/images/codacy-logo.png Codacy docshttps://docs.codacy.com/ Codacy release notes Index of release notes for Codacy Cloud and Codacy Self-hosted.https://docs.codacy.com/release-notes/ Mon, 19 Aug 2024 15:46:32 +0000Codacy docshttps://docs.codacy.com/release-notes/ Cloud July 2024 Release notes for Codacy Cloud July 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-07/ Mon, 19 Aug 2024 15:46:32 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-07/ Cloud June 2024 Release notes for Codacy Cloud June 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-06/ Mon, 15 Jul 2024 09:06:20 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-06/ Self-hosted v14.0.0 Release notes for Codacy Self-hosted v14.0.0.https://docs.codacy.com/release-notes/self-hosted/self-hosted-v14.0.0/ Wed, 26 Jun 2024 10:17:57 +0000Codacy docshttps://docs.codacy.com/release-notes/self-hosted/self-hosted-v14.0.0/ Self-hosted v12.0.0 Release notes for Codacy Self-hosted v12.0.0.https://docs.codacy.com/release-notes/self-hosted/self-hosted-v12.0.0/ Wed, 26 Jun 2024 10:05:13 +0000Codacy docshttps://docs.codacy.com/release-notes/self-hosted/self-hosted-v12.0.0/ Self-hosted v13.0.0 Release notes for Codacy Self-hosted v13.0.0.https://docs.codacy.com/release-notes/self-hosted/self-hosted-v13.0.0/ Wed, 26 Jun 2024 10:05:13 +0000Codacy docshttps://docs.codacy.com/release-notes/self-hosted/self-hosted-v13.0.0/ Cloud May 2024 Release notes for Codacy Cloud May 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-05/ Fri, 07 Jun 2024 14:54:54 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-05/ Rollout of new Coverage engine November 23, 2023 As part of an ongoing effort to improve the speed and value of the insights provided by Codacy, we've been working on a new Coverage engine and started its deployment on November 23rd, 2023. The rollout to use the new engine across Codacy will be phased across several months and will gradually impact the coverage data you see on the Git provider, UI, and API.https://docs.codacy.com/release-notes/cloud/cloud-2023-11-23-new-coverage-engine-status-checks/ Fri, 07 Jun 2024 08:17:50 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-11-23-new-coverage-engine-status-checks/ Cloud January 2022 Release notes for Codacy Cloud January 2022.https://docs.codacy.com/release-notes/cloud/cloud-2022-01/ Wed, 08 May 2024 16:36:15 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2022-01/ Cloud January 2023 Release notes for Codacy Cloud January 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-01/ Wed, 08 May 2024 16:36:15 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-01/ Cloud April 2024 Release notes for Codacy Cloud April 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-04/ Tue, 07 May 2024 16:32:07 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-04/ Cloud March 2024 Release notes for Codacy Cloud March 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-03/ Tue, 09 Apr 2024 12:24:00 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-03/ Cloud March 2023 Release notes for Codacy Cloud March 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-03/ Thu, 14 Mar 2024 17:34:50 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-03/ Cloud February 2024 Release notes for Codacy Cloud February 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-02/ Thu, 07 Mar 2024 17:51:38 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-02/ Cloud December 2023 Release notes for Codacy Cloud December 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-12/ Mon, 19 Feb 2024 16:04:14 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-12/ Cloud October 2023 Release notes for Codacy Cloud October 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-10/ Thu, 15 Feb 2024 17:22:38 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-10/ Cloud January 2024 Release notes for Codacy Cloud January 2024.https://docs.codacy.com/release-notes/cloud/cloud-2024-01/ Wed, 07 Feb 2024 09:59:24 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-01/ Discontinuation of SSH keys for GitHub repositories January 15, 2024 For increased security, Codacy is discontinuing the usage of repository SSH keys for Git operations on GitHub in favor of installation access tokens.https://docs.codacy.com/release-notes/cloud/cloud-2024-01-15-gh-repository-ssh-keys-discontinuation/ Wed, 17 Jan 2024 13:49:02 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2024-01-15-gh-repository-ssh-keys-discontinuation/ Cloud November 2023 Release notes for Codacy Cloud November 2023.https://docs.codacy.com/release-notes/cloud/cloud-2023-11/ Wed, 06 Dec 2023 17:03:53 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-11/ Removal of Jira, Slack, and Webhooks repository integrations November 13, 2023 On the week of November 13th 2023 we removed the option to create, configure, and delete Jira, Slack, and Webhooks integrations for your repositories. These integrations were available on the repository Settings, tab Integration.https://docs.codacy.com/release-notes/cloud/cloud-2023-11-13-jira-slack-webhooks-repo-integrations-removal/ Wed, 29 Nov 2023 10:05:21 +0000Codacy docshttps://docs.codacy.com/release-notes/cloud/cloud-2023-11-13-jira-slack-webhooks-repo-integrations-removal/ \ No newline at end of file diff --git a/organizations/images/coding-standard-create.png b/organizations/images/coding-standard-create.png index 09d0bb781b..ae6ecb4158 100644 Binary files a/organizations/images/coding-standard-create.png and b/organizations/images/coding-standard-create.png differ diff --git a/organizations/images/coding-standard-delete.png b/organizations/images/coding-standard-delete.png index 454db807c1..71181c17c0 100644 Binary files a/organizations/images/coding-standard-delete.png and b/organizations/images/coding-standard-delete.png differ diff --git a/organizations/images/coding-standard-edit.png b/organizations/images/coding-standard-edit.png index 72b8c532af..4499a7d527 100644 Binary files a/organizations/images/coding-standard-edit.png and b/organizations/images/coding-standard-edit.png differ diff --git a/organizations/images/coding-standard-set-default.png b/organizations/images/coding-standard-set-default.png index 42ca404916..33fa8011e5 100644 Binary files a/organizations/images/coding-standard-set-default.png and b/organizations/images/coding-standard-set-default.png differ diff --git a/organizations/using-coding-standards/index.html b/organizations/using-coding-standards/index.html index 57f3c75279..e42049f3d7 100644 --- a/organizations/using-coding-standards/index.html +++ b/organizations/using-coding-standards/index.html @@ -11,7 +11,7 @@ - + @@ -4449,7 +4449,7 @@

Defining default coding standardsOpen your organization Policies page, tab Coding standards.

  • -

    Toggle Apply to new repositoriet on the relevant coding standard card.

    +

    Toggle Apply to new repositories on the relevant coding standard card.

    Setting a coding standard as the default

  • @@ -4670,7 +4670,7 @@

    Share your feedback 📢

    - Last modified August 20, 2024 + Last modified August 27, 2024
    diff --git a/repositories-configure/configuring-code-patterns/index.html b/repositories-configure/configuring-code-patterns/index.html index ed8525da24..e67b8487cd 100644 --- a/repositories-configure/configuring-code-patterns/index.html +++ b/repositories-configure/configuring-code-patterns/index.html @@ -11,7 +11,7 @@ - + @@ -548,8 +548,8 @@
  • - - Detaching a coding standard from a repository + + Customizing applied coding standards
  • @@ -4327,9 +4327,11 @@

    Configuring too

    Optionally, to take the changes into account immediately, reanalyze the repository manually. Otherwise, Codacy will use the updated configuration when analyzing new commits and pull requests.

    -

    Detaching a coding standard from a repository#

    -

    If the repository is following a coding standard, a notice is displayed. To detach the coding standard from the repository, click Detach repository and confirm.

    -

    Detaching a coding standard

    +

    Customizing applied coding standards#

    +

    To apply or edit a repository's coding standards, click Customize in the Following ... section at the top of the Code patterns page.

    +

    Customize applied coding standards

    +

    Select the coding standards that you want to follow or stop following and click Apply.

    +

    Customize applied coding standards

    Using tool configuration files#

    Note

    @@ -4738,7 +4740,7 @@

    Share your feedback 📢

    - Last modified August 12, 2024 + Last modified August 27, 2024
    diff --git a/repositories-configure/images/code-patterns-config-file.png b/repositories-configure/images/code-patterns-config-file.png index 6ff884eaab..8c01253bea 100644 Binary files a/repositories-configure/images/code-patterns-config-file.png and b/repositories-configure/images/code-patterns-config-file.png differ diff --git a/repositories-configure/images/code-patterns-cs-customize-modal.png b/repositories-configure/images/code-patterns-cs-customize-modal.png new file mode 100644 index 0000000000..cde8b55352 Binary files /dev/null and b/repositories-configure/images/code-patterns-cs-customize-modal.png differ diff --git a/repositories-configure/images/code-patterns-cs-customize.png b/repositories-configure/images/code-patterns-cs-customize.png new file mode 100644 index 0000000000..ff25539623 Binary files /dev/null and b/repositories-configure/images/code-patterns-cs-customize.png differ diff --git a/repositories-configure/images/code-patterns.png b/repositories-configure/images/code-patterns.png index c9054bc373..8a2027744f 100644 Binary files a/repositories-configure/images/code-patterns.png and b/repositories-configure/images/code-patterns.png differ diff --git a/search/search_index.json b/search/search_index.json index c675e61c23..961020d068 100644 --- a/search/search_index.json +++ b/search/search_index.json @@ -1 +1 @@ -{"config": {"indexing": "full", "lang": ["en"], "min_search_length": 3, "prebuild_index": false, "separator": "[\\s\\-]+"}, "docs": [{"location": "", "text": "Documentation home # Getting started Adding your first repository (5 min) Sign up with your Git provider so that Codacy can have access to your Git provider organizations and members. You can then add any repository you have access to with one click. Supported languages Codacy supports over 40 programming languages and infrastructure-as-code platforms out of the box, and regularly adds support for new languages and tools. Using Codacy Creating and managing an organization Codacy automatically imports your Git provider organizations and members. Changes reflect on Codacy in real time and you can manage people who joined your organization on Codacy. Setting up integrations Configure Codacy to provide analysis feedback and status checks directly on your pull requests. Most popular topics Managing people in organizations Invite your teammates to join Codacy to analyze their commits on private repositories. Adding coverage to your repository Set up your repositories to show code coverage reports directly on Codacy. Using the Codacy API Retrieve and analyze data from Codacy and perform configuration changes programmatically", "title": "Documentation home"}, {"location": "#documentation-home", "text": "Getting started Adding your first repository (5 min) Sign up with your Git provider so that Codacy can have access to your Git provider organizations and members. You can then add any repository you have access to with one click. Supported languages Codacy supports over 40 programming languages and infrastructure-as-code platforms out of the box, and regularly adds support for new languages and tools. Using Codacy Creating and managing an organization Codacy automatically imports your Git provider organizations and members. Changes reflect on Codacy in real time and you can manage people who joined your organization on Codacy. Setting up integrations Configure Codacy to provide analysis feedback and status checks directly on your pull requests.", "title": "Documentation home"}, {"location": "special-thanks/", "text": "Special thanks # We would like to thank everyone who helped us greatly . The names on these lists contributed immensely to what Codacy is today. Open source tools # In addition to in-house built rules, we use open source tools for many of our static analysis. We want to express our gratitude to everyone who contributed to those tools. SonarC# PMD Brakeman RuboCop SimpleCov CoffeeLint Pylint SonarVB PHPMD PHP_CodeSniffer Mocha Scalastyle CSSLint radon Clone Digger PHPCPD plato sloc LessLinter Hadolint SCSSLint Credo PSScriptAnalyzer Ameba Language support contributions # These are the tools integrated on Codacy by our own users! Without them, we wouldn't have support for these languages. Language Who made it possible CoffeeScript Ryan Delaney Elixir Grant McLendon PowerShell Aditya Patwardhan Crystal Vitalii Elenhaupt Collaborators # For all the people who helped us so much, we want to give a big shout out and thanks! David Pate Adriaan Moors Iulian Dragos Jakob Pupke Mathieu Demarne Ryan Shipp Eugene Burmako", "title": "Special thanks"}, {"location": "special-thanks/#special-thanks", "text": "We would like to thank everyone who helped us greatly . The names on these lists contributed immensely to what Codacy is today.", "title": "Special thanks"}, {"location": "special-thanks/#open-source-tools", "text": "In addition to in-house built rules, we use open source tools for many of our static analysis. We want to express our gratitude to everyone who contributed to those tools. SonarC# PMD Brakeman RuboCop SimpleCov CoffeeLint Pylint SonarVB PHPMD PHP_CodeSniffer Mocha Scalastyle CSSLint radon Clone Digger PHPCPD plato sloc LessLinter Hadolint SCSSLint Credo PSScriptAnalyzer Ameba", "title": "Open source tools"}, {"location": "special-thanks/#language-support-contributions", "text": "These are the tools integrated on Codacy by our own users! Without them, we wouldn't have support for these languages. Language Who made it possible CoffeeScript Ryan Delaney Elixir Grant McLendon PowerShell Aditya Patwardhan Crystal Vitalii Elenhaupt", "title": "Language support contributions"}, {"location": "special-thanks/#collaborators", "text": "For all the people who helped us so much, we want to give a big shout out and thanks! David Pate Adriaan Moors Iulian Dragos Jakob Pupke Mathieu Demarne Ryan Shipp Eugene Burmako", "title": "Collaborators"}, {"location": "account/emails/", "text": "Emails # To manage the email addresses associated with your account and your email notifications, click on your avatar on the top right-hand corner and open Your account , page Emails . Updating your email addresses # Codacy automatically links to your Codacy account the email addresses from the Git provider associated with your current session. On the Emails page, you can verify which email addresses are linked to your Codacy account. Note For GitHub , if you have email privacy enabled on the provider, Codacy doesn't show your private emails and uses another available email address when displaying your personal details on lists, search filters, or activity. To update the email addresses associated with your Codacy account, do the following: Configure your Git email address . This ensures that commits are attributed to you. Update your email addresses on your Git provider ( GitHub , Bitbucket , or GitLab ). Log out and log back in to Codacy. Tip If the updates are still not reflected on Codacy, navigate to the access management page, revoke the relevant Git provider integration, then log out and back in to Codacy using the same provider. Note When developers commit from GitHub or Bitbucket , Codacy automatically associates all the commit email addresses from the same Git provider user with a single Codacy committer. For developers that never logged in to the Codacy app, this mechanism requires that they set their Git email address and add all their email addresses to their GitHub account or Bitbucket account . Setting your Git email address # Unless you explicitly configure your email address , Git automatically uses an email address based on the username and hostname of your workstation, and associates this email address with your commits. To check which email address your local Git installation is using, run the following command on your workstation: git config user.email If the returned email address isn't one of the email addresses associated with your Git provider account, configure Git to use one of those email addresses instead: git config --global user.email you@example.com Important Make sure that your email address doesn't include any extra characters such as quotes ( \"\" or '' ). Managing your email notifications # Codacy can send you an email whenever there are new analysis results on your repositories with the list of found issues and the changes that created them. Codacy sends all email notifications to your default email address, and you can change your default email address by clicking make default next to another email address. Configure the notifications that you wish to receive under Repository notifications : Per commit: Codacy will send you an email for each analyzed commit. Per pull request: Codacy will send you an email for each analyzed pull request. Only my activity: By default, Codacy will only send you emails about your own commits and pull requests. Turn off this setting to receive emails for commits and pull requests made by other people as well. Tip To turn off all email notifications, disable the settings Per commit and Per pull request .", "title": "Emails"}, {"location": "account/emails/#emails", "text": "To manage the email addresses associated with your account and your email notifications, click on your avatar on the top right-hand corner and open Your account , page Emails .", "title": "Emails"}, {"location": "account/emails/#updating", "text": "Codacy automatically links to your Codacy account the email addresses from the Git provider associated with your current session. On the Emails page, you can verify which email addresses are linked to your Codacy account. Note For GitHub , if you have email privacy enabled on the provider, Codacy doesn't show your private emails and uses another available email address when displaying your personal details on lists, search filters, or activity. To update the email addresses associated with your Codacy account, do the following: Configure your Git email address . This ensures that commits are attributed to you. Update your email addresses on your Git provider ( GitHub , Bitbucket , or GitLab ). Log out and log back in to Codacy. Tip If the updates are still not reflected on Codacy, navigate to the access management page, revoke the relevant Git provider integration, then log out and back in to Codacy using the same provider. Note When developers commit from GitHub or Bitbucket , Codacy automatically associates all the commit email addresses from the same Git provider user with a single Codacy committer. For developers that never logged in to the Codacy app, this mechanism requires that they set their Git email address and add all their email addresses to their GitHub account or Bitbucket account .", "title": "Updating your email addresses"}, {"location": "account/emails/#managing-your-email-notifications", "text": "Codacy can send you an email whenever there are new analysis results on your repositories with the list of found issues and the changes that created them. Codacy sends all email notifications to your default email address, and you can change your default email address by clicking make default next to another email address. Configure the notifications that you wish to receive under Repository notifications : Per commit: Codacy will send you an email for each analyzed commit. Per pull request: Codacy will send you an email for each analyzed pull request. Only my activity: By default, Codacy will only send you emails about your own commits and pull requests. Turn off this setting to receive emails for commits and pull requests made by other people as well. Tip To turn off all email notifications, disable the settings Per commit and Per pull request .", "title": "Managing your email notifications"}, {"location": "account/managing-your-profile/", "text": "Managing your profile # To manage your profile information such as your name and avatar, click on your avatar on the top right-hand corner and select Your account . Changing your name or avatar # To change your avatar, sign up or log in at Gravatar using the same email address that you used to log into Codacy. The avatar that you define there will be automatically used as your avatar on Codacy. Note Organization avatars aren't editable at the moment. To change your name, update the field Name and click the button Update profile . Deleting your account # When you delete your account on Codacy: Your profile information and all data related to your personal repositories are completely removed from Codacy Codacy will stop analyzing any repositories added to Codacy using your account This operation doesn't make any changes on your Git provider. To delete your account, click the button Delete account and confirm that you really want to proceed. Note If you're the last organization admin of any of your organizations, you must either add someone else as an owner or delete those organizations before you can delete your account.", "title": "Managing your profile"}, {"location": "account/managing-your-profile/#managing-your-profile", "text": "To manage your profile information such as your name and avatar, click on your avatar on the top right-hand corner and select Your account .", "title": "Managing your profile"}, {"location": "account/managing-your-profile/#changing-your-name-or-avatar", "text": "To change your avatar, sign up or log in at Gravatar using the same email address that you used to log into Codacy. The avatar that you define there will be automatically used as your avatar on Codacy. Note Organization avatars aren't editable at the moment. To change your name, update the field Name and click the button Update profile .", "title": "Changing your name or avatar"}, {"location": "account/managing-your-profile/#deleting-your-account", "text": "When you delete your account on Codacy: Your profile information and all data related to your personal repositories are completely removed from Codacy Codacy will stop analyzing any repositories added to Codacy using your account This operation doesn't make any changes on your Git provider. To delete your account, click the button Delete account and confirm that you really want to proceed. Note If you're the last organization admin of any of your organizations, you must either add someone else as an owner or delete those organizations before you can delete your account.", "title": "Deleting your account"}, {"location": "account/user-session-management/", "text": "User session management # To reduce the risk of unauthorized access to your account, Codacy sets automatic expiration timeouts for every session. When a session expires, Codacy invalidates the session both on the client and server side, and creates a new session. Idle session timeout # The idle session timeout on the Codacy app is 30 minutes . In the absence of user activity during this period, such as typing or using the mouse, Codacy logs out the user and invalidates the session. Absolute session timeout # The absolute session timeout on the Codacy app is 8 hours . When an active session reaches this maximum period, Codacy logs out the user and invalidates the session.", "title": "User session management"}, {"location": "account/user-session-management/#user-session-management", "text": "To reduce the risk of unauthorized access to your account, Codacy sets automatic expiration timeouts for every session. When a session expires, Codacy invalidates the session both on the client and server side, and creates a new session.", "title": "User session management"}, {"location": "account/user-session-management/#idle-session-timeout", "text": "The idle session timeout on the Codacy app is 30 minutes . In the absence of user activity during this period, such as typing or using the mouse, Codacy logs out the user and invalidates the session.", "title": "Idle session timeout"}, {"location": "account/user-session-management/#absolute-session-timeout", "text": "The absolute session timeout on the Codacy app is 8 hours . When an active session reaches this maximum period, Codacy logs out the user and invalidates the session.", "title": "Absolute session timeout"}, {"location": "chart/", "text": "Installing Codacy Self-hosted # This documentation guides you on how to install Codacy Self-hosted on Kubernetes or MicroK8s. Important If you're running the legacy Codacy Self-hosted solution running on Docker please contact support@codacy.com so that we can assist you with the migration to Codacy Self-hosted running on Kubernetes or MicroK8s. To install Codacy you must complete these main steps: Setting up the system requirements Ensure that your infrastructure meets the hardware and system requirements to run Codacy. Installing Codacy Install Codacy on the cluster using our Helm chart that includes all the necessary components and dependencies. Configuring Codacy Configure integrations with Git providers and set up monitoring. The next sections include detailed instructions on how to complete each step of the installation process. Make sure that you complete each step before advancing to the next one. 1. Setting up the system requirements # Before you start, you must prepare and provision the database server and Kubernetes or MicroK8s cluster that will host Codacy. Carefully review and set up the system requirements to run Codacy by following the instructions on the page below: System requirements Optionally, you can follow one of the guides below to quickly create a new Kubernetes or MicroK8s cluster that satisfies the characteristics described in the system requirements: Creating an Amazon EKS cluster Creating a MicroK8s cluster 2. Installing Codacy # Install Codacy on an existing cluster using our Helm chart: Make sure that you have the following tools installed on your machine: kubectl within one minor version difference of your cluster Important If you're using MicroK8s you don't need to install kubectl because you will execute all kubectl commands as microk8s.kubectl commands instead. To simplify this, check how to create an alias for kubectl . Helm version >= 3.9 Create a cluster namespace called codacy that will group all resources related to Codacy. kubectl create namespace codacy Add the Docker registry credentials provided by Codacy together with your license to a cluster Secret. This is necessary because some Codacy Docker images are currently private. Substitute and with the Docker registry username and password and run the following command: kubectl create secret docker-registry docker-credentials \\ --docker-username = \\ --docker-password = \\ --namespace codacy Download the template file values-production.yaml and use a text editor of your choice to edit the value placeholders as described in the comments. Create an address record on your DNS provider mapping the hostname you used in the previous step to the IP address of your Ingress controller. Important If you're using MicroK8s you must map the hostname to the public IP address of the machine running MicroK8s. Add Codacy's chart repository to your Helm client and install the Codacy chart using the file values-production.yaml created previously. Important If you're using MicroK8s you must download and use the file values-microk8s.yaml together with the file values-production.yaml by uncommenting the last line in the helm upgrade command below. helm repo add codacy-stable https://charts.codacy.com/stable/ helm repo update helm upgrade --install codacy codacy-stable/codacy \\ --namespace codacy \\ --version 14 .0.0 \\ --values values-production.yaml # --values values-microk8s.yaml By now all the Codacy pods should be starting in the cluster. Run the following command and wait for all the pods to have the status Running , which can take several minutes: $ kubectl get pods -n codacy NAME READY STATUS RESTARTS AGE codacy-api-f7897b965-fgn67 1 /1 Running 0 8m57s codacy-api-f7897b965-kkqsx 1 /1 Running 0 8m57s codacy-crow-7c957d45f6-b8zp2 1 /1 Running 2 8m57s codacy-crowdb-0 1 /1 Running 0 8m57s codacy-engine-549bcb69d9-cgrqf 1 /1 Running 1 8m57s codacy-engine-549bcb69d9-sh5f4 1 /1 Running 1 8m57s codacy-fluentdoperator-x5vr2 2 /2 Running 0 8m57s codacy-listener-868b784dcf-npdfh 1 /1 Running 0 8m57s codacy-listenerdb-0 1 /1 Running 0 8m57s codacy-minio-7cfdc7b4f4-254gz 1 /1 Running 0 8m57s codacy-nfsserverprovisioner-0 1 /1 Running 0 8m57s codacy-portal-774d9fc596-rwqj5 1 /1 Running 2 8m56s codacy-rabbitmq-ha-0 1 /1 Running 0 8m57s codacy-ragnaros-69459775b5-hmj4d 1 /1 Running 3 8m57s codacy-remote-provider-service-8fb8556b-rr4ws 1 /1 Running 0 8m56s codacy-worker-manager-656dbf8d6d-n4j7c 1 /1 Running 0 8m57s 3. Configuring Codacy # After successfully installing Codacy on your cluster, you're now ready to perform the post-install configuration steps: Use a browser to navigate to the Codacy hostname previously configured on the file values-production.yaml . Log in using your Git provider account. This automatically creates a Codacy administrator account with your credentials. Follow Codacy's onboarding process, which will guide you through the following steps: Configuring one or more of the following supported integrations: GitHub Cloud GitHub Enterprise GitLab Cloud GitLab Enterprise Bitbucket Cloud Bitbucket Server Email Creating an initial organization Inviting users to Codacy As a last step we recommend that you set up monitoring on your Codacy instance. If you run into any issues while configuring Codacy, be sure to check our troubleshooting guide for more help.", "title": "Installing Codacy Self-hosted"}, {"location": "chart/#installing-codacy-self-hosted", "text": "This documentation guides you on how to install Codacy Self-hosted on Kubernetes or MicroK8s. Important If you're running the legacy Codacy Self-hosted solution running on Docker please contact support@codacy.com so that we can assist you with the migration to Codacy Self-hosted running on Kubernetes or MicroK8s. To install Codacy you must complete these main steps: Setting up the system requirements Ensure that your infrastructure meets the hardware and system requirements to run Codacy. Installing Codacy Install Codacy on the cluster using our Helm chart that includes all the necessary components and dependencies. Configuring Codacy Configure integrations with Git providers and set up monitoring. The next sections include detailed instructions on how to complete each step of the installation process. Make sure that you complete each step before advancing to the next one.", "title": "Installing Codacy Self-hosted"}, {"location": "chart/#1-setting-up-the-system-requirements", "text": "Before you start, you must prepare and provision the database server and Kubernetes or MicroK8s cluster that will host Codacy. Carefully review and set up the system requirements to run Codacy by following the instructions on the page below: System requirements Optionally, you can follow one of the guides below to quickly create a new Kubernetes or MicroK8s cluster that satisfies the characteristics described in the system requirements: Creating an Amazon EKS cluster Creating a MicroK8s cluster", "title": "1. Setting up the system requirements"}, {"location": "chart/#2-installing-codacy", "text": "Install Codacy on an existing cluster using our Helm chart: Make sure that you have the following tools installed on your machine: kubectl within one minor version difference of your cluster Important If you're using MicroK8s you don't need to install kubectl because you will execute all kubectl commands as microk8s.kubectl commands instead. To simplify this, check how to create an alias for kubectl . Helm version >= 3.9 Create a cluster namespace called codacy that will group all resources related to Codacy. kubectl create namespace codacy Add the Docker registry credentials provided by Codacy together with your license to a cluster Secret. This is necessary because some Codacy Docker images are currently private. Substitute and with the Docker registry username and password and run the following command: kubectl create secret docker-registry docker-credentials \\ --docker-username = \\ --docker-password = \\ --namespace codacy Download the template file values-production.yaml and use a text editor of your choice to edit the value placeholders as described in the comments. Create an address record on your DNS provider mapping the hostname you used in the previous step to the IP address of your Ingress controller. Important If you're using MicroK8s you must map the hostname to the public IP address of the machine running MicroK8s. Add Codacy's chart repository to your Helm client and install the Codacy chart using the file values-production.yaml created previously. Important If you're using MicroK8s you must download and use the file values-microk8s.yaml together with the file values-production.yaml by uncommenting the last line in the helm upgrade command below. helm repo add codacy-stable https://charts.codacy.com/stable/ helm repo update helm upgrade --install codacy codacy-stable/codacy \\ --namespace codacy \\ --version 14 .0.0 \\ --values values-production.yaml # --values values-microk8s.yaml By now all the Codacy pods should be starting in the cluster. Run the following command and wait for all the pods to have the status Running , which can take several minutes: $ kubectl get pods -n codacy NAME READY STATUS RESTARTS AGE codacy-api-f7897b965-fgn67 1 /1 Running 0 8m57s codacy-api-f7897b965-kkqsx 1 /1 Running 0 8m57s codacy-crow-7c957d45f6-b8zp2 1 /1 Running 2 8m57s codacy-crowdb-0 1 /1 Running 0 8m57s codacy-engine-549bcb69d9-cgrqf 1 /1 Running 1 8m57s codacy-engine-549bcb69d9-sh5f4 1 /1 Running 1 8m57s codacy-fluentdoperator-x5vr2 2 /2 Running 0 8m57s codacy-listener-868b784dcf-npdfh 1 /1 Running 0 8m57s codacy-listenerdb-0 1 /1 Running 0 8m57s codacy-minio-7cfdc7b4f4-254gz 1 /1 Running 0 8m57s codacy-nfsserverprovisioner-0 1 /1 Running 0 8m57s codacy-portal-774d9fc596-rwqj5 1 /1 Running 2 8m56s codacy-rabbitmq-ha-0 1 /1 Running 0 8m57s codacy-ragnaros-69459775b5-hmj4d 1 /1 Running 3 8m57s codacy-remote-provider-service-8fb8556b-rr4ws 1 /1 Running 0 8m56s codacy-worker-manager-656dbf8d6d-n4j7c 1 /1 Running 0 8m57s", "title": "2. Installing Codacy"}, {"location": "chart/#3-configuring-codacy", "text": "After successfully installing Codacy on your cluster, you're now ready to perform the post-install configuration steps: Use a browser to navigate to the Codacy hostname previously configured on the file values-production.yaml . Log in using your Git provider account. This automatically creates a Codacy administrator account with your credentials. Follow Codacy's onboarding process, which will guide you through the following steps: Configuring one or more of the following supported integrations: GitHub Cloud GitHub Enterprise GitLab Cloud GitLab Enterprise Bitbucket Cloud Bitbucket Server Email Creating an initial organization Inviting users to Codacy As a last step we recommend that you set up monitoring on your Codacy instance. If you run into any issues while configuring Codacy, be sure to check our troubleshooting guide for more help.", "title": "3. Configuring Codacy"}, {"location": "chart/requirements/", "text": "System requirements # Before installing Codacy Self-hosted you must ensure that you have the following infrastructure correctly provisioned and configured: Git provider Kubernetes or MicroK8s cluster PostgreSQL server The next sections describe in detail how to set up these prerequisites. Git provider # To use Codacy Self-hosted, you must use one or more of our supported Git providers . In particular, if you're using a self-hosted Git provider, make sure that your version is supported by Codacy. Kubernetes or MicroK8s cluster setup # The cluster running Codacy must satisfy the following requirements: The infrastructure hosting the cluster must be provisioned with the hardware and networking requirements described below The orchestration platform managing the cluster must be one of: Kubernetes version 1.22.* to 1.27.* (1.26 recommended) MicroK8s version 1.19.* The NGINX Ingress controller must be installed and correctly set up in the cluster Cluster networking requirements # The cluster must be configured to accept and establish connections on the following ports: Service Protocol/Port Notes Inbound SSH TCP/22 MicroK8s only , to access the infrastructure remotely. Inbound HTTP TCP/80 Allow access to the Codacy website and API endpoints Inbound HTTPS TCP/443 Allow access to the Codacy website and API endpoints Outbound PostgreSQL TCP/5432 Connection to the PostgreSQL DBMS Outbound SMTP TCP/25 Connection to your SMTP server Outbound SMTPS TCP/465 Connection to your SMTP server over TLS/SSL Outbound Docker Hub * Connection to Docker Hub to download the required container images Outbound Git provider * Connection to the ports required by your remote Git provider Cluster hardware requirements # The high-level architecture described in the next section is important in understanding how Codacy uses and allocates hardware resources. Below we also provide guidance on resource provisioning for typical scenarios . For a custom hardware resource recommendation, please contact us at support@codacy.com . Codacy architecture # You can look at Codacy separately as two groups of components: The \"Platform\" contains the UI and other components important to treat and show results The \"Analysis\" is the swarm of workers that run between one and four linters simultaneously, depending on factors such as the number of files or the programming languages used in your projects Since all components are running on a cluster, you can increase the number of pod replicas in every deployment to give you more resilience and throughput, at a cost of increased resource usage. The following is a simplified overview of how to calculate resource allocation for the group of components \"Platform\" and \"Analysis\": Group of components vCPU Memory Platform (1 pod replica per component) 4 8 GB Analysis (1 Analysis Worker pod with up to 4 linters) 5 (per Analysis Worker) 10 GB (per Analysis Worker) Standard cluster provisioning # As described in the section above, Codacy's architecture allows scaling the \"Analysis\" group of components, meaning that the resources needed for Codacy depend mainly on the rate of commits done by your team that Codacy will be analyzing. The resources recommended on the following table are based on our experience and are also the defaults in the values-production.yaml file. You might need to adapt these defaults taking into account your use case. In particular, you should set the value of global.workerManager.workers.config.dedicatedMax to the maximum number of concurrent analysis depending on the available resources and number of replicas per component. Note For MicroK8s clusters we added an extra 1.5 vCPU and 1.5 GB memory to the \"Platform\" to account for the MicroK8s platform itself running on the same machine. Installation type Pod replicas per component Max. concurrent analysis Platform resources Analysis resources ~ Total resources Kubernetes Small Installation 1 2 4 vCPUs 8 GB RAM 10 vCPUs 20 GB RAM 16 vCPUs 32 GB RAM Kubernetes Medium Installation (default) 2 4 8 vCPUs 16 GB RAM 20 vCPUs 40 GB RAM 32 vCPUs 64 GB RAM Kubernetes Big Installation 2+ 10+ 8+ vCPUs 16+ GB RAM 50+ vCPUs 100+ GB RAM 60+ vCPUs 110+ GB RAM MicroK8s Minimum 1 2 5.5 vCPUs 9.5 GB RAM 10 vCPUs 20 GB RAM 16 vCPUs 32 GB RAM MicroK8s Recommended (default) 1+ 2 9.5+ vCPUs 17.5+ GB RAM 10 vCPUs 20 GB RAM 21+ vCPUs 40+ GB RAM The storage requirements recommended on the following table depend mainly on the number of repositories that Codacy will be analyzing and should be used as a guideline to determine your installation requirements. Component Bundled in the chart? Minimum recommended NFS Yes 200 GB RabbitMQ Yes 8 GB Minio Yes 20 GB PostgreSQL No (external DB recommended) 500 GB+ Note Please note that due to the way Codacy works, a small number of pods will run in privileged mode with the CAP_SYS_ADMIN capability. This is required to allow the Worker pods to serve NFS shares to be mounted by the pods running the static code analysis tools. PostgreSQL server setup # Codacy requires a database server to persist data that must satisfy the following requirements: The infrastructure hosting the database server must be provisioned with the hardware requirements described below The DBMS server must be PostgreSQL version 11.20 or version 12.* (12.* recommended) The PostgreSQL server must be configured to accept connections from the cluster The Codacy databases and a dedicated user must be created using the instructions below Important Google, the developer of Kubernetes, doesn't recommend running database servers on your cluster . As such, consider using a managed solution like Amazon RDS or Google Cloud SQL, or running the PostgreSQL server on a dedicated virtual machine. We recommend that you use a managed solution to reduce maintenance and configuration costs of the PostgreSQL server. The main cloud providers all have this service that you can use, for example: Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL-Compatible Edition Azure Database for PostgreSQL Google Cloud SQL for PostgreSQL Digital Ocean Managed Databases PostgreSQL hardware requirements # The following are the minimum specifications recommended for provisioning the PostgreSQL server: vCPUs Memory Storage Max. concurrent connections 4 8 GB 500 GB+ 300 Preparing PostgreSQL for Codacy # Before installing Codacy you must create a set of databases that will be used by Codacy to persist data. We also recommend that you create a dedicated user for Codacy, with access permissions only to the databases that are specific to Codacy: Connect to the PostgreSQL server as a database admin user. For example, using the psql command line client: psql -U postgres -h Create the dedicated user that Codacy will use to connect to PostgreSQL. Make sure that you change the username and password to suit your security needs: CREATE USER codacy WITH PASSWORD 'codacy' ; ALTER ROLE codacy WITH CREATEDB ; Take note of the username and password you define, as you will require them later to configure the connection from Codacy to the PostgreSQL server. Make sure that you can connect to the PostgreSQL database using the newly created user. For example, using the psql command line client: psql -U codacy -d postgres -h Create the databases required by Codacy: CREATE DATABASE accounts WITH OWNER = codacy ; CREATE DATABASE analysis WITH OWNER = codacy ; CREATE DATABASE results WITH OWNER = codacy ; CREATE DATABASE metrics WITH OWNER = codacy ; CREATE DATABASE filestore WITH OWNER = codacy ; CREATE DATABASE jobs WITH OWNER = codacy ; CREATE DATABASE listener WITH OWNER = codacy ; CREATE DATABASE crow WITH OWNER = codacy ;", "title": "System requirements"}, {"location": "chart/requirements/#system-requirements", "text": "Before installing Codacy Self-hosted you must ensure that you have the following infrastructure correctly provisioned and configured: Git provider Kubernetes or MicroK8s cluster PostgreSQL server The next sections describe in detail how to set up these prerequisites.", "title": "System requirements"}, {"location": "chart/requirements/#git-provider", "text": "To use Codacy Self-hosted, you must use one or more of our supported Git providers . In particular, if you're using a self-hosted Git provider, make sure that your version is supported by Codacy.", "title": "Git provider"}, {"location": "chart/requirements/#kubernetes-or-microk8s-cluster-setup", "text": "The cluster running Codacy must satisfy the following requirements: The infrastructure hosting the cluster must be provisioned with the hardware and networking requirements described below The orchestration platform managing the cluster must be one of: Kubernetes version 1.22.* to 1.27.* (1.26 recommended) MicroK8s version 1.19.* The NGINX Ingress controller must be installed and correctly set up in the cluster", "title": "Kubernetes or MicroK8s cluster setup"}, {"location": "chart/requirements/#postgresql-server-setup", "text": "Codacy requires a database server to persist data that must satisfy the following requirements: The infrastructure hosting the database server must be provisioned with the hardware requirements described below The DBMS server must be PostgreSQL version 11.20 or version 12.* (12.* recommended) The PostgreSQL server must be configured to accept connections from the cluster The Codacy databases and a dedicated user must be created using the instructions below Important Google, the developer of Kubernetes, doesn't recommend running database servers on your cluster . As such, consider using a managed solution like Amazon RDS or Google Cloud SQL, or running the PostgreSQL server on a dedicated virtual machine. We recommend that you use a managed solution to reduce maintenance and configuration costs of the PostgreSQL server. The main cloud providers all have this service that you can use, for example: Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL-Compatible Edition Azure Database for PostgreSQL Google Cloud SQL for PostgreSQL Digital Ocean Managed Databases", "title": "PostgreSQL server setup"}, {"location": "chart/configuration/caching/", "text": "Caching # Codacy Self-hosted includes a built-in NFS server provisioner that deploys a shared volume to cache the cloned repository files while they're being analyzed by each tool. However, if you're dealing with big repositories or a high volume of analysis, using an NFS server external to the cluster will improve the performance of the cache. To use your own external NFS server: Edit the file values-production.yaml that you used to install Codacy . Set listener.nfsserverprovisioner.enabled: \"false\" and define the remaining listener.cache.* values as described below: listener : nfsserverprovisioner : enabled : false cache : name : listener-cache path : /data nfs : server : # IP address of the external NFS server path : /var/nfs/data/ # External NFS server directory or file system to be mounted Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml Validate that the repository-listener pod is now using the external NFS server: $ kubectl describe pod -n codacy codacy-listener-<...> [ ... ] Volumes: listener-cache: Type: NFS ( an NFS mount that lasts the lifetime of a pod ) Server: Path: /var/nfs/data/ ReadOnly: false", "title": "Caching"}, {"location": "chart/configuration/caching/#caching", "text": "Codacy Self-hosted includes a built-in NFS server provisioner that deploys a shared volume to cache the cloned repository files while they're being analyzed by each tool. However, if you're dealing with big repositories or a high volume of analysis, using an NFS server external to the cluster will improve the performance of the cache. To use your own external NFS server: Edit the file values-production.yaml that you used to install Codacy . Set listener.nfsserverprovisioner.enabled: \"false\" and define the remaining listener.cache.* values as described below: listener : nfsserverprovisioner : enabled : false cache : name : listener-cache path : /data nfs : server : # IP address of the external NFS server path : /var/nfs/data/ # External NFS server directory or file system to be mounted Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml Validate that the repository-listener pod is now using the external NFS server: $ kubectl describe pod -n codacy codacy-listener-<...> [ ... ] Volumes: listener-cache: Type: NFS ( an NFS mount that lasts the lifetime of a pod ) Server: Path: /var/nfs/data/ ReadOnly: false", "title": "Caching"}, {"location": "chart/configuration/logging/", "text": "Logging # Currently, Codacy Self-hosted supports two types of log configurations: Log level : The severity of the messages that will be shown in logs. Log retention period : The period during which logs will be stored, before being removed by the cleanup job specified in the configuration. The sections below provide instructions on how to configure each logging configuration. Configuring the log level # The log level defines the minimum severity of the events contained in the logs, and affects the necessary storage space in MinIO. Important We recommend that you don't use a log level lower than WARN, as the logs are useful to troubleshoot any issues in your Codacy Self-hosted instance. Codacy supports configuring the log level of the following components: codacy-api engine listener worker-manager Follow these instructions to configure the log level: Edit the value of .config.logLevel in the values-production.yaml file that is used to install Codacy, as shown in the example below. worker-manager : replicaCount : 2 config : logLevel : WARN resources : limits : cpu : 500m memory : 1000Mi requests : cpu : 200m memory : 200Mi The list of supported values for logLevel is shown below. Note that each level also prints the information of the levels higher than it: DEBUG (default): Logs detailed information on the flow through the system. This is the most verbose level . INFO: Logs interesting events such as application startup and shutdown, important events on the flow of the system, or behavior that is skipped for expected reasons. WARN: Logs runtime events that are unexpected, or undesirable, but not necessarily wrong such as the use of deprecated APIs. ERROR: Only logs runtime errors, or unexpected conditions that prevent the expected behavior from happening. This is the least verbose level . Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml Configuring the log retention period # The log retention period is the number of days during which logs will be stored before being removed by the MinIO bucket lifecycle configuration policy that we provide in the template lifecycle-police-job.yaml . Follow these instructions to configure the log retention period: Adjust the retention period of your logs by editing the value of fluentdoperator.expirationDays in the values.yaml file, as shown in the example below. fluentdoperator : enabled : true defaultConfigmap : codacy-fluentd-config bucketName : logs expirationDays : 7 Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "Logging"}, {"location": "chart/configuration/logging/#logging", "text": "Currently, Codacy Self-hosted supports two types of log configurations: Log level : The severity of the messages that will be shown in logs. Log retention period : The period during which logs will be stored, before being removed by the cleanup job specified in the configuration. The sections below provide instructions on how to configure each logging configuration.", "title": "Logging"}, {"location": "chart/configuration/logging/#configuring-the-log-level", "text": "The log level defines the minimum severity of the events contained in the logs, and affects the necessary storage space in MinIO. Important We recommend that you don't use a log level lower than WARN, as the logs are useful to troubleshoot any issues in your Codacy Self-hosted instance. Codacy supports configuring the log level of the following components: codacy-api engine listener worker-manager Follow these instructions to configure the log level: Edit the value of .config.logLevel in the values-production.yaml file that is used to install Codacy, as shown in the example below. worker-manager : replicaCount : 2 config : logLevel : WARN resources : limits : cpu : 500m memory : 1000Mi requests : cpu : 200m memory : 200Mi The list of supported values for logLevel is shown below. Note that each level also prints the information of the levels higher than it: DEBUG (default): Logs detailed information on the flow through the system. This is the most verbose level . INFO: Logs interesting events such as application startup and shutdown, important events on the flow of the system, or behavior that is skipped for expected reasons. WARN: Logs runtime events that are unexpected, or undesirable, but not necessarily wrong such as the use of deprecated APIs. ERROR: Only logs runtime errors, or unexpected conditions that prevent the expected behavior from happening. This is the least verbose level . Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "Configuring the log level"}, {"location": "chart/configuration/logging/#configuring-the-log-retention-period", "text": "The log retention period is the number of days during which logs will be stored before being removed by the MinIO bucket lifecycle configuration policy that we provide in the template lifecycle-police-job.yaml . Follow these instructions to configure the log retention period: Adjust the retention period of your logs by editing the value of fluentdoperator.expirationDays in the values.yaml file, as shown in the example below. fluentdoperator : enabled : true defaultConfigmap : codacy-fluentd-config bucketName : logs expirationDays : 7 Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "Configuring the log retention period"}, {"location": "chart/configuration/monitoring/", "text": "Monitoring # Currently, Codacy Self-hosted supports two monitoring solutions: Crow : A simple, lightweight, and built-in monitoring solution, enabled by default when you install Codacy. Prometheus + Grafana + Loki : A comprehensive third-party monitoring solution, recommended for more advanced usage. The sections below provide instructions on how to set up each monitoring solution. Setting up monitoring using Crow # Crow displays information about the projects that are pending analysis and the jobs currently running on Codacy. Crow is installed alongside Codacy when the Helm chart is deployed to the cluster. By default, you can access Crow as follows: URL: http:///monitoring , where is the hostname of your Codacy instance Username: codacy Password: C0dacy123 We highly recommend that you define a custom password for Crow, if you haven't already done it when installing Codacy: Edit the value of global.crow.config.passwordAuth.password in the values-production.yaml file that you used to install Codacy: global : crow : config : passwordAuth : password : C0dacy123 Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml Setting up monitoring using Grafana, Prometheus, and Loki # Prometheus is an open-source systems monitoring and alerting toolkit. Logs can be collected using Loki , which is a horizontally-scalable, highly-available, multi-tenant log aggregation system. Its data can be visualized with Grafana , a widely used open source analytics and monitoring solution. This solution is considerably more resource demanding than Crow, and is recommended only for more advanced usage. Furthermore, its installation, configuration, and management require a deeper knowledge of Kubernetes as each component must be carefully tweaked to match your specific use case, using as starting point the .yaml values files provided by us. The instructions below cover the basic installation of these monitoring services using the Kube Prometheus Stack . Important If you're using MicroK8s run alias kubectl=microk8s.kubectl . 1. Install custom resources # Add the custom resources required for installing the monitoring bundle in your cluster: kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_alertmanagerconfigs.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_alertmanagers.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_podmonitors.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_probes.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_prometheuses.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_prometheusrules.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_thanosrulers.yaml 2. Installing Loki # Obtain the configuration file for Loki, values-loki.yaml , and install it by running the command below. While the default storage class setting for Loki persistence should suit most use cases, you may need to adjust it to your specific Kubernetes installation. For instance, for MicroK8s use storageClassName: microk8s-hostpath . helm repo add grafana https://grafana.github.io/helm-charts kubectl create namespace monitoring helm upgrade --install --atomic --timeout 600s loki grafana/loki \\ --version 2 .14.1 --namespace monitoring --values values-loki.yaml 3. Installing Promtail # Promtail is an agent that ships the contents of local logs to a Loki instance. Obtain the configuration file for Promtail, values-promtail.yaml , and install it by running the command below. helm upgrade --install --atomic --timeout 600s promtail grafana/promtail \\ --version 2 .2.0 --namespace monitoring --values values-promtail.yaml 4. Installing Prometheus and Grafana # Obtain the configuration file for the Kube Prometheus Stack , values-prometheus-operator.yaml . Then: Edit the Grafana password for the admin user and the hostname for Grafana in the values-prometheus-operator.yaml file. Install the bundle on your cluster by running the command below. helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update helm upgrade --install --atomic --timeout 600s monitoring prometheus-community/kube-prometheus-stack \\ --version 39 .9.0 --namespace monitoring --values values-prometheus-operator.yaml Grafana will be available on the domain you configured in your values-prometheus-operator.yaml file, with Prometheus and Loki configured as datasources. Follow the Kubernetes documentation if you need to access other monitoring services that are now running on your cluster, using the method that best suits your use case. 5. Enable service dashboards # Now that you have Prometheus and Grafana installed you can enable metrics reporting for Codacy components. Create a file named values-monitoring.yaml with the following content: global : metrics : kamon : enabled : true prometheusReporter : enabled : true serviceMonitor : enabled : true grafana : enabled : true Apply this configuration by performing a Helm upgrade. To do so append --values values-monitoring.yaml to the command used to install Codacy : helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-monitoring.yaml", "title": "Monitoring"}, {"location": "chart/configuration/monitoring/#monitoring", "text": "Currently, Codacy Self-hosted supports two monitoring solutions: Crow : A simple, lightweight, and built-in monitoring solution, enabled by default when you install Codacy. Prometheus + Grafana + Loki : A comprehensive third-party monitoring solution, recommended for more advanced usage. The sections below provide instructions on how to set up each monitoring solution.", "title": "Monitoring"}, {"location": "chart/configuration/monitoring/#setting-up-monitoring-using-crow", "text": "Crow displays information about the projects that are pending analysis and the jobs currently running on Codacy. Crow is installed alongside Codacy when the Helm chart is deployed to the cluster. By default, you can access Crow as follows: URL: http:///monitoring , where is the hostname of your Codacy instance Username: codacy Password: C0dacy123 We highly recommend that you define a custom password for Crow, if you haven't already done it when installing Codacy: Edit the value of global.crow.config.passwordAuth.password in the values-production.yaml file that you used to install Codacy: global : crow : config : passwordAuth : password : C0dacy123 Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "Setting up monitoring using Crow"}, {"location": "chart/configuration/monitoring/#setting-up-monitoring-using-grafana-prometheus-and-loki", "text": "Prometheus is an open-source systems monitoring and alerting toolkit. Logs can be collected using Loki , which is a horizontally-scalable, highly-available, multi-tenant log aggregation system. Its data can be visualized with Grafana , a widely used open source analytics and monitoring solution. This solution is considerably more resource demanding than Crow, and is recommended only for more advanced usage. Furthermore, its installation, configuration, and management require a deeper knowledge of Kubernetes as each component must be carefully tweaked to match your specific use case, using as starting point the .yaml values files provided by us. The instructions below cover the basic installation of these monitoring services using the Kube Prometheus Stack . Important If you're using MicroK8s run alias kubectl=microk8s.kubectl .", "title": "Setting up monitoring using Grafana, Prometheus, and Loki"}, {"location": "chart/configuration/integrations/bitbucket-cloud/", "text": "Bitbucket Cloud # Follow the instructions below to set up the Codacy Self-hosted integration with Bitbucket Cloud. Create an OAuth consumer # To integrate Codacy with Bitbucket Cloud, you must register an OAuth consumer for Codacy on Bitbucket. You can create a consumer on any existing individual or team account. To create a consumer, do the following: On Bitbucket, click on your avatar on the bottom left-hand corner and select Bitbucket settings . Select OAuth on the left sidebar and click the button Add consumer . Fill in the fields to create the OAuth consumer: Name: Name of the OAuth consumer. For example, Codacy . Callback URL: Copy the URL below, replacing the HTTP protocol and hostname with the correct values for your Codacy instance. https://codacy.example.com/login/Bitbucket?codacy_skip_ga=1 This is a private consumer: Enable the check box. Add the permissions: Account: Write Team membership: Read Projects: Read Repositories: Admin Pull requests: Write Issues: Write Webhooks: Read and write Click Save, and then click the name of the new OAuth consumer to take note of the generated key and secret. Configure Bitbucket Cloud on Codacy # After creating the OAuth consumer on Bitbucket Cloud, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.bitbucket.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the OAuth consumer: global : bitbucket : enabled : \"true\" login : \"true\" # Show login button for Bitbucket Cloud key : \"\" # OAuth consumer key secret : \"\" # OAuth consumer secret Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use Bitbucket Cloud to authenticate to Codacy.", "title": "Bitbucket Cloud"}, {"location": "chart/configuration/integrations/bitbucket-cloud/#bitbucket-cloud", "text": "Follow the instructions below to set up the Codacy Self-hosted integration with Bitbucket Cloud.", "title": "Bitbucket Cloud"}, {"location": "chart/configuration/integrations/bitbucket-cloud/#create-oauth", "text": "To integrate Codacy with Bitbucket Cloud, you must register an OAuth consumer for Codacy on Bitbucket. You can create a consumer on any existing individual or team account. To create a consumer, do the following: On Bitbucket, click on your avatar on the bottom left-hand corner and select Bitbucket settings . Select OAuth on the left sidebar and click the button Add consumer . Fill in the fields to create the OAuth consumer: Name: Name of the OAuth consumer. For example, Codacy . Callback URL: Copy the URL below, replacing the HTTP protocol and hostname with the correct values for your Codacy instance. https://codacy.example.com/login/Bitbucket?codacy_skip_ga=1 This is a private consumer: Enable the check box. Add the permissions: Account: Write Team membership: Read Projects: Read Repositories: Admin Pull requests: Write Issues: Write Webhooks: Read and write Click Save, and then click the name of the new OAuth consumer to take note of the generated key and secret.", "title": "Create an OAuth consumer"}, {"location": "chart/configuration/integrations/bitbucket-cloud/#configure", "text": "After creating the OAuth consumer on Bitbucket Cloud, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.bitbucket.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the OAuth consumer: global : bitbucket : enabled : \"true\" login : \"true\" # Show login button for Bitbucket Cloud key : \"\" # OAuth consumer key secret : \"\" # OAuth consumer secret Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use Bitbucket Cloud to authenticate to Codacy.", "title": "Configure Bitbucket Cloud on Codacy"}, {"location": "chart/configuration/integrations/bitbucket-server/", "text": "Bitbucket Server # Follow the instructions below to set up the Codacy Self-hosted integration with Bitbucket Server. Create a Bitbucket Server application link # To integrate Codacy with Bitbucket Server, you must create an application link on your Bitbucket Server instance: Create a key pair to sign and validate the requests between Codacy and the Bitbucket Server instance. Run the following command to create the key pair using the RSA algorithm in the PKCS#8 format: bash < ( curl -fsSL https://raw.githubusercontent.com/codacy/chart/master/docs/configuration/integrations/generate-bitbucket-server-secrets.sh ) Store the keys in a safe place for usage in the next steps and as a backup. Open /plugins/servlet/applinks/listApplicationLinks , where is the URL of your Bitbucket Server instance. Create a new application link with the URL of your Codacy instance. Important If you're using Bitbucket Server 7.20 or later you must select the application type Atlassian product while creating the new application link. This forces the integration to use OAuth 1.0 and is necessary to ensure the compatibility between Codacy and older versions of Bitbucket that only supported OAuth 1.0. If Bitbucket Server may warn you that there was no response from the URL you entered. This is expected, and you can click Continue after verifying that the URL is correct. Fill in the fields: Application Name: Name of the application. For example, Codacy . Application Type: Select Generic Application . The remaining fields should be left blank. After creating the new application link, click Edit to add an incoming authentication. Fill in the fields of the incoming authentication: Consumer Key: Enter the consumerKey generated previously. Consumer Name: Name of the consumer. For example, Codacy . Public Key: Enter the consumerPublicKey generated previously. The remaining fields should be left blank. Configure Bitbucket Server on Codacy # After creating the Bitbucket Server application link, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.bitbucketEnterprise.enabled: \"true\" and define the remaining values as described below and with the information obtained when you created the Bitbucket Server application link: bitbucketEnterprise : enabled : \"true\" login : \"true\" # Show login button for Bitbucket Server hostname : \"bitbucket.example.com\" # Hostname of your Bitbucket Server instance protocol : \"https\" # Protocol of your Bitbucket Server instance port : 7990 # Port of your Bitbucket Server instance consumerKey : \"\" # Generated when creating the Bitbucket Server application link consumerPublicKey : \"\" # Generated when creating the Bitbucket Server application link consumerPrivateKey : \"\" # Generated when creating the Bitbucket Server application link contextPath : \"\" # Context path of your Bitbucket Server, if configured Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use Bitbucket Server to authenticate to Codacy.", "title": "Bitbucket Server"}, {"location": "chart/configuration/integrations/bitbucket-server/#bitbucket-server", "text": "Follow the instructions below to set up the Codacy Self-hosted integration with Bitbucket Server.", "title": "Bitbucket Server"}, {"location": "chart/configuration/integrations/bitbucket-server/#create-a-bitbucket-server-application-link", "text": "To integrate Codacy with Bitbucket Server, you must create an application link on your Bitbucket Server instance: Create a key pair to sign and validate the requests between Codacy and the Bitbucket Server instance. Run the following command to create the key pair using the RSA algorithm in the PKCS#8 format: bash < ( curl -fsSL https://raw.githubusercontent.com/codacy/chart/master/docs/configuration/integrations/generate-bitbucket-server-secrets.sh ) Store the keys in a safe place for usage in the next steps and as a backup. Open /plugins/servlet/applinks/listApplicationLinks , where is the URL of your Bitbucket Server instance. Create a new application link with the URL of your Codacy instance. Important If you're using Bitbucket Server 7.20 or later you must select the application type Atlassian product while creating the new application link. This forces the integration to use OAuth 1.0 and is necessary to ensure the compatibility between Codacy and older versions of Bitbucket that only supported OAuth 1.0. If Bitbucket Server may warn you that there was no response from the URL you entered. This is expected, and you can click Continue after verifying that the URL is correct. Fill in the fields: Application Name: Name of the application. For example, Codacy . Application Type: Select Generic Application . The remaining fields should be left blank. After creating the new application link, click Edit to add an incoming authentication. Fill in the fields of the incoming authentication: Consumer Key: Enter the consumerKey generated previously. Consumer Name: Name of the consumer. For example, Codacy . Public Key: Enter the consumerPublicKey generated previously. The remaining fields should be left blank.", "title": "Create a Bitbucket Server application link"}, {"location": "chart/configuration/integrations/bitbucket-server/#configure-bitbucket-server-on-codacy", "text": "After creating the Bitbucket Server application link, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.bitbucketEnterprise.enabled: \"true\" and define the remaining values as described below and with the information obtained when you created the Bitbucket Server application link: bitbucketEnterprise : enabled : \"true\" login : \"true\" # Show login button for Bitbucket Server hostname : \"bitbucket.example.com\" # Hostname of your Bitbucket Server instance protocol : \"https\" # Protocol of your Bitbucket Server instance port : 7990 # Port of your Bitbucket Server instance consumerKey : \"\" # Generated when creating the Bitbucket Server application link consumerPublicKey : \"\" # Generated when creating the Bitbucket Server application link consumerPrivateKey : \"\" # Generated when creating the Bitbucket Server application link contextPath : \"\" # Context path of your Bitbucket Server, if configured Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use Bitbucket Server to authenticate to Codacy.", "title": "Configure Bitbucket Server on Codacy"}, {"location": "chart/configuration/integrations/email/", "text": "SMTP server # Follow the instructions below to set up Codacy Self-hosted to send emails using your SMTP server: Edit the file values-production.yaml that you used to install Codacy . Set global.email.enabled: \"true\" and define the remaining values with the credentials for your SMTP server: email : enabled : \"true\" replyTo : \"notifications@mycompany.com\" # Reply-to field on sent emails smtp : protocol : \"smtp\" # SMTP protocol to use, either smtps or smtp hostname : \"smtp.example.com\" # Hostname of your SMTP server # username: \"\" # Optional username to authenticate on your SMTP server # password: \"\" # Optional password to authenticate on your SMTP server # port: 25 # Optional port of your SMTP server, the default is 25 Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to: Invite new users via email Receive commit and pull request email notifications", "title": "SMTP server"}, {"location": "chart/configuration/integrations/email/#smtp-server", "text": "Follow the instructions below to set up Codacy Self-hosted to send emails using your SMTP server: Edit the file values-production.yaml that you used to install Codacy . Set global.email.enabled: \"true\" and define the remaining values with the credentials for your SMTP server: email : enabled : \"true\" replyTo : \"notifications@mycompany.com\" # Reply-to field on sent emails smtp : protocol : \"smtp\" # SMTP protocol to use, either smtps or smtp hostname : \"smtp.example.com\" # Hostname of your SMTP server # username: \"\" # Optional username to authenticate on your SMTP server # password: \"\" # Optional password to authenticate on your SMTP server # port: 25 # Optional port of your SMTP server, the default is 25 Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to: Invite new users via email Receive commit and pull request email notifications", "title": "SMTP server"}, {"location": "chart/configuration/integrations/github-app-create/", "text": "Creating a GitHub App # You must create and correctly set up a GitHub App to allow Codacy Self-hosted to integrate with GitHub. To create the GitHub App: If you're using GitHub Cloud , open https://github.com/settings/apps/new . If you're using GitHub Enterprise , open https://github.example.com/settings/apps/new , replacing the HTTP protocol and hostname with the correct values for your GitHub Enterprise instance. Configure the new GitHub App using the values listed on the table below, replacing https://codacy.example.com with the correct base URL of your Codacy instance. Field Value GitHub App name Codacy Homepage URL https://codacy.example.com User authorization callback URL https://codacy.example.com Request user authorization (OAuth) during installation Enabled Make sure this option is selected to request that the installing user grants access to their identity during the installation of your Codacy GitHub App. Webhook URL For GitHub Cloud: https://codacy.example.com/2.0/events/gh/organization For GitHub Enterprise: https://codacy.example.com/2.0/events/ghe/organization Repository permissions Administration Read & write Checks Read & write Issues Read & write Metadata Read only Pull requests Read & write Webhooks Read & write Commit statuses Read & write Organization permissions Members Read only Webhooks Read & write User permissions Email addresses Read only Git SSH keys Read & write Where can this GitHub App be installed? Any account Scroll to the bottom of the page, click Generate a private key , and save the .pem file containing the private key. Take note of the following information, as you'll need it to configure Codacy: GitHub App name App ID Client ID Client secret Private key (contents of the .pem file generated in the previous step)", "title": "Creating a GitHub App"}, {"location": "chart/configuration/integrations/github-app-create/#creating-a-github-app", "text": "You must create and correctly set up a GitHub App to allow Codacy Self-hosted to integrate with GitHub. To create the GitHub App: If you're using GitHub Cloud , open https://github.com/settings/apps/new . If you're using GitHub Enterprise , open https://github.example.com/settings/apps/new , replacing the HTTP protocol and hostname with the correct values for your GitHub Enterprise instance. Configure the new GitHub App using the values listed on the table below, replacing https://codacy.example.com with the correct base URL of your Codacy instance. Field Value GitHub App name Codacy Homepage URL https://codacy.example.com User authorization callback URL https://codacy.example.com Request user authorization (OAuth) during installation Enabled Make sure this option is selected to request that the installing user grants access to their identity during the installation of your Codacy GitHub App. Webhook URL For GitHub Cloud: https://codacy.example.com/2.0/events/gh/organization For GitHub Enterprise: https://codacy.example.com/2.0/events/ghe/organization Repository permissions Administration Read & write Checks Read & write Issues Read & write Metadata Read only Pull requests Read & write Webhooks Read & write Commit statuses Read & write Organization permissions Members Read only Webhooks Read & write User permissions Email addresses Read only Git SSH keys Read & write Where can this GitHub App be installed? Any account Scroll to the bottom of the page, click Generate a private key , and save the .pem file containing the private key. Take note of the following information, as you'll need it to configure Codacy: GitHub App name App ID Client ID Client secret Private key (contents of the .pem file generated in the previous step)", "title": "Creating a GitHub App"}, {"location": "chart/configuration/integrations/github-cloud/", "text": "GitHub Cloud # Follow the instructions below to set up the Codacy Self-hosted integration with GitHub Cloud: Follow the instructions on creating a GitHub App . Edit the file values-production.yaml that you used to install Codacy . Set global.github.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitHub App: github : enabled : \"true\" login : \"true\" # Show login button for GitHub Cloud clientId : \"\" # Client ID clientSecret : \"\" # Client secret app : name : \"codacy\" # GitHub App name id : \"1234\" # App ID privateKey : \"\" # Contents of the .pem file without newlines or the BEGIN/END lines Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitHub Cloud to authenticate to Codacy.", "title": "GitHub Cloud"}, {"location": "chart/configuration/integrations/github-cloud/#github-cloud", "text": "Follow the instructions below to set up the Codacy Self-hosted integration with GitHub Cloud: Follow the instructions on creating a GitHub App . Edit the file values-production.yaml that you used to install Codacy . Set global.github.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitHub App: github : enabled : \"true\" login : \"true\" # Show login button for GitHub Cloud clientId : \"\" # Client ID clientSecret : \"\" # Client secret app : name : \"codacy\" # GitHub App name id : \"1234\" # App ID privateKey : \"\" # Contents of the .pem file without newlines or the BEGIN/END lines Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitHub Cloud to authenticate to Codacy.", "title": "GitHub Cloud"}, {"location": "chart/configuration/integrations/github-enterprise/", "text": "GitHub Enterprise # Follow the instructions below to set up the Codacy Self-hosted integration with GitHub Enterprise: Follow the instructions on creating a GitHub App . Edit the file values-production.yaml that you used to install Codacy . Set global.githubEnterprise.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitHub App: githubEnterprise : enabled : \"true\" login : \"true\" # Show login button for GitHub Enterprise hostname : \"github.example.com\" # Hostname of your GitHub Enterprise instance protocol : \"https\" # Protocol of your GitHub Enterprise instance port : 443 # Port of your GitHub Enterprise instance disableSSL : \"false\" # Disable certificate validation isPrivateMode : \"true\" # Status of private mode on your GitHub Enterprise instance clientId : \"\" # GitHub App Client ID clientSecret : \"\" # GitHub App Client secret app : name : \"codacy\" # GitHub App name id : \"1234\" # GitHub App ID privateKey : \"\" # Contents of the .pem file without newlines or the BEGIN/END lines Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitHub Enterprise to authenticate to Codacy.", "title": "GitHub Enterprise"}, {"location": "chart/configuration/integrations/github-enterprise/#github-enterprise", "text": "Follow the instructions below to set up the Codacy Self-hosted integration with GitHub Enterprise: Follow the instructions on creating a GitHub App . Edit the file values-production.yaml that you used to install Codacy . Set global.githubEnterprise.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitHub App: githubEnterprise : enabled : \"true\" login : \"true\" # Show login button for GitHub Enterprise hostname : \"github.example.com\" # Hostname of your GitHub Enterprise instance protocol : \"https\" # Protocol of your GitHub Enterprise instance port : 443 # Port of your GitHub Enterprise instance disableSSL : \"false\" # Disable certificate validation isPrivateMode : \"true\" # Status of private mode on your GitHub Enterprise instance clientId : \"\" # GitHub App Client ID clientSecret : \"\" # GitHub App Client secret app : name : \"codacy\" # GitHub App name id : \"1234\" # GitHub App ID privateKey : \"\" # Contents of the .pem file without newlines or the BEGIN/END lines Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitHub Enterprise to authenticate to Codacy.", "title": "GitHub Enterprise"}, {"location": "chart/configuration/integrations/gitlab-cloud/", "text": "GitLab Cloud # Follow the instructions below to set up the Codacy Self-hosted integration with GitLab Cloud. Create a GitLab application # To integrate Codacy with GitLab Cloud, you must create a GitLab application: Open https://gitlab.com/-/profile/applications . Fill in the fields to register your Codacy instance on GitLab: Name: Name of the application. For example, Codacy . Redirect URI: Copy the URLs below, replacing the HTTP protocol and hostname with the correct values for your Codacy instance. This field is case sensitive. https://codacy.example.com/login/GitLab https://codacy.example.com/add/addProvider/GitLab https://codacy.example.com/add/addService/GitLab https://codacy.example.com/add/addPermissions/GitLab Scopes: Enable the scopes: api read_user read_repository openid Click Save application and take note of the generated Application Id and Secret. Note You can ignore the following error that GitLab may display when you test or save the new GitLab application: This happens because GitLab tests the new application by calling an endpoint that Codacy doesn't implement. Configure GitLab Cloud on Codacy # After creating the GitLab application, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.gitlab.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitLab application: gitlab : enabled : \"true\" login : \"true\" # Show login button for GitLab Cloud clientId : \"\" # Application ID clientSecret : \"\" # Secret Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitLab Cloud to authenticate to Codacy.", "title": "GitLab Cloud"}, {"location": "chart/configuration/integrations/gitlab-cloud/#gitlab-cloud", "text": "Follow the instructions below to set up the Codacy Self-hosted integration with GitLab Cloud.", "title": "GitLab Cloud"}, {"location": "chart/configuration/integrations/gitlab-cloud/#create-application", "text": "To integrate Codacy with GitLab Cloud, you must create a GitLab application: Open https://gitlab.com/-/profile/applications . Fill in the fields to register your Codacy instance on GitLab: Name: Name of the application. For example, Codacy . Redirect URI: Copy the URLs below, replacing the HTTP protocol and hostname with the correct values for your Codacy instance. This field is case sensitive. https://codacy.example.com/login/GitLab https://codacy.example.com/add/addProvider/GitLab https://codacy.example.com/add/addService/GitLab https://codacy.example.com/add/addPermissions/GitLab Scopes: Enable the scopes: api read_user read_repository openid Click Save application and take note of the generated Application Id and Secret. Note You can ignore the following error that GitLab may display when you test or save the new GitLab application: This happens because GitLab tests the new application by calling an endpoint that Codacy doesn't implement.", "title": "Create a GitLab application"}, {"location": "chart/configuration/integrations/gitlab-cloud/#configure", "text": "After creating the GitLab application, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.gitlab.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitLab application: gitlab : enabled : \"true\" login : \"true\" # Show login button for GitLab Cloud clientId : \"\" # Application ID clientSecret : \"\" # Secret Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitLab Cloud to authenticate to Codacy.", "title": "Configure GitLab Cloud on Codacy"}, {"location": "chart/configuration/integrations/gitlab-enterprise/", "text": "GitLab Enterprise # Follow the instructions below to set up the Codacy Self-hosted integration with GitLab Enterprise: Create a GitLab application # To integrate Codacy with GitLab Enterprise, you must create a GitLab application: Open /-/profile/applications as a GitLab admin, where is the URL of your GitLab Enterprise instance. Fill in the fields to register your Codacy instance on GitLab: Name: Name of the application. For example, Codacy . Redirect URI: Copy the URLs below, replacing the HTTP protocol and hostname with the correct values for your Codacy instance. This field is case sensitive. https://codacy.example.com/login/GitLabEnterprise https://codacy.example.com/add/addProvider/GitLabEnterprise https://codacy.example.com/add/addService/GitLabEnterprise https://codacy.example.com/add/addPermissions/GitLabEnterprise Scopes: Enable the scopes: api read_user read_repository openid Click Save application and take note of the generated Application Id and Secret. Note You can ignore the following error that GitLab Enterprise may display when you test or save the new GitLab application: This happens because GitLab Enterprise tests the new application by calling an endpoint that Codacy doesn't implement. Configure GitLab Enterprise on Codacy # After creating the GitLab application, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.gitlabEnterprise.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitLab application: gitlabEnterprise : enabled : \"true\" login : \"true\" # Show login button for GitLab Enterprise hostname : \"gitlab.example.com\" # Hostname of your GitLab Enterprise instance protocol : \"https\" # Protocol of your GitLab Enterprise instance port : 443 # Port of your GitLab Enterprise instance clientId : \"\" # Application ID clientSecret : \"\" # Secret Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitLab Enterprise to authenticate to Codacy. Detect changes to repositories and organizations # Optionally, Codacy can automatically detect the following changes to repositories and organizations on your GitLab Enterprise instance: For repositories: renames, deletes, and visibility changes For organizations: renames, deletes, and access removed To do this, you must configure a System Hook on your GitLab Enterprise instance to notify Codacy of the changes: Open /admin/hooks as a GitLab admin, where is the URL of your GitLab Enterprise instance. Fill in the fields to create the System Hook: URL: The URL of your Codacy instance with the path /2.0/events/gle/organization . For example, http://codacy.example.com/2.0/events/gle/organization Secret Token: Copy the Application Secret from the GitLab application that you created previously, or from the value of clientSecret in the file values-production.yaml that you used to install Codacy. Trigger: Enable the trigger Repository update events SSL verification: Enable the SSL verification. Click Save Changes to save the System Hook.", "title": "GitLab Enterprise"}, {"location": "chart/configuration/integrations/gitlab-enterprise/#gitlab-enterprise", "text": "Follow the instructions below to set up the Codacy Self-hosted integration with GitLab Enterprise:", "title": "GitLab Enterprise"}, {"location": "chart/configuration/integrations/gitlab-enterprise/#create-application", "text": "To integrate Codacy with GitLab Enterprise, you must create a GitLab application: Open /-/profile/applications as a GitLab admin, where is the URL of your GitLab Enterprise instance. Fill in the fields to register your Codacy instance on GitLab: Name: Name of the application. For example, Codacy . Redirect URI: Copy the URLs below, replacing the HTTP protocol and hostname with the correct values for your Codacy instance. This field is case sensitive. https://codacy.example.com/login/GitLabEnterprise https://codacy.example.com/add/addProvider/GitLabEnterprise https://codacy.example.com/add/addService/GitLabEnterprise https://codacy.example.com/add/addPermissions/GitLabEnterprise Scopes: Enable the scopes: api read_user read_repository openid Click Save application and take note of the generated Application Id and Secret. Note You can ignore the following error that GitLab Enterprise may display when you test or save the new GitLab application: This happens because GitLab Enterprise tests the new application by calling an endpoint that Codacy doesn't implement.", "title": "Create a GitLab application"}, {"location": "chart/configuration/integrations/gitlab-enterprise/#configure", "text": "After creating the GitLab application, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.gitlabEnterprise.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitLab application: gitlabEnterprise : enabled : \"true\" login : \"true\" # Show login button for GitLab Enterprise hostname : \"gitlab.example.com\" # Hostname of your GitLab Enterprise instance protocol : \"https\" # Protocol of your GitLab Enterprise instance port : 443 # Port of your GitLab Enterprise instance clientId : \"\" # Application ID clientSecret : \"\" # Secret Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitLab Enterprise to authenticate to Codacy.", "title": "Configure GitLab Enterprise on Codacy"}, {"location": "chart/configuration/integrations/gitlab-enterprise/#detect-changes-to-repositories-and-organizations", "text": "Optionally, Codacy can automatically detect the following changes to repositories and organizations on your GitLab Enterprise instance: For repositories: renames, deletes, and visibility changes For organizations: renames, deletes, and access removed To do this, you must configure a System Hook on your GitLab Enterprise instance to notify Codacy of the changes: Open /admin/hooks as a GitLab admin, where is the URL of your GitLab Enterprise instance. Fill in the fields to create the System Hook: URL: The URL of your Codacy instance with the path /2.0/events/gle/organization . For example, http://codacy.example.com/2.0/events/gle/organization Secret Token: Copy the Application Secret from the GitLab application that you created previously, or from the value of clientSecret in the file values-production.yaml that you used to install Codacy. Trigger: Enable the trigger Repository update events SSL verification: Enable the SSL verification. Click Save Changes to save the System Hook.", "title": "Detect changes to repositories and organizations"}, {"location": "chart/infrastructure/eks-quickstart/", "text": "Creating an Amazon EKS cluster # Follow the instructions below to set up an Amazon EKS cluster from scratch, including the necessary underlying infrastructure, using Terraform. The following diagram is a non-exhaustive overview of what you can expect to have deployed in your AWS account by using this quickstart guide. 1. Prepare your environment # Prepare your environment to set up the Amazon EKS cluster: Make sure that you have the following tools installed on your machine: Git version >= 2.0.0 AWS CLI version 1 Terraform version >= 0.12 Kubectl version >= 1.14 Set up the AWS CLI credentials for your AWS account using the AWS CLI and Terraform documentation as reference. Note that, as stated on the Terraform documentation , if your .aws/credentials are more complex you might need to set AWS_SDK_LOAD_CONFIG=1 for Terraform to work correctly: export AWS_SDK_LOAD_CONFIG = 1 Clone the Codacy chart repository and change to the directory that includes the provided Terraform configuration files: git clone https://github.com/codacy/chart.git cd chart/docs/infrastructure/EKS/ This folder includes the following infrastructure stacks: backend: Optional S3 bucket for storing the Terraform state and a DynamoDB table for state locking main: Amazon EKS cluster, including the setup of all network and node infrastructure to go from zero to a fully functional cluster You must have administration privileges on AWS to deploy (and eventually destroy) this infrastructure. The policy file aws-terraform-minimum-admin-policy.json lists the minimum privileges that are required. 2. Set up the Terraform state storage backend # The backend stores the current and historical state of your infrastructure. Although using the backend is optional, we recommend that you deploy it, particularly if you're planning to use these Terraform templates to make modifications to the cluster in the future: Initialize Terraform and deploy the infrastructure described in the backend/ directory, then follow Terraform's instructions: cd backend/ terraform init && terraform apply This creates an Amazon S3 bucket with a unique name to save the infrastructure state. Take note of the value of state_bucket_name in the output of the command. Edit the main/config.tf file and follow the instructions included in the comments to set the name of the Amazon S3 bucket created above and enable the use of the backend in those infrastructure stacks. 3. Create a vanilla Amazon EKS cluster # Create a cluster that includes all the required network and node setup: Initialize Terraform and deploy the infrastructure described in the main/ directory, then follow Terraform's instructions: cd ../main/ terraform init && terraform apply This process takes around 10 minutes. Consider if you want to tailor the cluster to your needs by customizing the cluster configuration. The cluster configuration (such as the type and number of nodes, network CIDRs, etc.) is exposed as variables in the main/variables.tf file. To customize the defaults of that file we recommend that you use a variable definitions file and set the variables in a file named terraform.tfvars in the directory main/ . The following is an example terraform.tfvars : some_key = \"a_string_value\" another_key = 3 someting_else = true Subsequently running terraform apply loads the variables in the terraform.tfvars file by default: terraform apply Set up the kubeconfig file that stores the information needed by kubectl to connect to the new cluster by default: aws eks update-kubeconfig --name codacy-cluster --alias codacy-cluster Get information about the pods in the cluster to test that the cluster was created and that kubectl can successfully connect to the cluster: kubectl get pods -A 4. Prepare to set up the Ingress Controller # Prepare your infrastructure for the Ingress Controller setup, which is performed later during the installation process: Make sure that your network resources are correctly tagged, and create the following required tags if they are missing: Resource Type Key = Value VPC kubernetes.io/cluster/codacy-cluster = shared Subnet (public) kubernetes.io/cluster/codacy-cluster = shared kubernetes.io/role/elb = 1 Subnet (private) kubernetes.io/cluster/codacy-cluster = shared kubernetes.io/role/internal-elb = 1 For more information refer to the AWS documentation . Add the following chart repositories to Helm: helm repo add stable https://charts.helm.sh/stable helm repo update 5. Install the NGINX Ingress Controller # Install the NGINX Ingress Controller: Download the configuration file values-nginx.yaml for the NGINX Ingress Controller. If you wish to use a private load balancer or restrict the IP range for the provisioned load balancer edit the file and enable the required annotation and/or the corresponding setting where indicated. Install the NGINX Ingress Controller. If you're using Kubernetes version <=1.21 , run: kubectl create namespace codacy helm upgrade --install --namespace codacy --version 1 .39.0 codacy-nginx-ingress stable/nginx-ingress -f values-nginx.yaml If you're using Kubernetes version 1.22 or later , run: kubectl create namespace codacy helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update helm upgrade --install --namespace codacy --version 4.8.3 nginx-ingress ingress-nginx/ingress-nginx -f values-nginx.yaml Uninstalling the Amazon EKS cluster # Warning If you proceed beyond this point you'll permanently delete and break things. Delete the Kubernetes cluster. Run the following command in the main/ directory: terraform destroy This process takes around 10 minutes. Remove the Terraform backend. If you created the Terraform backend with the provided stack you can now safely delete it. The backend is purposely created with extra settings to prevent its accidental destruction. To destroy it cleanly you must first disable these settings by editing the file backend/state_and_lock.tf and following the instructions included in the comments. Afterwards, run the following command in the backend/ directory: terraform apply && terraform destroy Note that you first have to run terraform apply to update the settings, and only then will terraform destroy be able to destroy the backend.", "title": "Creating an Amazon EKS cluster"}, {"location": "chart/infrastructure/eks-quickstart/#creating-an-amazon-eks-cluster", "text": "Follow the instructions below to set up an Amazon EKS cluster from scratch, including the necessary underlying infrastructure, using Terraform. The following diagram is a non-exhaustive overview of what you can expect to have deployed in your AWS account by using this quickstart guide.", "title": "Creating an Amazon EKS cluster"}, {"location": "chart/infrastructure/eks-quickstart/#1-prepare-your-environment", "text": "Prepare your environment to set up the Amazon EKS cluster: Make sure that you have the following tools installed on your machine: Git version >= 2.0.0 AWS CLI version 1 Terraform version >= 0.12 Kubectl version >= 1.14 Set up the AWS CLI credentials for your AWS account using the AWS CLI and Terraform documentation as reference. Note that, as stated on the Terraform documentation , if your .aws/credentials are more complex you might need to set AWS_SDK_LOAD_CONFIG=1 for Terraform to work correctly: export AWS_SDK_LOAD_CONFIG = 1 Clone the Codacy chart repository and change to the directory that includes the provided Terraform configuration files: git clone https://github.com/codacy/chart.git cd chart/docs/infrastructure/EKS/ This folder includes the following infrastructure stacks: backend: Optional S3 bucket for storing the Terraform state and a DynamoDB table for state locking main: Amazon EKS cluster, including the setup of all network and node infrastructure to go from zero to a fully functional cluster You must have administration privileges on AWS to deploy (and eventually destroy) this infrastructure. The policy file aws-terraform-minimum-admin-policy.json lists the minimum privileges that are required.", "title": "1. Prepare your environment"}, {"location": "chart/infrastructure/eks-quickstart/#2-set-up-the-terraform-state-storage-backend", "text": "The backend stores the current and historical state of your infrastructure. Although using the backend is optional, we recommend that you deploy it, particularly if you're planning to use these Terraform templates to make modifications to the cluster in the future: Initialize Terraform and deploy the infrastructure described in the backend/ directory, then follow Terraform's instructions: cd backend/ terraform init && terraform apply This creates an Amazon S3 bucket with a unique name to save the infrastructure state. Take note of the value of state_bucket_name in the output of the command. Edit the main/config.tf file and follow the instructions included in the comments to set the name of the Amazon S3 bucket created above and enable the use of the backend in those infrastructure stacks.", "title": "2. Set up the Terraform state storage backend"}, {"location": "chart/infrastructure/eks-quickstart/#3-create-a-vanilla-amazon-eks-cluster", "text": "Create a cluster that includes all the required network and node setup: Initialize Terraform and deploy the infrastructure described in the main/ directory, then follow Terraform's instructions: cd ../main/ terraform init && terraform apply This process takes around 10 minutes. Consider if you want to tailor the cluster to your needs by customizing the cluster configuration. The cluster configuration (such as the type and number of nodes, network CIDRs, etc.) is exposed as variables in the main/variables.tf file. To customize the defaults of that file we recommend that you use a variable definitions file and set the variables in a file named terraform.tfvars in the directory main/ . The following is an example terraform.tfvars : some_key = \"a_string_value\" another_key = 3 someting_else = true Subsequently running terraform apply loads the variables in the terraform.tfvars file by default: terraform apply Set up the kubeconfig file that stores the information needed by kubectl to connect to the new cluster by default: aws eks update-kubeconfig --name codacy-cluster --alias codacy-cluster Get information about the pods in the cluster to test that the cluster was created and that kubectl can successfully connect to the cluster: kubectl get pods -A", "title": "3. Create a vanilla Amazon EKS cluster"}, {"location": "chart/infrastructure/eks-quickstart/#4-prepare-to-set-up-the-ingress-controller", "text": "Prepare your infrastructure for the Ingress Controller setup, which is performed later during the installation process: Make sure that your network resources are correctly tagged, and create the following required tags if they are missing: Resource Type Key = Value VPC kubernetes.io/cluster/codacy-cluster = shared Subnet (public) kubernetes.io/cluster/codacy-cluster = shared kubernetes.io/role/elb = 1 Subnet (private) kubernetes.io/cluster/codacy-cluster = shared kubernetes.io/role/internal-elb = 1 For more information refer to the AWS documentation . Add the following chart repositories to Helm: helm repo add stable https://charts.helm.sh/stable helm repo update", "title": "4. Prepare to set up the Ingress Controller"}, {"location": "chart/infrastructure/eks-quickstart/#5-install-the-nginx-ingress-controller", "text": "Install the NGINX Ingress Controller: Download the configuration file values-nginx.yaml for the NGINX Ingress Controller. If you wish to use a private load balancer or restrict the IP range for the provisioned load balancer edit the file and enable the required annotation and/or the corresponding setting where indicated. Install the NGINX Ingress Controller. If you're using Kubernetes version <=1.21 , run: kubectl create namespace codacy helm upgrade --install --namespace codacy --version 1 .39.0 codacy-nginx-ingress stable/nginx-ingress -f values-nginx.yaml If you're using Kubernetes version 1.22 or later , run: kubectl create namespace codacy helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update helm upgrade --install --namespace codacy --version 4.8.3 nginx-ingress ingress-nginx/ingress-nginx -f values-nginx.yaml", "title": "5. Install the NGINX Ingress Controller"}, {"location": "chart/infrastructure/eks-quickstart/#uninstalling-the-amazon-eks-cluster", "text": "Warning If you proceed beyond this point you'll permanently delete and break things. Delete the Kubernetes cluster. Run the following command in the main/ directory: terraform destroy This process takes around 10 minutes. Remove the Terraform backend. If you created the Terraform backend with the provided stack you can now safely delete it. The backend is purposely created with extra settings to prevent its accidental destruction. To destroy it cleanly you must first disable these settings by editing the file backend/state_and_lock.tf and following the instructions included in the comments. Afterwards, run the following command in the backend/ directory: terraform apply && terraform destroy Note that you first have to run terraform apply to update the settings, and only then will terraform destroy be able to destroy the backend.", "title": "Uninstalling the Amazon EKS cluster"}, {"location": "chart/infrastructure/microk8s-quickstart/", "text": "Creating a MicroK8s cluster # Follow the instructions below to set up a MicroK8s instance from scratch, including all the necessary dependencies and configurations. MicroK8s is a lightweight, fully conformant, single-package Kubernetes developed by Canonical. The project is publicly available on GitHub . 1. Prepare your environment # Prepare your environment to set up the MicroK8s instance. You will need a machine running Ubuntu Server 20.04 LTS that: Is correctly provisioned with the resources described for MicroK8s in the system requirements Is able to establish a connection to the PostgreSQL instance described in the system requirements Make sure that you have Helm version 3.8.1 installed. The next steps assume that you're starting from a clean install of Ubuntu Server and require that you run commands on a local or remote command line session on the machine. 2. Installing MicroK8s # Install MicroK8s on the machine: Make sure that the package nfs-common is installed: sudo apt update && sudo apt install nfs-common -y Install MicroK8s from the 1.19/stable channel: sudo snap install microk8s --classic --channel = 1 .19/stable sudo usermod -a -G microk8s $USER sudo su - $USER Check that MicroK8s is running: microk8s.status --wait-ready If you're running MicroK8s using a single node, disable high-availability clustering for improved performance: microk8s.disable ha-cluster 3. Configuring MicroK8s # Now that MicroK8s is running on the machine we can proceed to enabling the necessary addons: Configure MicroK8s to allow privileged containers: sudo mkdir -p /var/snap/microk8s/current/args sudo echo \"--allow-privileged=true\" >> /var/snap/microk8s/current/args/kube-apiserver microk8s.status --wait-ready Enable the following MicroK8s addons: microk8s.enable dns microk8s.status --wait-ready microk8s.enable storage microk8s.status --wait-ready microk8s.enable ingress microk8s.status --wait-ready Important Check the output of the commands to make sure that all the addons are enabled correctly. If by chance any of the addons fails to be enabled, re-execute the microk8s.enable command for that addon. Restart MicroK8s and its services to make sure that all configurations are working: microk8s.stop microk8s.start microk8s.status --wait-ready Export your kubeconfig so that Helm knows on which cluster to install the charts: microk8s.config > ~/.kube/config The addons are now enabled and the MicroK8s instance bootstrapped. However, we must wait for some MicroK8s pods to be ready, as failing to do so can result in the pods entering a CrashLoopBackoff state: microk8s.kubectl wait -n kube-system --for = condition = Ready pod -l k8s-app = kube-dns microk8s.kubectl wait -n kube-system --for = condition = Ready pod -l k8s-app = hostpath-provisioner # If the following command fails, you probably installed the wrong MicroK8s version microk8s.kubectl wait --all-namespaces --for = condition = Ready pod -l name = nginx-ingress-microk8s Verify that the MicroK8s configuration was successful: microk8s.status --wait-ready The output of the command should be the following: microk8s is running addons: knative: disabled jaeger: disabled fluentd: disabled gpu: disabled cilium: disabled storage: enabled registry: disabled rbac: disabled ingress: enabled dns: enabled metrics-server: disabled linkerd: disabled prometheus: disabled istio: disabled dashboard: disabled After these steps you have ensured that DNS, HTTP, and NGINX Ingress are enabled and working properly inside the MicroK8s instance. Notes on installing Codacy # You can now follow the generic Codacy installation instructions but please note the following: You must execute all kubectl commands as microk8s.kubectl commands instead. To simplify this, we suggest that you create an alias so that you can run the commands directly as provided on the instructions: alias kubectl = microk8s.kubectl When running the helm upgrade command that installs the Codacy chart, you will be instructed to also use the file values-microk8s.yaml that downsizes some component limits, making it easier to fit Codacy in the lightweight MicroK8s solution.", "title": "Creating a MicroK8s cluster"}, {"location": "chart/infrastructure/microk8s-quickstart/#creating-a-microk8s-cluster", "text": "Follow the instructions below to set up a MicroK8s instance from scratch, including all the necessary dependencies and configurations. MicroK8s is a lightweight, fully conformant, single-package Kubernetes developed by Canonical. The project is publicly available on GitHub .", "title": "Creating a MicroK8s cluster"}, {"location": "chart/infrastructure/microk8s-quickstart/#1-prepare-your-environment", "text": "Prepare your environment to set up the MicroK8s instance. You will need a machine running Ubuntu Server 20.04 LTS that: Is correctly provisioned with the resources described for MicroK8s in the system requirements Is able to establish a connection to the PostgreSQL instance described in the system requirements Make sure that you have Helm version 3.8.1 installed. The next steps assume that you're starting from a clean install of Ubuntu Server and require that you run commands on a local or remote command line session on the machine.", "title": "1. Prepare your environment"}, {"location": "chart/infrastructure/microk8s-quickstart/#2-installing-microk8s", "text": "Install MicroK8s on the machine: Make sure that the package nfs-common is installed: sudo apt update && sudo apt install nfs-common -y Install MicroK8s from the 1.19/stable channel: sudo snap install microk8s --classic --channel = 1 .19/stable sudo usermod -a -G microk8s $USER sudo su - $USER Check that MicroK8s is running: microk8s.status --wait-ready If you're running MicroK8s using a single node, disable high-availability clustering for improved performance: microk8s.disable ha-cluster", "title": "2. Installing MicroK8s"}, {"location": "chart/infrastructure/microk8s-quickstart/#3-configuring-microk8s", "text": "Now that MicroK8s is running on the machine we can proceed to enabling the necessary addons: Configure MicroK8s to allow privileged containers: sudo mkdir -p /var/snap/microk8s/current/args sudo echo \"--allow-privileged=true\" >> /var/snap/microk8s/current/args/kube-apiserver microk8s.status --wait-ready Enable the following MicroK8s addons: microk8s.enable dns microk8s.status --wait-ready microk8s.enable storage microk8s.status --wait-ready microk8s.enable ingress microk8s.status --wait-ready Important Check the output of the commands to make sure that all the addons are enabled correctly. If by chance any of the addons fails to be enabled, re-execute the microk8s.enable command for that addon. Restart MicroK8s and its services to make sure that all configurations are working: microk8s.stop microk8s.start microk8s.status --wait-ready Export your kubeconfig so that Helm knows on which cluster to install the charts: microk8s.config > ~/.kube/config The addons are now enabled and the MicroK8s instance bootstrapped. However, we must wait for some MicroK8s pods to be ready, as failing to do so can result in the pods entering a CrashLoopBackoff state: microk8s.kubectl wait -n kube-system --for = condition = Ready pod -l k8s-app = kube-dns microk8s.kubectl wait -n kube-system --for = condition = Ready pod -l k8s-app = hostpath-provisioner # If the following command fails, you probably installed the wrong MicroK8s version microk8s.kubectl wait --all-namespaces --for = condition = Ready pod -l name = nginx-ingress-microk8s Verify that the MicroK8s configuration was successful: microk8s.status --wait-ready The output of the command should be the following: microk8s is running addons: knative: disabled jaeger: disabled fluentd: disabled gpu: disabled cilium: disabled storage: enabled registry: disabled rbac: disabled ingress: enabled dns: enabled metrics-server: disabled linkerd: disabled prometheus: disabled istio: disabled dashboard: disabled After these steps you have ensured that DNS, HTTP, and NGINX Ingress are enabled and working properly inside the MicroK8s instance.", "title": "3. Configuring MicroK8s"}, {"location": "chart/infrastructure/microk8s-quickstart/#notes-on-installing-codacy", "text": "You can now follow the generic Codacy installation instructions but please note the following: You must execute all kubectl commands as microk8s.kubectl commands instead. To simplify this, we suggest that you create an alias so that you can run the commands directly as provided on the instructions: alias kubectl = microk8s.kubectl When running the helm upgrade command that installs the Codacy chart, you will be instructed to also use the file values-microk8s.yaml that downsizes some component limits, making it easier to fit Codacy in the lightweight MicroK8s solution.", "title": "Notes on installing Codacy"}, {"location": "chart/maintenance/database/", "text": "Database migration guide # Migrating databases between pods is a straightforward process with 3 steps: Dump the databases to a dump file. Apply the dump file. Delete the dump file. You will have to dump all the following databases: accounts analysis filestore jobs metrics results Requirements # The following operations must be executed by a user which has elevated access ( SUPERUSER ) in the Postgres databases. Dumping your current data out of a running Postgres # You will need to know the following: $HOSTNAME - the hostname where the database is located. $DB_USER - the username with privileged access to the database that will perform the dump. $DB - the database that you would like to export. $DB_PASSWORD - the database password. pg_dump # The following command lets you extract a given database into a dump file: PGPASSWORD = $DB_PASSWORD pg_dump -h $SRC_HOSTNAME -p $SRC_HOSTPORT -U $DB_USER --clean -Fc $db > /tmp/ $db .dump This will dump the file with the .dump extension into the /tmp folder. For more information and additional options, please check the official documentation. pg_restore # To restore a database, you can run a pg_restore command to consume the dump file and replicate the data onto Postgres: PGPASSWORD = $DB_PASSWORD pg_restore -h $DEST_HOSTNAME -p $DEST_HOSTPORT -U $DB_USER -j 8 -d $db -n public --clean $db .dump With the custom format from pg_dump (by using -Fc ) we can now invoke pg_restore with multiple parallel jobs. This should make the restoration of the databases quicker, depending on which value you provide for the number of parallel jobs to execute. We provide a value of 8 parallel jobs in the example above ( -j 8 ). Note If you run into any problems while restoring, make sure that you have the database created in that Postgres instance (e.g. before restoring the jobs database the Postgres instance should have an empty database called jobs created there). For more information and additional options, please check the official documentation . Sample script # Assuming you have the same $DB_USER and $DB_PASSWORD , and that you want to migrate all the databases from the same hostname to the same destination hostname, you could migrate your databases with the following sample script: SRC_HOSTNAME = $1 SRC_HOSTPORT = $2 DEST_HOSTNAME = $3 DEST_HOSTPORT = $4 DB_USER = $5 DB_PASSWORD = $6 declare -a dbs =( accounts analysis filestore jobs metrics results ) for db in ${ dbs [@] } do PGPASSWORD = $DB_PASSWORD pg_dump -h $SRC_HOSTNAME -p $SRC_HOSTPORT -U $DB_USER --clean -Fc $db > /tmp/ $db .dump PGPASSWORD = $DB_PASSWORD pg_restore -h $DEST_HOSTNAME -p $DEST_HOSTPORT -U $DB_USER -d $db -n public --clean $db .dump done As an example, you could run the script as follows: migrateDBs.sh postgres\u2013instance1.us-east-1.rds.amazonaws.com 25060 postgres\u2013instance1.eu-west-1.rds.amazonaws.com 25060 super_user secret_password", "title": "Database migration guide"}, {"location": "chart/maintenance/database/#database-migration-guide", "text": "Migrating databases between pods is a straightforward process with 3 steps: Dump the databases to a dump file. Apply the dump file. Delete the dump file. You will have to dump all the following databases: accounts analysis filestore jobs metrics results", "title": "Database migration guide"}, {"location": "chart/maintenance/database/#requirements", "text": "The following operations must be executed by a user which has elevated access ( SUPERUSER ) in the Postgres databases.", "title": "Requirements"}, {"location": "chart/maintenance/database/#dumping-your-current-data-out-of-a-running-postgres", "text": "You will need to know the following: $HOSTNAME - the hostname where the database is located. $DB_USER - the username with privileged access to the database that will perform the dump. $DB - the database that you would like to export. $DB_PASSWORD - the database password.", "title": "Dumping your current data out of a running Postgres"}, {"location": "chart/maintenance/database/#sample-script", "text": "Assuming you have the same $DB_USER and $DB_PASSWORD , and that you want to migrate all the databases from the same hostname to the same destination hostname, you could migrate your databases with the following sample script: SRC_HOSTNAME = $1 SRC_HOSTPORT = $2 DEST_HOSTNAME = $3 DEST_HOSTPORT = $4 DB_USER = $5 DB_PASSWORD = $6 declare -a dbs =( accounts analysis filestore jobs metrics results ) for db in ${ dbs [@] } do PGPASSWORD = $DB_PASSWORD pg_dump -h $SRC_HOSTNAME -p $SRC_HOSTPORT -U $DB_USER --clean -Fc $db > /tmp/ $db .dump PGPASSWORD = $DB_PASSWORD pg_restore -h $DEST_HOSTNAME -p $DEST_HOSTPORT -U $DB_USER -d $db -n public --clean $db .dump done As an example, you could run the script as follows: migrateDBs.sh postgres\u2013instance1.us-east-1.rds.amazonaws.com 25060 postgres\u2013instance1.eu-west-1.rds.amazonaws.com 25060 super_user secret_password", "title": "Sample script"}, {"location": "chart/maintenance/license/", "text": "Updating your Codacy license # Some changes to your Codacy plan require that you update your Codacy Self-hosted license with a new one provided by a Codacy representative: Edit the value of codacy-api.config.license in the values-production.yaml file that you used to install Codacy: codacy-api : config : license : <--- insert your Codacy license here ---> Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml Checking the expiration date of your Codacy license # To check the expiration date of your Codacy license, do the following: Click the Admin link in the top right-hand corner. On the Dashboard page, search for your organization and click the organization identifier to navigate to its details. On the Organization details , check your Plan expiry date .", "title": "Updating your Codacy license"}, {"location": "chart/maintenance/license/#updating-your-codacy-license", "text": "Some changes to your Codacy plan require that you update your Codacy Self-hosted license with a new one provided by a Codacy representative: Edit the value of codacy-api.config.license in the values-production.yaml file that you used to install Codacy: codacy-api : config : license : <--- insert your Codacy license here ---> Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "Updating your Codacy license"}, {"location": "chart/maintenance/license/#checking-the-expiration-date-of-your-codacy-license", "text": "To check the expiration date of your Codacy license, do the following: Click the Admin link in the top right-hand corner. On the Dashboard page, search for your organization and click the organization identifier to navigate to its details. On the Organization details , check your Plan expiry date .", "title": "Checking the expiration date of your Codacy license"}, {"location": "chart/maintenance/uninstall/", "text": "Uninstalling Codacy # To ensure a clean removal you should uninstall Codacy Self-hosted before destroying the cluster. To do so run: helm -n codacy uninstall codacy kubectl -n codacy delete --all pod & kubectl -n codacy delete --all pvc & kubectl -n codacy delete --all job & sleep 5 kubectl -n codacy patch pvc -p '{\"metadata\":{\"finalizers\":null}}' $( kubectl -n codacy get pvc -o jsonpath = '{.items[*].metadata.name}' ) sleep 5 kubectl -n codacy delete pod $( kubectl -n codacy get pod -o jsonpath = '{.items[*].metadata.name}' ) --force --grace-period = 0 kubectl -n codacy get pod & kubectl -n codacy get pvc & kubectl -n codacy get job & Note that the deletion of pvc s in the above command has to run in the background due to a cyclic dependency in one of the components. If you're unsure of the effects of these commands please run each of the bash subcommands and validate their output: echo \"PVCs to delete:\" kubectl get pvc -n codacy -o jsonpath = '{.items[*].metadata.name}' echo \"PODS to delete:\" kubectl get pods -n codacy -o jsonpath = '{.items[*].metadata.name}'", "title": "Uninstalling Codacy"}, {"location": "chart/maintenance/uninstall/#uninstalling-codacy", "text": "To ensure a clean removal you should uninstall Codacy Self-hosted before destroying the cluster. To do so run: helm -n codacy uninstall codacy kubectl -n codacy delete --all pod & kubectl -n codacy delete --all pvc & kubectl -n codacy delete --all job & sleep 5 kubectl -n codacy patch pvc -p '{\"metadata\":{\"finalizers\":null}}' $( kubectl -n codacy get pvc -o jsonpath = '{.items[*].metadata.name}' ) sleep 5 kubectl -n codacy delete pod $( kubectl -n codacy get pod -o jsonpath = '{.items[*].metadata.name}' ) --force --grace-period = 0 kubectl -n codacy get pod & kubectl -n codacy get pvc & kubectl -n codacy get job & Note that the deletion of pvc s in the above command has to run in the background due to a cyclic dependency in one of the components. If you're unsure of the effects of these commands please run each of the bash subcommands and validate their output: echo \"PVCs to delete:\" kubectl get pvc -n codacy -o jsonpath = '{.items[*].metadata.name}' echo \"PODS to delete:\" kubectl get pods -n codacy -o jsonpath = '{.items[*].metadata.name}'", "title": "Uninstalling Codacy"}, {"location": "chart/maintenance/upgrade/", "text": "Upgrading Codacy # To upgrade Codacy Self-hosted to the latest stable version: Check the release notes for all Codacy Self-hosted versions between your current version and the most recent version for breaking changes and follow the instructions provided carefully. Warning Failing to follow the steps to deal with breaking changes can cause the upgrade to fail or cause problems while Codacy is running. In particular, Codacy Self-hosted v5.0.0 drops the support for legacy manual organizations . Tip To see the version of your Codacy Self-hosted instance click your avatar on the top right-hand corner of any Codacy page: Store all your currently defined configuration values in a file: helm get values codacy \\ --namespace codacy \\ --output yaml > codacy.yaml Note If you installed Codacy on a Kubernetes namespace different from codacy , make sure that you adjust the namespace when executing the commands in this page. Review the values stored in the file codacy.yaml , making any changes if necessary. Perform the upgrade using the values stored in the file: helm repo update helm upgrade codacy codacy-stable/codacy \\ --version 14 .0.0 \\ --namespace codacy \\ --values codacy.yaml Update your Codacy command-line tools to the versions with the Git tag self-hosted-14.0.0 : Codacy Analysis CLI Codacy Coverage Reporter", "title": "Upgrading Codacy"}, {"location": "chart/maintenance/upgrade/#upgrading-codacy", "text": "To upgrade Codacy Self-hosted to the latest stable version: Check the release notes for all Codacy Self-hosted versions between your current version and the most recent version for breaking changes and follow the instructions provided carefully. Warning Failing to follow the steps to deal with breaking changes can cause the upgrade to fail or cause problems while Codacy is running. In particular, Codacy Self-hosted v5.0.0 drops the support for legacy manual organizations . Tip To see the version of your Codacy Self-hosted instance click your avatar on the top right-hand corner of any Codacy page: Store all your currently defined configuration values in a file: helm get values codacy \\ --namespace codacy \\ --output yaml > codacy.yaml Note If you installed Codacy on a Kubernetes namespace different from codacy , make sure that you adjust the namespace when executing the commands in this page. Review the values stored in the file codacy.yaml , making any changes if necessary. Perform the upgrade using the values stored in the file: helm repo update helm upgrade codacy codacy-stable/codacy \\ --version 14 .0.0 \\ --namespace codacy \\ --values codacy.yaml Update your Codacy command-line tools to the versions with the Git tag self-hosted-14.0.0 : Codacy Analysis CLI Codacy Coverage Reporter", "title": "Upgrading Codacy"}, {"location": "chart/troubleshoot/k8s-cheatsheet/", "text": "Kubernetes cheatsheet # Debugging using events # Important Always check the pods and deployment versions in the namespace to make sure you aren't debugging an issue in a version that's not the one you would expect Events are a great way to understand what's going on under the hood in a Kubernetes cluster. By looking at them you can see if probes are failing, and other important signals from your cluster. Get events for the whole namespace: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp Get error events: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp --field-selector type = Error Get warning events: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp --field-selector type = Warning Get events from a specific pod: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp --field-selector involvedObject.name = Helm # Check all the previous releases in your namespace: helm -n codacy history codacy Rollback to a specific revision: helm -n codacy rollback codacy Edit configmap # kubectl get configmaps and kubectl edit configmap Restart deployment of daemonset # daemonsets # kubectl get daemonsets and kubectl rollout restart daemonset/ deployment # kubectl get deployment and kubectl rollout restart deployment/ and kubectl rollout status deployment/ -w Read logs # daemonset with multiple containers # kubectl logs daemonset/ -f service # kubectl get svc and kubectl logs -l $( kubectl get svc/ -o = json | jq \".spec.selector\" | jq -r 'to_entries|map(\"\\(.key)=\\(.value|tostring)\")|.[]' | sed -e 'H;${x;s/\\n/,/g;s/^,//;p;};d' ) -f Open shell inside container # kubectl exec -it daemonset/ -c sh or kubectl exec -it deployment/ sh MicroK8s # Session Manager SSH # When using AWS Session Manager, to connect to the instance where you installed microk8s, since the CLI is very limited you will benefit from using these aliases: alias kubectl = 'sudo microk8s.kubectl -n ' alias helm = 'sudo helm'", "title": "Kubernetes cheatsheet"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#kubernetes-cheatsheet", "text": "", "title": "Kubernetes cheatsheet"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#debugging-using-events", "text": "Important Always check the pods and deployment versions in the namespace to make sure you aren't debugging an issue in a version that's not the one you would expect Events are a great way to understand what's going on under the hood in a Kubernetes cluster. By looking at them you can see if probes are failing, and other important signals from your cluster. Get events for the whole namespace: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp Get error events: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp --field-selector type = Error Get warning events: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp --field-selector type = Warning Get events from a specific pod: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp --field-selector involvedObject.name = ", "title": "Debugging using events"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#helm", "text": "Check all the previous releases in your namespace: helm -n codacy history codacy Rollback to a specific revision: helm -n codacy rollback codacy ", "title": "Helm"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#edit-configmap", "text": "kubectl get configmaps and kubectl edit configmap ", "title": "Edit configmap"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#restart-deployment-of-daemonset", "text": "", "title": "Restart deployment of daemonset"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#read-logs", "text": "", "title": "Read logs"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#open-shell-inside-container", "text": "kubectl exec -it daemonset/ -c sh or kubectl exec -it deployment/ sh", "title": "Open shell inside container"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#microk8s", "text": "", "title": "MicroK8s"}, {"location": "chart/troubleshoot/logs-collect/", "text": "Collecting logs for Support # To help troubleshoot issues, obtain the logs from your Codacy Self-hosted instance and send them to Codacy's Support: Run the following command on a machine with network access to the Codacy cluster, replacing with the namespace in which Codacy was installed: bash < ( curl -fsSL https://raw.githubusercontent.com/codacy/chart/master/docs/troubleshoot/extract-codacy-logs.sh ) \\ -n This will download the logs of the last 7 days as an archive file with the name codacy_logs_.zip . Tip You can also download the script extract-codacy-logs.sh to run it manually. Send the compressed logs to Codacy's support team at support@codacy.com for analysis. Note If the file is too big, please upload the file to either a cloud storage service such as Google Drive or to a file transfer service such as WeTransfer and send us the link to the file instead. Alternatively, to reduce the size of the compressed archive file, retrieve logs for a smaller number of days by replacing with a number between 1 and 7: bash < ( curl -fsSL https://raw.githubusercontent.com/codacy/chart/master/docs/troubleshoot/extract-codacy-logs.sh ) \\ -n -d ", "title": "Collecting logs for Support"}, {"location": "chart/troubleshoot/logs-collect/#collecting-logs-for-support", "text": "To help troubleshoot issues, obtain the logs from your Codacy Self-hosted instance and send them to Codacy's Support: Run the following command on a machine with network access to the Codacy cluster, replacing with the namespace in which Codacy was installed: bash < ( curl -fsSL https://raw.githubusercontent.com/codacy/chart/master/docs/troubleshoot/extract-codacy-logs.sh ) \\ -n This will download the logs of the last 7 days as an archive file with the name codacy_logs_.zip . Tip You can also download the script extract-codacy-logs.sh to run it manually. Send the compressed logs to Codacy's support team at support@codacy.com for analysis. Note If the file is too big, please upload the file to either a cloud storage service such as Google Drive or to a file transfer service such as WeTransfer and send us the link to the file instead. Alternatively, to reduce the size of the compressed archive file, retrieve logs for a smaller number of days by replacing with a number between 1 and 7: bash < ( curl -fsSL https://raw.githubusercontent.com/codacy/chart/master/docs/troubleshoot/extract-codacy-logs.sh ) \\ -n -d ", "title": "Collecting logs for Support"}, {"location": "chart/troubleshoot/troubleshoot/", "text": "Troubleshooting Codacy Self-hosted # This page includes information to help you troubleshoot issues that you may come across while installing, configuring, and operating Codacy Self-hosted. If the information provided on this page isn't enough to solve your issue, contact support@codacy.com providing: The description of the issue All the information that you were able to obtain while following these troubleshooting instructions The collected logs of your Codacy instance The version of your Codacy instance Tip To see the version of your Codacy Self-hosted instance click your avatar on the top right-hand corner of any Codacy page: Git provider integrations # The following sections help you troubleshoot the integration of Codacy with your Git provider. GitHub Cloud and GitHub Enterprise authentication # 404 error # While trying to authenticate on GitHub you get the following error message: This might mean that there is a mismatch in the Client ID that Codacy is using to authenticate on GitHub. To solve this issue: Make sure that the value of clientId in your values-production.yaml file is the same as the Client ID of the GitHub App that you created If the values were different, update your configuration and re-execute the helm upgrade command as described for GitHub Cloud or GitHub Enterprise If the error persists: Take note of the parameter client_id in the URL of the GitHub error page (for example, Iv1.0000000000000000 ) Check if the value of the parameter matches the value of the Client ID of your GitHub App GitLab Cloud and GitLab Enterprise authentication # Invalid redirect URI # While trying to authenticate on GitLab you get the following error message: This might mean that the redirect URIs are not correct in the GitLab application that Codacy is using to authenticate on GitLab. To solve this issue: Open the GitLab application that you created on GitLab Cloud or GitLab Enterprise Make sure that all the redirect URIs have the correct protocol for the Codacy instance endpoints, either http:// or https:// Make sure that all the redirect URIs have the full path with the correct case, since the field is case-sensitive If the error persists: Take note of the parameter redirect_uri in the URL of the GitLab error page (for example, https%3A%2F%2Fcodacy.example.com%2Flogin%2FGitLab or https%3A%2F%2Fcodacy.example.com%2Flogin%2FGitLabEnterprise ) Decode the value of the parameter using a tool such as urldecoder.com (for example, https://codacy.example.com/login/GitLab or https://codacy.example.com/login/GitLabEnterprise ) Check if the decoded value matches one of the redirect URIs of your GitLab application Unknown client # While trying to authenticate on GitLab you get the following error message: This might mean that there is a mismatch in the Application ID that Codacy is using to authenticate on GitLab. To solve this issue: Make sure that the value of clientId in your values-production.yaml file is the same as the Application ID of the GitLab Cloud or GitLab Enterprise application that you created If the values were different, update your configuration and re-execute the helm upgrade command as described for GitLab Cloud or GitLab Enterprise If the error persists: Take note of the parameter client_id in the URL of the GitLab error page (for example, cca35a2a1f9b9b516ac927d82947bd5149b0e57e922c9e5564ac092ea16a3ccd ) Check if the value of the parameter matches the value of the Application ID of your GitLab application Bitbucket Cloud authentication # Invalid client_id # While trying to authenticate on Bitbucket Cloud you get the following error message: This might mean that there is a mismatch in the OAuth consumer Client ID that Codacy is using to authenticate on Bitbucket Cloud. To solve this issue: Make sure that the value of key in your values-production.yaml file is the same as the Key of the Bitbucket OAuth consumer that you created If the values were different, update your configuration and re-execute the helm upgrade command as described for Bitbucket Cloud If the error persists: Take note of the parameter client_id in the URL of the Bitbucket Cloud error page (for example, r8QJDkkxj8unYfg4Bd ) Check if the value of the parameter matches the value of the Client ID of your Bitbucket OAuth consumer Accessing the RabbitMQ dashboard # We use RabbitMQ for the internal message queue between our components. If you need to access the RabbitMQ dashboard: Create a port-forward from the rabbitmq pod to your local machine, replacing with the namespace in which Codacy was installed: kubectl port-forward codacy-rabbitmq-ha-0 15672 :15672 --namespace = Important If you're using MicroK8s use microk8s.kubectl instead of kubectl . Access the RabbitMQ dashboard on the address localhost:15672 , and log in with the configured RabbitMQ credentials. The default RabbitMQ credentials are the following: Username: rabbitmq-codacy Password: rabbitmq-codacy Missing new tools # If the Code patterns page of your repositories doesn't list a new tool that was included in a new Codacy version, force the list of available tools to refresh by running the following command on any codacy-engine-* pod: curl -X POST localhost:9000/api/v1/engine/initialize Upgrade failed: cannot patch \"codacy-minio\" # If you download and use an updated values-production.yaml file while upgrading to Codacy Self-hosted 9.0.0 , you'll get the following error: Error: UPGRADE FAILED: cannot patch \"codacy-minio\" with kind PersistentVolumeClaim: persistentvolumeclaims \"codacy-minio\" is forbidden: only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize This happens because we updated the MinIO PVC size . As a workaround, you can either: Reset the PVC size back to the original value of 20Gi on your values.yaml file: minio : fullnameOverride : codacy-minio persistence : size : 20Gi Uninstall your current version of Codacy and reinstall Codacy Self-hosted 9.0.0 directly. Your data won't be impacted by the uninstall since it's stored on the database.", "title": "Troubleshooting Codacy Self-hosted"}, {"location": "chart/troubleshoot/troubleshoot/#troubleshooting-codacy-self-hosted", "text": "This page includes information to help you troubleshoot issues that you may come across while installing, configuring, and operating Codacy Self-hosted. If the information provided on this page isn't enough to solve your issue, contact support@codacy.com providing: The description of the issue All the information that you were able to obtain while following these troubleshooting instructions The collected logs of your Codacy instance The version of your Codacy instance Tip To see the version of your Codacy Self-hosted instance click your avatar on the top right-hand corner of any Codacy page:", "title": "Troubleshooting Codacy Self-hosted"}, {"location": "chart/troubleshoot/troubleshoot/#git-provider-integrations", "text": "The following sections help you troubleshoot the integration of Codacy with your Git provider.", "title": "Git provider integrations"}, {"location": "chart/troubleshoot/troubleshoot/#accessing-the-rabbitmq-dashboard", "text": "We use RabbitMQ for the internal message queue between our components. If you need to access the RabbitMQ dashboard: Create a port-forward from the rabbitmq pod to your local machine, replacing with the namespace in which Codacy was installed: kubectl port-forward codacy-rabbitmq-ha-0 15672 :15672 --namespace = Important If you're using MicroK8s use microk8s.kubectl instead of kubectl . Access the RabbitMQ dashboard on the address localhost:15672 , and log in with the configured RabbitMQ credentials. The default RabbitMQ credentials are the following: Username: rabbitmq-codacy Password: rabbitmq-codacy", "title": "Accessing the RabbitMQ dashboard"}, {"location": "chart/troubleshoot/troubleshoot/#missing-new-tools", "text": "If the Code patterns page of your repositories doesn't list a new tool that was included in a new Codacy version, force the list of available tools to refresh by running the following command on any codacy-engine-* pod: curl -X POST localhost:9000/api/v1/engine/initialize", "title": "Missing new tools"}, {"location": "chart/troubleshoot/troubleshoot/#upgrade-failed-cannot-patch-codacy-minio", "text": "If you download and use an updated values-production.yaml file while upgrading to Codacy Self-hosted 9.0.0 , you'll get the following error: Error: UPGRADE FAILED: cannot patch \"codacy-minio\" with kind PersistentVolumeClaim: persistentvolumeclaims \"codacy-minio\" is forbidden: only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize This happens because we updated the MinIO PVC size . As a workaround, you can either: Reset the PVC size back to the original value of 20Gi on your values.yaml file: minio : fullnameOverride : codacy-minio persistence : size : 20Gi Uninstall your current version of Codacy and reinstall Codacy Self-hosted 9.0.0 directly. Your data won't be impacted by the uninstall since it's stored on the database.", "title": "Upgrade failed: cannot patch \"codacy-minio\""}, {"location": "codacy-api/api-tokens/", "text": "API tokens # Codacy provides account and repository -level API tokens that allow you to: Upload coverage data to Codacy Upload to Codacy the results of running client-side analysis tools Authenticate when using the Codacy API The sections below provide details about the two types of API tokens and instructions on how to generate and revoke them. Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. Generating and revoking account API tokens # Account API tokens are defined at the Codacy user account level . Each account API token authorizes access to the same organizations, repositories, and operations as the roles and permissions of the owner of the account . Important If you're using an account API token to upload coverage be sure to check the roles that your Git provider account must have to authorize uploading coverage to Codacy. Use a dedicated service account to integrate Codacy with your repositories. This prevents disruption of service if the user who created an account API token loses access to the repositories, which may happen when a user leaves the team or the organization. You can create new account API tokens programmatically using the Codacy API or using the Codacy UI: Open your account, tab Access management . Click the button Create API token under Account API tokens . Tip You can create multiple account API tokens. This can be useful to have a more flexible control by revoking only a specific token. To revoke an account API token, click the \"X\" next to the token. After this, all applications or services using that token to access the Codacy API will fail to authenticate and will receive the reply {\"error\":\"not found\"} . Generating and revoking repository API tokens # Repository API tokens are defined on individual repositories . Each repository API token only authorizes access to the corresponding repository. You can create new repository API tokens programmatically using the Codacy API or using the Codacy UI: Open your repository Settings , tab Integrations . Click the button Create API token under Repository API tokens . Tip You can create multiple (up to 100) API tokens per repository. This can be useful to have a more flexible control by revoking only a specific token. To revoke a repository API token, click the X next to the token. After this, all applications or services using that token to access the Codacy API will fail to authenticate and will receive the reply {\"error\":\"not found\"} . See also # Adding coverage to your repository Client-side tools Creating repository API tokens programmatically", "title": "API tokens"}, {"location": "codacy-api/api-tokens/#api-tokens", "text": "Codacy provides account and repository -level API tokens that allow you to: Upload coverage data to Codacy Upload to Codacy the results of running client-side analysis tools Authenticate when using the Codacy API The sections below provide details about the two types of API tokens and instructions on how to generate and revoke them. Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this.", "title": "API tokens"}, {"location": "codacy-api/api-tokens/#account-api-tokens", "text": "Account API tokens are defined at the Codacy user account level . Each account API token authorizes access to the same organizations, repositories, and operations as the roles and permissions of the owner of the account . Important If you're using an account API token to upload coverage be sure to check the roles that your Git provider account must have to authorize uploading coverage to Codacy. Use a dedicated service account to integrate Codacy with your repositories. This prevents disruption of service if the user who created an account API token loses access to the repositories, which may happen when a user leaves the team or the organization. You can create new account API tokens programmatically using the Codacy API or using the Codacy UI: Open your account, tab Access management . Click the button Create API token under Account API tokens . Tip You can create multiple account API tokens. This can be useful to have a more flexible control by revoking only a specific token. To revoke an account API token, click the \"X\" next to the token. After this, all applications or services using that token to access the Codacy API will fail to authenticate and will receive the reply {\"error\":\"not found\"} .", "title": "Generating and revoking account API tokens"}, {"location": "codacy-api/api-tokens/#repository-api-tokens", "text": "Repository API tokens are defined on individual repositories . Each repository API token only authorizes access to the corresponding repository. You can create new repository API tokens programmatically using the Codacy API or using the Codacy UI: Open your repository Settings , tab Integrations . Click the button Create API token under Repository API tokens . Tip You can create multiple (up to 100) API tokens per repository. This can be useful to have a more flexible control by revoking only a specific token. To revoke a repository API token, click the X next to the token. After this, all applications or services using that token to access the Codacy API will fail to authenticate and will receive the reply {\"error\":\"not found\"} .", "title": "Generating and revoking repository API tokens"}, {"location": "codacy-api/api-tokens/#see-also", "text": "Adding coverage to your repository Client-side tools Creating repository API tokens programmatically", "title": "See also"}, {"location": "codacy-api/using-the-codacy-api/", "text": "Using the Codacy API # The Codacy API allows you to programmatically retrieve and analyze data from Codacy and perform a few configuration changes. Codacy supports two API versions but we strongly recommend using the new API v3 when possible since it's the version being actively developed. Import the OpenAPI 2.0 definition provided below into your development tools to help bootstrap your integration with Codacy. API v3 (recommended) API v2 Endpoint documentation https://api.codacy.com/api/api-docs https://api.codacy.com/api-docs OpenAPI 2.0 definition https://api.codacy.com/api/api-docs/swagger.yaml - Base URL https://api.codacy.com/api/v3 https://api.codacy.com/ Overview Use the new endpoints to access and manipulate the following resources, among others: Analysis details, issue and ignored issue details, repository quality settings Account details and API token management Organization details and join request management People management Repository management and file details Tool and code pattern details Use the legacy endpoints to access and manipulate the following resources: Commit code quality details and deltas Project details and configurations, file code quality and issue details Important If you're using Codacy Self-hosted you must use your own Codacy instance domain name in the API URLs to access the endpoint documentation matching your Codacy Self-hosted version and to call the endpoints on your Codacy instance. For example, use the following URLs for the API v3 endpoint documentation and endpoints: https:///api/api-docs https:///api/v3 Authenticating requests # Most API endpoints require that you authenticate using an API token. After obtaining the necessary tokens , include them in your request headers using the format api-token: or project-token: . Note Currently, all API v3 endpoints that require authentication must use account API tokens , while the API v2 endpoints require either account or repository API tokens . Performing GET requests for public repositories doesn't require authentication. For example, to make a request to an API v3 endpoint that requires an account API token: curl -X GET 'https://api.codacy.com/api/v3/user/organizations/gh' \\ -H 'api-token: ' Or to make a request to an API v2 endpoint that requires a repository API token: curl -X GET 'https://api.codacy.com/2.0/commit/da275c14ffab6e402dcc6009828067ffa44b7ee0' \\ -H 'project-token: ' Using parameters in requests # Most API endpoints require that you specify parameters. For GET requests , specify parameters directly as path segments of the endpoint URLs. Some endpoints also accept optional query string parameters. For example, to call the endpoint getRepositoryWithAnalysis with the parameters: provider: gh remoteOrganizationName: codacy repositoryName: docs branch (query string): api-overview curl -X GET 'https://app.codacy.com/api/v3/analysis/organizations/gh/codacy/repositories/docs?branch=api-overview' \\ -H 'api-token: ' For POST , PATCH , and DELETE requests , besides the parameters included in the URL you may also need to include a JSON body. For example, to call the endpoint searchRepositoryIssues specifying the issue levels Error and Warning in the body: curl -X POST 'https://app.codacy.com/api/v3/analysis/organizations/gh/codacy/repositories/docs/issues/search' \\ -H 'api-token: ' \\ -H 'Content-Type: application/json' \\ -d '{\"levels\": [\"Error\", \"Warning\"]}' Using pagination # Endpoints that return lists containing a potential large number of results use cursor-based pagination to return the results in small batches. These endpoints return the results together with a pagination object: If the pagination object includes a cursor , obtain the next page of results by calling the endpoint again using the cursor from the previous response as a query string parameter If the pagination object doesn't include a cursor , the endpoint returned the last page of results Use the query string parameter limit to configure the number of results that the endpoint returns in each page. The maximum limit is 1000 and the default is 100 The total is the total number of results that the endpoint can return Note To make sure that you receive all results when calling an endpoint with pagination, repeat the process above until the response doesn't include the cursor to obtain another page of results. For example, the following command requests the first 10 repositories in the Codacy GitHub organization: curl -X GET 'https://app.codacy.com/api/v3/organizations/gh/codacy/repositories?limit=10' -H 'api-token: ' The response includes the first 10 results, as well as the cursor to obtain the next page of results: { \"data\" : [ ... ], \"pagination\" : { \"cursor\" : \"codacy_2\" , \"limit\" : 10 , \"total\" : 156 } } To obtain the next page of results, it's necessary to include the cursor from the previous page as a parameter: curl -X GET 'https://app.codacy.com/api/v3/organizations/gh/codacy/repositories?limit=10&cursor=codacy_2' -H 'api-token: ' If you continue requesting more pages the endpoint will eventually return a pagination object that doesn't include a cursor . This means that you've reached the last page of results: { \"data\" : [ ... ], \"pagination\" : { \"limit\" : 10 , \"total\" : 156 } } Request rate limit # On Codacy Cloud the number of requests that you can perform to the Codacy API is rate limited to help us provide a reliable service: The limit is 2500 requests per 5 minutes and per source IP address When a request is rate limited, Codacy responds with an HTTP 503 or 504 error code and you should wait before attempting the request again Although it's possible for you to perform short bursts of requests to the Codacy API, you should always use a delay between requests to ensure that your API client doesn't hit the rate limits. The request rate limit doesn't apply to Codacy Self-hosted.", "title": "Using the Codacy API"}, {"location": "codacy-api/using-the-codacy-api/#using-the-codacy-api", "text": "The Codacy API allows you to programmatically retrieve and analyze data from Codacy and perform a few configuration changes. Codacy supports two API versions but we strongly recommend using the new API v3 when possible since it's the version being actively developed. Import the OpenAPI 2.0 definition provided below into your development tools to help bootstrap your integration with Codacy. API v3 (recommended) API v2 Endpoint documentation https://api.codacy.com/api/api-docs https://api.codacy.com/api-docs OpenAPI 2.0 definition https://api.codacy.com/api/api-docs/swagger.yaml - Base URL https://api.codacy.com/api/v3 https://api.codacy.com/ Overview Use the new endpoints to access and manipulate the following resources, among others: Analysis details, issue and ignored issue details, repository quality settings Account details and API token management Organization details and join request management People management Repository management and file details Tool and code pattern details Use the legacy endpoints to access and manipulate the following resources: Commit code quality details and deltas Project details and configurations, file code quality and issue details Important If you're using Codacy Self-hosted you must use your own Codacy instance domain name in the API URLs to access the endpoint documentation matching your Codacy Self-hosted version and to call the endpoints on your Codacy instance. For example, use the following URLs for the API v3 endpoint documentation and endpoints: https:///api/api-docs https:///api/v3", "title": "Using the Codacy API"}, {"location": "codacy-api/using-the-codacy-api/#authenticating-requests", "text": "Most API endpoints require that you authenticate using an API token. After obtaining the necessary tokens , include them in your request headers using the format api-token: or project-token: . Note Currently, all API v3 endpoints that require authentication must use account API tokens , while the API v2 endpoints require either account or repository API tokens . Performing GET requests for public repositories doesn't require authentication. For example, to make a request to an API v3 endpoint that requires an account API token: curl -X GET 'https://api.codacy.com/api/v3/user/organizations/gh' \\ -H 'api-token: ' Or to make a request to an API v2 endpoint that requires a repository API token: curl -X GET 'https://api.codacy.com/2.0/commit/da275c14ffab6e402dcc6009828067ffa44b7ee0' \\ -H 'project-token: '", "title": "Authenticating requests"}, {"location": "codacy-api/using-the-codacy-api/#using-parameters-in-requests", "text": "Most API endpoints require that you specify parameters. For GET requests , specify parameters directly as path segments of the endpoint URLs. Some endpoints also accept optional query string parameters. For example, to call the endpoint getRepositoryWithAnalysis with the parameters: provider: gh remoteOrganizationName: codacy repositoryName: docs branch (query string): api-overview curl -X GET 'https://app.codacy.com/api/v3/analysis/organizations/gh/codacy/repositories/docs?branch=api-overview' \\ -H 'api-token: ' For POST , PATCH , and DELETE requests , besides the parameters included in the URL you may also need to include a JSON body. For example, to call the endpoint searchRepositoryIssues specifying the issue levels Error and Warning in the body: curl -X POST 'https://app.codacy.com/api/v3/analysis/organizations/gh/codacy/repositories/docs/issues/search' \\ -H 'api-token: ' \\ -H 'Content-Type: application/json' \\ -d '{\"levels\": [\"Error\", \"Warning\"]}'", "title": "Using parameters in requests"}, {"location": "codacy-api/using-the-codacy-api/#using-pagination", "text": "Endpoints that return lists containing a potential large number of results use cursor-based pagination to return the results in small batches. These endpoints return the results together with a pagination object: If the pagination object includes a cursor , obtain the next page of results by calling the endpoint again using the cursor from the previous response as a query string parameter If the pagination object doesn't include a cursor , the endpoint returned the last page of results Use the query string parameter limit to configure the number of results that the endpoint returns in each page. The maximum limit is 1000 and the default is 100 The total is the total number of results that the endpoint can return Note To make sure that you receive all results when calling an endpoint with pagination, repeat the process above until the response doesn't include the cursor to obtain another page of results. For example, the following command requests the first 10 repositories in the Codacy GitHub organization: curl -X GET 'https://app.codacy.com/api/v3/organizations/gh/codacy/repositories?limit=10' -H 'api-token: ' The response includes the first 10 results, as well as the cursor to obtain the next page of results: { \"data\" : [ ... ], \"pagination\" : { \"cursor\" : \"codacy_2\" , \"limit\" : 10 , \"total\" : 156 } } To obtain the next page of results, it's necessary to include the cursor from the previous page as a parameter: curl -X GET 'https://app.codacy.com/api/v3/organizations/gh/codacy/repositories?limit=10&cursor=codacy_2' -H 'api-token: ' If you continue requesting more pages the endpoint will eventually return a pagination object that doesn't include a cursor . This means that you've reached the last page of results: { \"data\" : [ ... ], \"pagination\" : { \"limit\" : 10 , \"total\" : 156 } }", "title": "Using pagination"}, {"location": "codacy-api/using-the-codacy-api/#request-rate-limit", "text": "On Codacy Cloud the number of requests that you can perform to the Codacy API is rate limited to help us provide a reliable service: The limit is 2500 requests per 5 minutes and per source IP address When a request is rate limited, Codacy responds with an HTTP 503 or 504 error code and you should wait before attempting the request again Although it's possible for you to perform short bursts of requests to the Codacy API, you should always use a delay between requests to ensure that your API client doesn't hit the rate limits. The request rate limit doesn't apply to Codacy Self-hosted.", "title": "Request rate limit"}, {"location": "codacy-api/examples/adding-people-to-codacy-programmatically/", "text": "Adding people to Codacy programmatically # There are scenarios where manually adding people on the Codacy UI is inconvenient or time-consuming. For example, you're adding many people to Codacy, such as when initially onboarding all developers within a team. To add people programmatically, use the Codacy API endpoint addPeopleToOrganization by performing an HTTP POST request to /people , specifying a list of email addresses in the body of the request: curl -X POST https://app.codacy.com/api/v3/organizations///people \\ -H 'Content-Type: application/json' \\ -H 'api-token: ' \\ -d '[\"\", \"\"]' Substitute the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the organization, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server ORGANIZATION: Name of the organization on the Git provider. For example, codacy . You must have admin permissions over the organization on the Git provider. EMAIL#1...N: Email addresses of the people to be added. For example, no-reply@codacy.com . Example: Adding people from a file containing emails # We provide an example Bash script that adds all emails in a text file to Codacy. We suggest that you adapt the script to your specific scenario. The example script: Defines the account API token used to authenticate on the Codacy API. Defines the path and filename of the file containing the email addresses list. Uses awk and sed to read the email addresses list from a file. Calls the endpoint addPeopleToOrganization to add a list of email addresses to Codacy. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" FILENAME = \"emails.txt\" EMAILS = ` awk -vORS = , '{if(length($1)>0) printf(\"\\\"%s\\\",\", $1)}' $FILENAME | sed 's/,$//' ` curl -X POST \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /people\" \\ -H 'Content-Type: application/json' \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -d \"[ $EMAILS ]\" Expected format of the file containing the email addresses list: $ cat emails.txt email1@codacy.com email2@codacy.com email3@codacy.com email4@codacy.com See also # Adding people to your organization", "title": "Adding people to Codacy programmatically"}, {"location": "codacy-api/examples/adding-people-to-codacy-programmatically/#adding-people-to-codacy-programmatically", "text": "There are scenarios where manually adding people on the Codacy UI is inconvenient or time-consuming. For example, you're adding many people to Codacy, such as when initially onboarding all developers within a team. To add people programmatically, use the Codacy API endpoint addPeopleToOrganization by performing an HTTP POST request to /people , specifying a list of email addresses in the body of the request: curl -X POST https://app.codacy.com/api/v3/organizations///people \\ -H 'Content-Type: application/json' \\ -H 'api-token: ' \\ -d '[\"\", \"\"]' Substitute the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the organization, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server ORGANIZATION: Name of the organization on the Git provider. For example, codacy . You must have admin permissions over the organization on the Git provider. EMAIL#1...N: Email addresses of the people to be added. For example, no-reply@codacy.com .", "title": "Adding people to Codacy programmatically"}, {"location": "codacy-api/examples/adding-people-to-codacy-programmatically/#example-adding-people-from-a-file-containing-emails", "text": "We provide an example Bash script that adds all emails in a text file to Codacy. We suggest that you adapt the script to your specific scenario. The example script: Defines the account API token used to authenticate on the Codacy API. Defines the path and filename of the file containing the email addresses list. Uses awk and sed to read the email addresses list from a file. Calls the endpoint addPeopleToOrganization to add a list of email addresses to Codacy. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" FILENAME = \"emails.txt\" EMAILS = ` awk -vORS = , '{if(length($1)>0) printf(\"\\\"%s\\\",\", $1)}' $FILENAME | sed 's/,$//' ` curl -X POST \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /people\" \\ -H 'Content-Type: application/json' \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -d \"[ $EMAILS ]\" Expected format of the file containing the email addresses list: $ cat emails.txt email1@codacy.com email2@codacy.com email3@codacy.com email4@codacy.com", "title": "Example: Adding people from a file containing emails"}, {"location": "codacy-api/examples/adding-people-to-codacy-programmatically/#see-also", "text": "Adding people to your organization", "title": "See also"}, {"location": "codacy-api/examples/adding-repositories-to-codacy-programmatically/", "text": "Adding repositories to Codacy programmatically # There are scenarios where manually adding Git repositories on the Codacy UI is inconvenient or time-consuming. For example: You want to add all new repositories to Codacy when they're created on the Git provider You're adding many repositories to Codacy, such as when initially adding all repositories in your Git provider organization To add repositories programmatically, use the Codacy API v3 endpoint addRepository by performing an HTTP POST request to /repositories , specifying the Git provider and the full path of the repository in the body of the request: curl -X POST https://app.codacy.com/api/v3/repositories \\ -H 'Content-Type: application/json' \\ -H 'api-token: ' \\ -d '{\"provider\":\"\", \"repositoryFullPath\":\"\"}' Substitute the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the repository, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server REPOSITORY_FULL_PATH: Name of the organization and repository on the Git provider, using the format / . For example, codacy/docs . You must have admin permissions over the repository on the Git provider. Important If you're using GitLab you must specify the full group path and the repository using the format //...// . Example: Adding all repositories in a GitHub organization # We provide an example Bash script that adds all repositories in a GitHub Cloud organization to Codacy. We suggest that you adapt the script to your specific scenario. Warning Since Codacy automatically analyzes new repositories, adding many repositories in a short time can cause delays in the analysis of other repositories depending on the size of the repositories, the sizing of the infrastructure, and the concurrent analysis configuration. For example: Repositories added Expected delay 1 to 10 Small 11 to 100 Considerable More than 100 Extreme To avoid these delays, add repositories in small batches or space out adding new repositories over time. The example script: Defines a GitHub personal access token , the GitHub organization name, and the account API token used to authenticate on the Codacy API. Calls the GitHub API to obtain the list of all repositories in the defined organization. Uses jq to return the value of full_name for each repository obtained in the JSON response. The full_name already includes the organization and repository names using the format / . For each repository, calls the endpoint addRepository to add a new repository specifying gh as the Git provider and the value of full_name as the full path of the repository. Checks the HTTP status code obtained in the response and performs basic error handling. Pauses a few seconds between requests to the Codacy API to avoid rate limiting. #!/bin/bash GITHUB_AUTH_TOKEN = \"\" GITHUB_ORG_NAME = \"\" CODACY_API_TOKEN = \"\" printf \"Obtaining all repositories in the $GITHUB_ORG_NAME organization\\n\" for repo in $( curl -s https://api.github.com/orgs/ $GITHUB_ORG_NAME /repos -H \"Authorization: Bearer $GITHUB_AUTH_TOKEN \" | jq -r '.[] | .full_name' ) ; do printf \"Adding $repo to Codacy\\n\" http_status = $( curl -X POST https://app.codacy.com/api/v3/repositories \\ -H \"Content-Type: application/json\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -d '{\"provider\":\"gh\", \"repositoryFullPath\":\"' $repo '\"}' \\ -sSo /dev/null -w \"%{http_code}\" ) case \" $http_status \" in 200 ) printf \" $repo added successfully\\n\" ;; 401 ) printf \"Error: 401 Unauthorized, check the Codacy API token\\n\" break ;; 409 ) printf \"Error: 409 Conflict, $repo is already added to Codacy\\n\" ;; * ) printf \"Error: $http_status HTTP status code\\n\" break ;; esac sleep 60 # Pause between repositories done Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API. Besides this, the script doesn't consider paginated results obtained from the GitHub API. Learn how to use pagination on the GitHub API to ensure that you obtain all the repositories in your organization.", "title": "Adding repositories to Codacy programmatically"}, {"location": "codacy-api/examples/adding-repositories-to-codacy-programmatically/#adding-repositories-to-codacy-programmatically", "text": "There are scenarios where manually adding Git repositories on the Codacy UI is inconvenient or time-consuming. For example: You want to add all new repositories to Codacy when they're created on the Git provider You're adding many repositories to Codacy, such as when initially adding all repositories in your Git provider organization To add repositories programmatically, use the Codacy API v3 endpoint addRepository by performing an HTTP POST request to /repositories , specifying the Git provider and the full path of the repository in the body of the request: curl -X POST https://app.codacy.com/api/v3/repositories \\ -H 'Content-Type: application/json' \\ -H 'api-token: ' \\ -d '{\"provider\":\"\", \"repositoryFullPath\":\"\"}' Substitute the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the repository, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server REPOSITORY_FULL_PATH: Name of the organization and repository on the Git provider, using the format / . For example, codacy/docs . You must have admin permissions over the repository on the Git provider. Important If you're using GitLab you must specify the full group path and the repository using the format //...// .", "title": "Adding repositories to Codacy programmatically"}, {"location": "codacy-api/examples/adding-repositories-to-codacy-programmatically/#example-adding-all-repositories-in-a-github-organization", "text": "We provide an example Bash script that adds all repositories in a GitHub Cloud organization to Codacy. We suggest that you adapt the script to your specific scenario. Warning Since Codacy automatically analyzes new repositories, adding many repositories in a short time can cause delays in the analysis of other repositories depending on the size of the repositories, the sizing of the infrastructure, and the concurrent analysis configuration. For example: Repositories added Expected delay 1 to 10 Small 11 to 100 Considerable More than 100 Extreme To avoid these delays, add repositories in small batches or space out adding new repositories over time. The example script: Defines a GitHub personal access token , the GitHub organization name, and the account API token used to authenticate on the Codacy API. Calls the GitHub API to obtain the list of all repositories in the defined organization. Uses jq to return the value of full_name for each repository obtained in the JSON response. The full_name already includes the organization and repository names using the format / . For each repository, calls the endpoint addRepository to add a new repository specifying gh as the Git provider and the value of full_name as the full path of the repository. Checks the HTTP status code obtained in the response and performs basic error handling. Pauses a few seconds between requests to the Codacy API to avoid rate limiting. #!/bin/bash GITHUB_AUTH_TOKEN = \"\" GITHUB_ORG_NAME = \"\" CODACY_API_TOKEN = \"\" printf \"Obtaining all repositories in the $GITHUB_ORG_NAME organization\\n\" for repo in $( curl -s https://api.github.com/orgs/ $GITHUB_ORG_NAME /repos -H \"Authorization: Bearer $GITHUB_AUTH_TOKEN \" | jq -r '.[] | .full_name' ) ; do printf \"Adding $repo to Codacy\\n\" http_status = $( curl -X POST https://app.codacy.com/api/v3/repositories \\ -H \"Content-Type: application/json\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -d '{\"provider\":\"gh\", \"repositoryFullPath\":\"' $repo '\"}' \\ -sSo /dev/null -w \"%{http_code}\" ) case \" $http_status \" in 200 ) printf \" $repo added successfully\\n\" ;; 401 ) printf \"Error: 401 Unauthorized, check the Codacy API token\\n\" break ;; 409 ) printf \"Error: 409 Conflict, $repo is already added to Codacy\\n\" ;; * ) printf \"Error: $http_status HTTP status code\\n\" break ;; esac sleep 60 # Pause between repositories done Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API. Besides this, the script doesn't consider paginated results obtained from the GitHub API. Learn how to use pagination on the GitHub API to ensure that you obtain all the repositories in your organization.", "title": "Example: Adding all repositories in a GitHub organization"}, {"location": "codacy-api/examples/creating-repository-api-tokens-programmatically/", "text": "Creating repository API tokens programmatically # To create new repository API tokens for your Codacy repositories programmatically, use the Codacy API endpoint createRepositoryApiToken . You can also list all repository API tokens for a repository using the endpoint listRepositoryApiTokens . For example, if you're setting up coverage for all your repositories and prefer not to use a single account API token that grants the same permissions as an administrator, you need to create an individual repository API token for each repository. Example: Creating a repository API token for a single repository # This example creates a new repository API token for a repository and outputs the new token string. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, the organization name, and the repository name passed as an argument to the script. Calls the endpoint createRepositoryApiToken to create a new repository API token and uses jq to obtain only the created token string. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = $1 curl -sX POST \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /tokens\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data | .token\" Example usage and output $ ./create-token.sh website Example: Creating repository API tokens for all repositories in an organization # This example creates new repository API tokens for all the repositories in an organization and outputs a comma-separated list of repository names and corresponding token strings. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, and the organization name. Calls the endpoint listOrganizationRepositories to retrieve the list of repositories in the organization. Uses jq to select only the name of the repositories. Asks for confirmation from the user before making any changes. For each repository, calls the endpoint createRepositoryApiToken to create a new repository API token and uses jq to obtain only the created token string. Outputs a comma-separated list of the repository names and the corresponding new token strings. Pauses a few seconds between requests to the Codacy API to avoid rate limiting. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" repositories = $( curl -sX GET \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data[] | .name\" ) count = $( echo \" $repositories \" | wc -l ) read -p \"Create repository tokens for $count repositories? (y/n) \" choice if [ \" $choice \" = \"y\" ] ; then echo \" $repositories \" | while read repository ; do echo -n \" $repository ,\" curl -sX POST \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $repository /tokens\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data | .token\" sleep 2 # Wait 2 seconds done else echo \"No changes made.\" ; fi Example output: chart, docs, website, [...] Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API. Example: Listing the repository API tokens for a repository # This example lists all repository API tokens created for a repository. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, the organization name, and the repository name passed as an argument to the script. Calls the endpoint listRepositoryApiTokens to list the repository API tokens available on the repository and uses jq to obtain only the token strings, or exit with a non-zero status if the repository doesn't have any repository API tokens created yet. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = $1 curl -sX GET \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /tokens\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -er \".data[] | .token\" Example usage to obtain only the repository API token created most recently for the repository: $ ./list-tokens.sh website | head -n 1 See also # API tokens", "title": "Creating repository API tokens programmatically"}, {"location": "codacy-api/examples/creating-repository-api-tokens-programmatically/#creating-repository-api-tokens-programmatically", "text": "To create new repository API tokens for your Codacy repositories programmatically, use the Codacy API endpoint createRepositoryApiToken . You can also list all repository API tokens for a repository using the endpoint listRepositoryApiTokens . For example, if you're setting up coverage for all your repositories and prefer not to use a single account API token that grants the same permissions as an administrator, you need to create an individual repository API token for each repository.", "title": "Creating repository API tokens programmatically"}, {"location": "codacy-api/examples/creating-repository-api-tokens-programmatically/#example-creating-a-repository-api-token-for-a-single-repository", "text": "This example creates a new repository API token for a repository and outputs the new token string. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, the organization name, and the repository name passed as an argument to the script. Calls the endpoint createRepositoryApiToken to create a new repository API token and uses jq to obtain only the created token string. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = $1 curl -sX POST \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /tokens\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data | .token\" Example usage and output $ ./create-token.sh website ", "title": "Example: Creating a repository API token for a single repository"}, {"location": "codacy-api/examples/creating-repository-api-tokens-programmatically/#example-creating-repository-api-tokens-for-all-repositories-in-an-organization", "text": "This example creates new repository API tokens for all the repositories in an organization and outputs a comma-separated list of repository names and corresponding token strings. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, and the organization name. Calls the endpoint listOrganizationRepositories to retrieve the list of repositories in the organization. Uses jq to select only the name of the repositories. Asks for confirmation from the user before making any changes. For each repository, calls the endpoint createRepositoryApiToken to create a new repository API token and uses jq to obtain only the created token string. Outputs a comma-separated list of the repository names and the corresponding new token strings. Pauses a few seconds between requests to the Codacy API to avoid rate limiting. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" repositories = $( curl -sX GET \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data[] | .name\" ) count = $( echo \" $repositories \" | wc -l ) read -p \"Create repository tokens for $count repositories? (y/n) \" choice if [ \" $choice \" = \"y\" ] ; then echo \" $repositories \" | while read repository ; do echo -n \" $repository ,\" curl -sX POST \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $repository /tokens\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data | .token\" sleep 2 # Wait 2 seconds done else echo \"No changes made.\" ; fi Example output: chart, docs, website, [...] Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API.", "title": "Example: Creating repository API tokens for all repositories in an organization"}, {"location": "codacy-api/examples/creating-repository-api-tokens-programmatically/#example-listing-the-repository-api-tokens-for-a-repository", "text": "This example lists all repository API tokens created for a repository. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, the organization name, and the repository name passed as an argument to the script. Calls the endpoint listRepositoryApiTokens to list the repository API tokens available on the repository and uses jq to obtain only the token strings, or exit with a non-zero status if the repository doesn't have any repository API tokens created yet. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = $1 curl -sX GET \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /tokens\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -er \".data[] | .token\" Example usage to obtain only the repository API token created most recently for the repository: $ ./list-tokens.sh website | head -n 1 ", "title": "Example: Listing the repository API tokens for a repository"}, {"location": "codacy-api/examples/creating-repository-api-tokens-programmatically/#see-also", "text": "API tokens", "title": "See also"}, {"location": "codacy-api/examples/identifying-commits-without-coverage-data/", "text": "Identifying commits without coverage data # To calculate the supported coverage metrics for pull requests, Codacy requires that at least the following commits provide coverage data: The common ancestor commit of the pull request branch and the target branch The head commit of the pull request branch The following diagram highlights the commits that must have received coverage data for Codacy to display the coverage variation metric on a pull request: However, different factors may prevent your setup from correctly reporting coverage data for the required commits. To check if Codacy has received the required coverage data to calculate the coverage metrics for a pull request, use the Codacy API endpoint getPullRequestCoverageReports . Example: Identifying which pull request commits are missing coverage data # This example checks whether the open pull requests in a repository have received coverage data for their head and common ancestor commits. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, the organization name, and the repository name passed as an argument to the script. Calls the Codacy API endpoint listRepositoryPullRequests to retrieve the list of open pull requests on the repository. Uses jq to select only the numbers that identify the pull requests on the Git provider. For each pull request, outputs the pull request number and calls the Codacy API endpoint getPullRequestCoverageReports to obtain the information about the coverage data received for the head and common ancestor commits of the pull request. Uses jq to select and output the commit SHA-1 and coverage status for the commits. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = $1 curl -sX GET \"https://app.codacy.com/api/v3/analysis/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /pull-requests\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: application/json\" \\ | jq -r \".data[] | .pullRequest.number\" | \\ while read pull_request_number ; do echo \"Checking # $pull_request_number \" curl -sX GET \"https://app.codacy.com/api/v3/analysis/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /pull-requests/ $pull_request_number /coverage/status\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: application/json\" \\ | jq -r '.data[] | \"Coverage for \\(.commitSha) is \\(.reports[0].status)\"' done Example usage and output, where: The first commit listed for each pull request is the head commit of the pull request branch The second commit listed for each pull request is the common ancestor commit of the pull request branch Note If you find commits where the coverage status is different from Processed , follow these troubleshooting instructions to validate that your coverage setup is working correctly. $ ./check-coverage.sh pulse Checking #1563 Coverage for 4faccc86676f7dba3af2b71400605b0be4a686e3 is Processed Coverage for 51e57784468459b9b2839aa63c3e7e807a39c4ab is null Checking #1481 Coverage for 6d6a3ec0c773fb016a7302f8111c185a34e1a9b2 is null Coverage for 4015f987fab77d41dc27ec3100b57fa58bef4559 is Processed Checking #1434 Coverage for 74efe5d7542846f36cb8c030bd6b73fa9060dca2 is null Coverage for 1a64ea8885717e7b9874c9f3702806ec96b00276 is null Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API. See also # Adding coverage to your repository", "title": "Identifying commits without coverage data"}, {"location": "codacy-api/examples/identifying-commits-without-coverage-data/#identifying-commits-without-coverage-data", "text": "To calculate the supported coverage metrics for pull requests, Codacy requires that at least the following commits provide coverage data: The common ancestor commit of the pull request branch and the target branch The head commit of the pull request branch The following diagram highlights the commits that must have received coverage data for Codacy to display the coverage variation metric on a pull request: However, different factors may prevent your setup from correctly reporting coverage data for the required commits. To check if Codacy has received the required coverage data to calculate the coverage metrics for a pull request, use the Codacy API endpoint getPullRequestCoverageReports .", "title": "Identifying commits without coverage data"}, {"location": "codacy-api/examples/identifying-commits-without-coverage-data/#example-identifying-which-pull-request-commits-are-missing-coverage-data", "text": "This example checks whether the open pull requests in a repository have received coverage data for their head and common ancestor commits. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, the organization name, and the repository name passed as an argument to the script. Calls the Codacy API endpoint listRepositoryPullRequests to retrieve the list of open pull requests on the repository. Uses jq to select only the numbers that identify the pull requests on the Git provider. For each pull request, outputs the pull request number and calls the Codacy API endpoint getPullRequestCoverageReports to obtain the information about the coverage data received for the head and common ancestor commits of the pull request. Uses jq to select and output the commit SHA-1 and coverage status for the commits. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = $1 curl -sX GET \"https://app.codacy.com/api/v3/analysis/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /pull-requests\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: application/json\" \\ | jq -r \".data[] | .pullRequest.number\" | \\ while read pull_request_number ; do echo \"Checking # $pull_request_number \" curl -sX GET \"https://app.codacy.com/api/v3/analysis/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /pull-requests/ $pull_request_number /coverage/status\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: application/json\" \\ | jq -r '.data[] | \"Coverage for \\(.commitSha) is \\(.reports[0].status)\"' done Example usage and output, where: The first commit listed for each pull request is the head commit of the pull request branch The second commit listed for each pull request is the common ancestor commit of the pull request branch Note If you find commits where the coverage status is different from Processed , follow these troubleshooting instructions to validate that your coverage setup is working correctly. $ ./check-coverage.sh pulse Checking #1563 Coverage for 4faccc86676f7dba3af2b71400605b0be4a686e3 is Processed Coverage for 51e57784468459b9b2839aa63c3e7e807a39c4ab is null Checking #1481 Coverage for 6d6a3ec0c773fb016a7302f8111c185a34e1a9b2 is null Coverage for 4015f987fab77d41dc27ec3100b57fa58bef4559 is Processed Checking #1434 Coverage for 74efe5d7542846f36cb8c030bd6b73fa9060dca2 is null Coverage for 1a64ea8885717e7b9874c9f3702806ec96b00276 is null Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API.", "title": "Example: Identifying which pull request commits are missing coverage data"}, {"location": "codacy-api/examples/identifying-commits-without-coverage-data/#see-also", "text": "Adding coverage to your repository", "title": "See also"}, {"location": "codacy-api/examples/obtaining-code-quality-metrics-for-files/", "text": "Obtaining code quality metrics for files # To obtain the code quality information for your files in a flexible way, use the Codacy API endpoint listFiles . For example, if you're managing your source code using a monorepo strategy you may want to generate separate code quality reports for the subset of files that belong to each component or project in your repository. Example: Obtaining code quality metrics for a subdirectory of your repository # This example exports the grade, total issues, complexity, coverage, and duplication in CSV format for all files in the directory src/router of the GitHub repository codacy/website . The example script: Defines the account API token used to authenticate on the Codacy API. Calls the endpoint listFiles to retrieve the code quality metrics, filtering the results by files that include src/router/ in the path. Uses jq to select only the necessary data fields and convert the results to the CSV format. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = \"\" curl -X GET \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /files?search=src/router/\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data[] | [.path, .gradeLetter, .totalIssues, .complexity, .coverage, .duplication] | @csv\" Example output: \"src/components/router/index.ts\",\"A\",0,8,70,0 \"src/components/router/Link.tsx\",\"A\",0,5,100,0 \"src/components/router/Redirect.tsx\",\"B\",0,2,14,0 \"src/components/router/routes/account.ts\",\"A\",0,0,100,0 [...] Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API. See also # Which metrics does Codacy calculate? Files page", "title": "Obtaining code quality metrics for files"}, {"location": "codacy-api/examples/obtaining-code-quality-metrics-for-files/#obtaining-code-quality-metrics-for-files", "text": "To obtain the code quality information for your files in a flexible way, use the Codacy API endpoint listFiles . For example, if you're managing your source code using a monorepo strategy you may want to generate separate code quality reports for the subset of files that belong to each component or project in your repository.", "title": "Obtaining code quality metrics for files"}, {"location": "codacy-api/examples/obtaining-code-quality-metrics-for-files/#example-obtaining-code-quality-metrics-for-a-subdirectory-of-your-repository", "text": "This example exports the grade, total issues, complexity, coverage, and duplication in CSV format for all files in the directory src/router of the GitHub repository codacy/website . The example script: Defines the account API token used to authenticate on the Codacy API. Calls the endpoint listFiles to retrieve the code quality metrics, filtering the results by files that include src/router/ in the path. Uses jq to select only the necessary data fields and convert the results to the CSV format. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = \"\" curl -X GET \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /files?search=src/router/\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data[] | [.path, .gradeLetter, .totalIssues, .complexity, .coverage, .duplication] | @csv\" Example output: \"src/components/router/index.ts\",\"A\",0,8,70,0 \"src/components/router/Link.tsx\",\"A\",0,5,100,0 \"src/components/router/Redirect.tsx\",\"B\",0,2,14,0 \"src/components/router/routes/account.ts\",\"A\",0,0,100,0 [...] Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API.", "title": "Example: Obtaining code quality metrics for a subdirectory of your repository"}, {"location": "codacy-api/examples/obtaining-code-quality-metrics-for-files/#see-also", "text": "Which metrics does Codacy calculate? Files page", "title": "See also"}, {"location": "codacy-api/examples/obtaining-current-issues-in-repositories/", "text": "Obtaining current issues in repositories # To obtain information about the current issues in your repositories in a flexible way, use the Codacy API endpoint searchRepositoryIssues . For example, you may want to generate a report that includes only issues that belong to specific categories (such as security issues), or that have a minimum severity level. Example: Obtaining security issues with level Error and Warning # This example exports the pattern ID, issue level, file path, and timestamp for all security issues that have the severity level Warning or Error in the GitHub repository codacy/website . The example script: Defines the account API token used to authenticate on the Codacy API. Calls the endpoint searchRepositoryIssues to retrieve information about the issues, filtering the results by security issues with the relevant severity levels. Uses jq to select only the necessary data fields and convert the results to the CSV format. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = \"\" curl -X POST \"https://app.codacy.com/api/v3/analysis/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /issues/search\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: application/json\" \\ -d '{ \"levels\": [\"Error\", \"Warning\"], \"categories\": [\"Security\"] }' \\ | jq -r \".data[] | [.patternInfo.id, .patternInfo.level, .filePath, .commitInfo.timestamp] | @csv\" Example output: \"BundlerAudit_Insecure Dependency\",\"Error\",\"Gemfile.lock\",\"2021-06-16T11:46:24Z\" \"Custom_Scala_PredictableRandom\",\"Warning\",\"src/test/database/SpecsHelper.scala\",\"2021-05-21T16:20:15Z\" \"Custom_Scala_PlayUntrustedHttpRequestParameter\",\"Warning\",\"app/RedirectController.scala\",\"2021-04-26T15:06:33Z\" [...] Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API. See also # Which metrics does Codacy calculate? Issues page", "title": "Obtaining current issues in repositories"}, {"location": "codacy-api/examples/obtaining-current-issues-in-repositories/#obtaining-current-issues-in-repositories", "text": "To obtain information about the current issues in your repositories in a flexible way, use the Codacy API endpoint searchRepositoryIssues . For example, you may want to generate a report that includes only issues that belong to specific categories (such as security issues), or that have a minimum severity level.", "title": "Obtaining current issues in repositories"}, {"location": "codacy-api/examples/obtaining-current-issues-in-repositories/#example-obtaining-security-issues-with-level-error-and-warning", "text": "This example exports the pattern ID, issue level, file path, and timestamp for all security issues that have the severity level Warning or Error in the GitHub repository codacy/website . The example script: Defines the account API token used to authenticate on the Codacy API. Calls the endpoint searchRepositoryIssues to retrieve information about the issues, filtering the results by security issues with the relevant severity levels. Uses jq to select only the necessary data fields and convert the results to the CSV format. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = \"\" curl -X POST \"https://app.codacy.com/api/v3/analysis/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /issues/search\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: application/json\" \\ -d '{ \"levels\": [\"Error\", \"Warning\"], \"categories\": [\"Security\"] }' \\ | jq -r \".data[] | [.patternInfo.id, .patternInfo.level, .filePath, .commitInfo.timestamp] | @csv\" Example output: \"BundlerAudit_Insecure Dependency\",\"Error\",\"Gemfile.lock\",\"2021-06-16T11:46:24Z\" \"Custom_Scala_PredictableRandom\",\"Warning\",\"src/test/database/SpecsHelper.scala\",\"2021-05-21T16:20:15Z\" \"Custom_Scala_PlayUntrustedHttpRequestParameter\",\"Warning\",\"app/RedirectController.scala\",\"2021-04-26T15:06:33Z\" [...] Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API.", "title": "Example: Obtaining security issues with level Error and Warning"}, {"location": "codacy-api/examples/obtaining-current-issues-in-repositories/#see-also", "text": "Which metrics does Codacy calculate? Issues page", "title": "See also"}, {"location": "codacy-api/examples/uploading-dast-results/", "text": "Uploading DAST results to Codacy # To ensure the security of your web applications, Codacy allows you to upload DAST (dynamic application security testing) results from Zed Attack Proxy (ZAP) directly to Codacy and monitor them as findings under Security and risk management . Uploading results to Codacy # Use ZAP to perform DAST on your application and generate a report in the Traditional JSON format . For details on generating reports in ZAP, refer to the ZAP documentation . Upload the report to Codacy using the API endpoint uploadDASTReport : Note The DAST report must be under 20MB in size. curl -X POST https://app.codacy.com/api/v3/organizations///security/tools/dast//reports \\ -H 'api-token: ' \\ -H 'Content-Type: multipart/form-data' \\ -H 'Accept: application/json' \\ -F 'file=@' \\ -F 'reportFormat=json' Replace the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the organization, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server ORGANIZATION: Name of the organization on the Git provider. For example, codacy . You must have admin permissions over the organization on the Git provider. TOOL_NAME: Name of the tool used to generate the report. Currently, only ZAP is supported. REPORT_PATH: Path to the file containing the DAST report. Replace placeholders with your specific details to complete the upload. This process seamlessly integrates the security insights of third-party DAST tools with Codacy for a comprehensive security overview. Retrieving uploaded results on Codacy # To retrieve a list of uploaded DAST reports, access the Codacy API endpoint listDASTReports : GET /organizations/{provider}/{remoteOrganizationName}/security/dast/reports curl -X GET https://api.codacy.com/api/v3/organizations///security/dast/reports \\ -H 'api-token: ' \\ -H 'Accept: application/json' Replace the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the organization, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server TOOL_NAME: Name of the tool used to generate the report. Currently, only ZAP is supported. This endpoint provides a list of all DAST reports uploaded to Codacy, allowing you to check the status and details of each report. Example: Uploading ZAP DAST results # Use this example Bash script to upload the ZAP DAST report to Codacy. This example can be adapted to fit your specific needs. The example script: Defines the API token used to authenticate on the Codacy API. Defines the path and filename of the file containing the DAST report. Calls the endpoint uploadDASTReport to upload the report to Codacy. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # e.g., gh for GitHub ORGANIZATION_NAME = \"\" TOOL_NAME = \"\" # e.g., ZAP REPORT_FILE_PATH = \"zap-report.json\" curl -X POST https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION_NAME /security/tools/dast/ $TOOL_NAME /reports \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: multipart/form-data\" \\ -H \"Accept: application/json\" \\ -F \"file=@ $REPORT_FILE_PATH \" \\ -F \"reportFormat=json\"", "title": "Uploading DAST results to Codacy"}, {"location": "codacy-api/examples/uploading-dast-results/#uploading-dast-results-to-codacy", "text": "To ensure the security of your web applications, Codacy allows you to upload DAST (dynamic application security testing) results from Zed Attack Proxy (ZAP) directly to Codacy and monitor them as findings under Security and risk management .", "title": "Uploading DAST results to Codacy"}, {"location": "codacy-api/examples/uploading-dast-results/#uploading-results-to-codacy", "text": "Use ZAP to perform DAST on your application and generate a report in the Traditional JSON format . For details on generating reports in ZAP, refer to the ZAP documentation . Upload the report to Codacy using the API endpoint uploadDASTReport : Note The DAST report must be under 20MB in size. curl -X POST https://app.codacy.com/api/v3/organizations///security/tools/dast//reports \\ -H 'api-token: ' \\ -H 'Content-Type: multipart/form-data' \\ -H 'Accept: application/json' \\ -F 'file=@' \\ -F 'reportFormat=json' Replace the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the organization, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server ORGANIZATION: Name of the organization on the Git provider. For example, codacy . You must have admin permissions over the organization on the Git provider. TOOL_NAME: Name of the tool used to generate the report. Currently, only ZAP is supported. REPORT_PATH: Path to the file containing the DAST report. Replace placeholders with your specific details to complete the upload. This process seamlessly integrates the security insights of third-party DAST tools with Codacy for a comprehensive security overview.", "title": "Uploading results to Codacy"}, {"location": "codacy-api/examples/uploading-dast-results/#retrieving-uploaded-results-on-codacy", "text": "To retrieve a list of uploaded DAST reports, access the Codacy API endpoint listDASTReports : GET /organizations/{provider}/{remoteOrganizationName}/security/dast/reports curl -X GET https://api.codacy.com/api/v3/organizations///security/dast/reports \\ -H 'api-token: ' \\ -H 'Accept: application/json' Replace the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the organization, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server TOOL_NAME: Name of the tool used to generate the report. Currently, only ZAP is supported. This endpoint provides a list of all DAST reports uploaded to Codacy, allowing you to check the status and details of each report.", "title": "Retrieving uploaded results on Codacy"}, {"location": "codacy-api/examples/uploading-dast-results/#example-uploading-zap-dast-results", "text": "Use this example Bash script to upload the ZAP DAST report to Codacy. This example can be adapted to fit your specific needs. The example script: Defines the API token used to authenticate on the Codacy API. Defines the path and filename of the file containing the DAST report. Calls the endpoint uploadDASTReport to upload the report to Codacy. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # e.g., gh for GitHub ORGANIZATION_NAME = \"\" TOOL_NAME = \"\" # e.g., ZAP REPORT_FILE_PATH = \"zap-report.json\" curl -X POST https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION_NAME /security/tools/dast/ $TOOL_NAME /reports \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: multipart/form-data\" \\ -H \"Accept: application/json\" \\ -F \"file=@ $REPORT_FILE_PATH \" \\ -F \"reportFormat=json\"", "title": "Example: Uploading ZAP DAST results"}, {"location": "coverage-reporter/", "text": "Adding coverage to your repository # Code coverage is a metric used to describe the degree to which the source code of a program is tested. A program with high code coverage has been more thoroughly tested and has a lower chance of containing software bugs than a program with low code coverage. You can read more about the basics of code coverage on Codacy's blog. To monitor the code coverage of your repository on Codacy you must generate coverage reports for each commit on your CI/CD workflow, and then upload the coverage data to Codacy. Complete these main steps to set up coverage for your repository: Generating coverage reports Ensure that you're generating one of the code coverage report formats supported by Codacy on each push to your repository. Uploading coverage data to Codacy After each push to your repository, run the Codacy Coverage Reporter to parse your report file and upload the coverage data to Codacy. Validating that the coverage setup is complete Check if Codacy displays the coverage metrics for new commits and pull requests and troubleshoot the coverage setup if necessary. The next sections include detailed instructions on how to complete each step of the setup process. 1. Generating coverage reports # Before setting up Codacy to display code coverage metrics for your repository you must have tests and use tools to generate coverage reports for the source code files in your repository. Consider the following when generating coverage reports for your repository: There are many tools that you can use to generate coverage reports, but you must ensure that the coverage reports are in one of the formats that Codacy supports If your repository includes multiple programming languages, you may need to generate a separate coverage report for each language depending on the specific languages and tools that you use Make sure that you generate coverage reports that include coverage data for all tested source code files in your repository and not just the files that were changed in each commit The following table contains example coverage tools that generate reports in formats that Codacy supports: Language Example coverage tools Report files C# OpenCover opencover.xml (OpenCover) dotCover CLI dotcover.xml (dotCover detailedXML ) Coverlet Make sure that you output the report files in a supported format using one of the following file names: opencover.xml (OpenCover) cobertura.xml (Cobertura) lcov.info , lcov.dat , *.lcov (LCOV) Go Golang Code Coverage Golang report files don't have a specific name. Because of this, later in the setup process you must follow specific instructions while submitting coverage to Codacy. Java JaCoCo jacoco*.xml (JaCoCo) Cobertura cobertura.xml (Cobertura) JavaScript Istanbul Mocha + Blanket.js lcov.info , lcov.dat , *.lcov (LCOV) PHP PHPUnit coverage-xml/index.xml (PHPUnit XML version <= 4) clover.xml (Clover) Python Coverage.py cobertura.xml (Cobertura) Ruby SimpleCov cobertura.xml (Cobertura) lcov.info , lcov.dat , *.lcov (LCOV) Scala sbt-jacoco jacoco*.xml (JaCoCo) scoverage cobertura.xml (Cobertura) Swift/Objective-C Xcode Code Coverage See below how to generate coverage reports with Xcode Handling unsupported languages # If you're generating a report format that Codacy doesn't support yet, contribute with a parser implementation yourself or use one of the community projects below to generate coverage reports in a supported format: SlatherOrg/slather : generate Cobertura reports from Xcode coverage reports: gem install slather slather coverage -x --output-directory --scheme .xcodeproj This will generate a file cobertura.xml inside the folder . dariodf/lcov_ex : generate LCOV reports for Elixir projects chrisgit/sfdx-plugins_apex_coverage_report : generate LCOV or Cobertura reports from Apex code coverage data danielpalme/ReportGenerator : convert between different report formats Important Make sure that you specify the language when uploading coverage for an unsupported language. As a last resort, you can also send the coverage data directly by calling one of the following Codacy API endpoints: saveCoverage saveCoverageWithAccountToken 2. Uploading coverage data to Codacy # After having coverage reports set up for your repository, you must use the Codacy Coverage Reporter to upload them to Codacy. The recommended way to do this is by using a CI/CD platform that automatically runs tests, generates coverage, and then uses the Codacy Coverage Reporter to upload the coverage report information to Codacy. Important Please note that Codacy needs to receive coverage data for: Every push to your repository including merge commits or any commits created automatically by tools such as Dependabot All tested files in your repository including the files that weren't changed in the commit, or files from unchanged modules in a monorepo setup Alternative ways of running the Codacy Coverage Reporter Codacy makes available alternative ways to run the Codacy Coverage Reporter , such as by installing the binary manually or by using Docker, a GitHub Action, or a CircleCI Orb. However, the instructions on this page assume that you'll run the recommended self-contained bash script get.sh to automatically download and run the most recent version of the Codacy Coverage Reporter. Set up an API token to allow Codacy Coverage Reporter to authenticate on Codacy: If you're setting up coverage for one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up and automating coverage for multiple repositories , obtain an account API Token and set the following environment variables: CODACY_API_TOKEN: Your account API token. CODACY_ORGANIZATION_PROVIDER: Git provider hosting the repository. Must be one of gh , ghe , gl , gle , bb , or bbe to specify GitHub, GitHub Enterprise, GitLab, GitLab Enterprise, Bitbucket, or Bitbucket Enterprise, respectively. CODACY_USERNAME: Name of your organization on the Git provider, or your username on the Git provider if you're using a personal organization. CODACY_PROJECT_NAME: Name of the repository for which you're uploading the coverage data. export CODACY_API_TOKEN = export CODACY_ORGANIZATION_PROVIDER = export CODACY_USERNAME = export CODACY_PROJECT_NAME = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variables to specify your Codacy instance URL and the Codacy Coverage Reporter version that's compatible with Codacy Self-hosted 14.0.0: export CODACY_API_BASE_URL = export CODACY_REPORTER_VERSION = 13 .10.15 Run Codacy Coverage Reporter on the root of the locally checked out branch of your Git repository , specifying the relative path to the coverage report to upload: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report -r Check the console output to validate that the Codacy Coverage Reporter detected the correct commit SHA-1 hash and successfully uploaded the coverage data to Codacy. If you need help, check the troubleshooting page for solutions to the most common issues while running the CLI. Note Be sure to also check the instructions for more advanced scenarios while uploading the coverage data to Codacy, such as when running parallel tests, using monorepos, or testing source code in multiple or unsupported languages. 3. Validating that the coverage setup is complete # Codacy displays the code coverage in each branch, as well as the evolution of code coverage between commits and the code coverage variation introduced by pull requests. Because of this, to ensure that all code coverage metrics are available on Codacy, you must have successfully uploaded coverage data and analyzed: The last two commits in each branch The common ancestor commit of each pull request branch and its target branch Example The example below shows that after pushing a commit that correctly sets up coverage on the default branch: Codacy will report coverage metrics for all subsequent commits and pull requests relative to the default branch. Codacy won't report coverage metrics for commits and pull requests that are relative to older branches where the coverage setup wasn't performed yet. To solve this issue, you can rebase the old feature branch to update the common ancestor commit to one that already has coverage data. Follow these instructions to validate that your coverage setup is working correctly: On Codacy, open your Repository Settings , tab Coverage , and observe the list of the most recent 50 coverage reports in the section Test your integration . Make sure that Codacy receives and processes the coverage data successfully for at least two commits . If there are commits with a status different from Processed , please follow the troubleshooting instructions for the corresponding error status and click the button Test integration to display any new coverage reports uploaded to Codacy. Commit not found # Codacy doesn't have information about the commit associated with the coverage data. What causes the error? How to fix the error? Codacy didn't receive the webhook for that commit from the Git provider. Wait a few more minutes until Codacy detects the commit and the status will update automatically. If it takes more than 5 to 10 minutes for Codacy to detect the commit, the webhook call from the Git provider may have been lost. You can wait until you push a new commit or contact support@codacy.com asking us to sync the commits on Codacy with your Git provider. The commit SHA-1 hash sent while uploading coverage is wrong. Make sure that the Codacy Coverage Reporter detects the correct commit SHA-1 hash for the uploaded coverage data. Branch not enabled # The commit associated with the coverage data doesn't belong to any branch that Codacy is analyzing. What causes the error? How to fix the error? Coverage was uploaded for a commit that belongs to a branch that isn't analyzed by Codacy. Make sure that the branch is enabled on Codacy . Alternatively, ensure that the target branch is enabled and open a pull request for Codacy to start analyzing the branch automatically. If Codacy is already analyzing the branch, make sure that the Codacy Coverage Reporter detects the correct commit SHA-1 hash for the uploaded coverage data. Coverage was uploaded for a commit that no longer belongs to any branch on the Git repository, for example after a rebase or squash merge. The error status is expected in this scenario and you can ignore it. Commit not analyzed # Due to technical limitations, Codacy only reports coverage for a commit after successfully completing the static code analysis of that commit. What causes the error? How to fix the error? Codacy hasn't finished analyzing the commit yet. Wait a few more minutes until Codacy completes the static code analysis for the commit and the status will update automatically. Codacy didn't analyze the commit on a private repository because the committer doesn't belong to the Codacy organization. Make sure that you add all committers to your Codacy organization . Codacy skipped analyzing the commit because there are more recent commits in the branch. Upload coverage data for the most recent commit in the branch. The setting Run analysis on your build server is on, but your client-side tools didn't upload results to Codacy. Make sure that your client-side tools run successfully and upload the results to Codacy to complete the analysis. Codacy ran into an error while analyzing the commit. Solve the issue that caused the analysis to fail (such as Codacy losing access to the repository ), or contact us at support@codacy.com asking for help. Final report not sent # Codacy is waiting to receive more coverage data before reporting the coverage for a commit. What causes the error? How to fix the error? Coverage was uploaded with the --partial flag but Codacy didn't receive the final notification. Make sure that after uploading all partial reports you send the final notification . Pending # Codacy is waiting to receive valid coverage data for the files in your repository. What causes the error? How to fix the error? The file paths in the coverage report don't match the ones on the repository Files page on Codacy. Make sure that the file paths included in your coverage report are relative to the root directory of your repository. For example, src/index.js . The uploaded coverage data only includes information for files that are ignored on Codacy . Check which files are ignored on Codacy and make sure that you're generating coverage reports for the correct files in your repository. The uploaded coverage data is incorrectly associated, using the -l option, to a language that's not present in your repository. Verify that you are associating the correct language, or don't specify a language to let Codacy detect the contents of the coverage reports automatically. See how to upload coverage in advanced scenarios for more information. Check that Codacy displays the coverage metrics for the latest commits and pull requests. If Codacy can't calculate the coverage metrics for pull requests, make sure that you're uploading coverage data for the following commits of the pull request: Commit Required to calculate the coverage metrics Head commit of the pull request branch Coverage variation Diff coverage Common ancestor commit of the pull request and target branches Coverage variation The following diagram highlights the commits that must receive coverage data for Codacy to calculate the coverage metrics for pull requests: Click View logs on a pull request detail page to see the SHA-1 hashes of the commits that are missing coverage data. If you have many open pull requests, you can also use a script to identify if any pull requests are missing coverage data . Need help? If you need help setting up coverage on your repository please contact us at support@codacy.com including the following information: URL of your repository on Codacy Your CI/CD configuration files and the name of your CI/CD platform Full console output of your CI/CD when running the Codacy Coverage Reporter Branch name and commit SHA-1 hash corresponding to the CI/CD output Test coverage report that you're uploading to Codacy Any other relevant information or screenshots of your setup See also # Identifying commits without coverage data Why does Codacy show unexpected coverage changes?", "title": "Adding coverage to your repository"}, {"location": "coverage-reporter/#adding-coverage-to-your-repository", "text": "Code coverage is a metric used to describe the degree to which the source code of a program is tested. A program with high code coverage has been more thoroughly tested and has a lower chance of containing software bugs than a program with low code coverage. You can read more about the basics of code coverage on Codacy's blog. To monitor the code coverage of your repository on Codacy you must generate coverage reports for each commit on your CI/CD workflow, and then upload the coverage data to Codacy. Complete these main steps to set up coverage for your repository: Generating coverage reports Ensure that you're generating one of the code coverage report formats supported by Codacy on each push to your repository. Uploading coverage data to Codacy After each push to your repository, run the Codacy Coverage Reporter to parse your report file and upload the coverage data to Codacy. Validating that the coverage setup is complete Check if Codacy displays the coverage metrics for new commits and pull requests and troubleshoot the coverage setup if necessary. The next sections include detailed instructions on how to complete each step of the setup process.", "title": "Adding coverage to your repository"}, {"location": "coverage-reporter/#generating-coverage", "text": "Before setting up Codacy to display code coverage metrics for your repository you must have tests and use tools to generate coverage reports for the source code files in your repository. Consider the following when generating coverage reports for your repository: There are many tools that you can use to generate coverage reports, but you must ensure that the coverage reports are in one of the formats that Codacy supports If your repository includes multiple programming languages, you may need to generate a separate coverage report for each language depending on the specific languages and tools that you use Make sure that you generate coverage reports that include coverage data for all tested source code files in your repository and not just the files that were changed in each commit The following table contains example coverage tools that generate reports in formats that Codacy supports: Language Example coverage tools Report files C# OpenCover opencover.xml (OpenCover) dotCover CLI dotcover.xml (dotCover detailedXML ) Coverlet Make sure that you output the report files in a supported format using one of the following file names: opencover.xml (OpenCover) cobertura.xml (Cobertura) lcov.info , lcov.dat , *.lcov (LCOV) Go Golang Code Coverage Golang report files don't have a specific name. Because of this, later in the setup process you must follow specific instructions while submitting coverage to Codacy. Java JaCoCo jacoco*.xml (JaCoCo) Cobertura cobertura.xml (Cobertura) JavaScript Istanbul Mocha + Blanket.js lcov.info , lcov.dat , *.lcov (LCOV) PHP PHPUnit coverage-xml/index.xml (PHPUnit XML version <= 4) clover.xml (Clover) Python Coverage.py cobertura.xml (Cobertura) Ruby SimpleCov cobertura.xml (Cobertura) lcov.info , lcov.dat , *.lcov (LCOV) Scala sbt-jacoco jacoco*.xml (JaCoCo) scoverage cobertura.xml (Cobertura) Swift/Objective-C Xcode Code Coverage See below how to generate coverage reports with Xcode", "title": "1. Generating coverage reports"}, {"location": "coverage-reporter/#uploading-coverage", "text": "After having coverage reports set up for your repository, you must use the Codacy Coverage Reporter to upload them to Codacy. The recommended way to do this is by using a CI/CD platform that automatically runs tests, generates coverage, and then uses the Codacy Coverage Reporter to upload the coverage report information to Codacy. Important Please note that Codacy needs to receive coverage data for: Every push to your repository including merge commits or any commits created automatically by tools such as Dependabot All tested files in your repository including the files that weren't changed in the commit, or files from unchanged modules in a monorepo setup Alternative ways of running the Codacy Coverage Reporter Codacy makes available alternative ways to run the Codacy Coverage Reporter , such as by installing the binary manually or by using Docker, a GitHub Action, or a CircleCI Orb. However, the instructions on this page assume that you'll run the recommended self-contained bash script get.sh to automatically download and run the most recent version of the Codacy Coverage Reporter. Set up an API token to allow Codacy Coverage Reporter to authenticate on Codacy: If you're setting up coverage for one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up and automating coverage for multiple repositories , obtain an account API Token and set the following environment variables: CODACY_API_TOKEN: Your account API token. CODACY_ORGANIZATION_PROVIDER: Git provider hosting the repository. Must be one of gh , ghe , gl , gle , bb , or bbe to specify GitHub, GitHub Enterprise, GitLab, GitLab Enterprise, Bitbucket, or Bitbucket Enterprise, respectively. CODACY_USERNAME: Name of your organization on the Git provider, or your username on the Git provider if you're using a personal organization. CODACY_PROJECT_NAME: Name of the repository for which you're uploading the coverage data. export CODACY_API_TOKEN = export CODACY_ORGANIZATION_PROVIDER = export CODACY_USERNAME = export CODACY_PROJECT_NAME = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variables to specify your Codacy instance URL and the Codacy Coverage Reporter version that's compatible with Codacy Self-hosted 14.0.0: export CODACY_API_BASE_URL = export CODACY_REPORTER_VERSION = 13 .10.15 Run Codacy Coverage Reporter on the root of the locally checked out branch of your Git repository , specifying the relative path to the coverage report to upload: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report -r Check the console output to validate that the Codacy Coverage Reporter detected the correct commit SHA-1 hash and successfully uploaded the coverage data to Codacy. If you need help, check the troubleshooting page for solutions to the most common issues while running the CLI. Note Be sure to also check the instructions for more advanced scenarios while uploading the coverage data to Codacy, such as when running parallel tests, using monorepos, or testing source code in multiple or unsupported languages.", "title": "2. Uploading coverage data to Codacy"}, {"location": "coverage-reporter/#validating-coverage", "text": "Codacy displays the code coverage in each branch, as well as the evolution of code coverage between commits and the code coverage variation introduced by pull requests. Because of this, to ensure that all code coverage metrics are available on Codacy, you must have successfully uploaded coverage data and analyzed: The last two commits in each branch The common ancestor commit of each pull request branch and its target branch Example The example below shows that after pushing a commit that correctly sets up coverage on the default branch: Codacy will report coverage metrics for all subsequent commits and pull requests relative to the default branch. Codacy won't report coverage metrics for commits and pull requests that are relative to older branches where the coverage setup wasn't performed yet. To solve this issue, you can rebase the old feature branch to update the common ancestor commit to one that already has coverage data. Follow these instructions to validate that your coverage setup is working correctly: On Codacy, open your Repository Settings , tab Coverage , and observe the list of the most recent 50 coverage reports in the section Test your integration . Make sure that Codacy receives and processes the coverage data successfully for at least two commits . If there are commits with a status different from Processed , please follow the troubleshooting instructions for the corresponding error status and click the button Test integration to display any new coverage reports uploaded to Codacy.", "title": "3. Validating that the coverage setup is complete"}, {"location": "coverage-reporter/#see-also", "text": "Identifying commits without coverage data Why does Codacy show unexpected coverage changes?", "title": "See also"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/", "text": "Alternative ways of running Coverage Reporter # The following sections list the alternative ways of running or installing Codacy Coverage Reporter. Important If you're using Codacy Self-hosted 14.0.0 you must use Codacy Coverage Reporter 13.10.15 to ensure it's compatible with your Codacy instance. Bash script (recommended) # The recommended way to run the Codacy Coverage Reporter is by using the self-contained bash script get.sh that automatically downloads and runs the most recent version of the Codacy Coverage Reporter: On Ubuntu, run: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report -r On Alpine Linux, run: wget -qO - https://coverage.codacy.com/get.sh | sh -s -- report -r Note Starting on version 13.0.0 the script automatically validates the checksum of the downloaded binary. To skip the checksum validation, define the following environment variable: export CODACY_REPORTER_SKIP_CHECKSUM = true The self-contained script can cache the binary. To avoid downloading the binary every time that the script runs, add one of the following directories to your CI cached folders: $HOME/.cache/codacy on Linux $HOME/Library/Caches/Codacy on Mac OS X To use a specific version of the Codacy Coverage Reporter, set the following environment variable to one of the released versions : export CODACY_REPORTER_VERSION = Docker # You can use Docker to run Codacy Coverage Reporter. Use the following command where is either one of the released versions , or latest to use the most recent version: docker run -v $PWD :/code codacy/codacy-coverage-reporter: report GitHub Action # If you're using GitHub Actions to report coverage, you can use our GitHub Action codacy/codacy-coverage-reporter-action . CircleCI orb # If you're using CircleCI to report coverage, you can use our orb codacy/coverage-reporter . Manually downloading the binary # Linux amd64 # If you prefer, you can manually download and run the native codacy-coverage-reporter binary, either for the latest version or a specific one. You can use the scripts below to automatically check for the latest version of the binaries, download the binaries from either Codacy's public store or GitHub, and run them. Using Codacy's public S3: LATEST_VERSION = \" $( curl -Ls https://artifacts.codacy.com/bin/codacy-coverage-reporter/latest ) \" curl -Ls -o codacy-coverage-reporter \"https://artifacts.codacy.com/bin/codacy-coverage-reporter/ ${ LATEST_VERSION } /codacy-coverage-reporter-linux\" chmod +x codacy-coverage-reporter ./codacy-coverage-reporter report Using GitHub: curl -Ls -o codacy-coverage-reporter \" $( curl -Ls https://api.github.com/repos/codacy/codacy-coverage-reporter/releases/latest | jq -r '.assets | map({name, browser_download_url} | select(.name | contains(\"codacy-coverage-reporter-linux\"))) | .[0].browser_download_url' ) \" chmod +x codacy-coverage-reporter ./codacy-coverage-reporter report Java # Use the Java binary to run Codacy Coverage reporter on other platforms, such as Linux x86, macOS, Windows, etc. You can use the scripts below to automatically check for the latest version of the Java binaries, download the binaries from either Codacy's public store or GitHub, and run them. Using Codacy's public store: LATEST_VERSION = \" $( curl -Ls https://artifacts.codacy.com/bin/codacy-coverage-reporter/latest ) \" curl -Ls -o codacy-coverage-reporter-assembly.jar \"https://artifacts.codacy.com/bin/codacy-coverage-reporter/ ${ LATEST_VERSION } /codacy-coverage-reporter-assembly.jar\" java -jar codacy-coverage-reporter-assembly.jar report Using GitHub: curl -LS -o codacy-coverage-reporter-assembly.jar \" $( curl -LSs https://api.github.com/repos/codacy/codacy-coverage-reporter/releases/latest | jq -r '.assets | map({name, browser_download_url} | select(.name | endswith(\".jar\"))) | .[0].browser_download_url' ) \" java -jar codacy-coverage-reporter-assembly.jar report Validating the checksum of the binaries # You can use the checksums available for each release to validate the binaries that you download manually. You can use any tool of your choice to validate the checksum, as long as it uses the SHA512 algorithm. For example, run the commands below to download and validate the checksum for the 13.0.0 Linux binary. Note that the command sha512sum expects to find the binary on the same directory and with the original name codacy-coverage-reporter-linux . curl -Ls -O https://github.com/codacy/codacy-coverage-reporter/releases/download/13.0.0/codacy-coverage-reporter-linux.SHA512SUM sha512sum -c codacy-coverage-reporter-linux.SHA512SUM Building from source # If you are having any issues with your installation, you can also build the coverage reporter from source. Clone the Codacy Coverage Reporter repository: git clone https://github.com/codacy/codacy-coverage-reporter.git Run the command sbt assembly inside the local repository folder: cd codacy-coverage-reporter sbt assembly This will produce a file target/codacy-coverage-reporter-assembly-.jar that you can run. Execute this .jar in the repository where you want to upload the coverage. For example: /java-project$ java -jar ../codacy-coverage-reporter/target/codacy-coverage-reporter-assembly-.jar report Community supported alternatives # Maven plugin # Thanks to the amazing job of Gavin Mogan you can now send your coverage to Codacy using his Maven plugin halkeye/codacy-maven-plugin ! Be sure to follow the instructions on his repository. Travis CI # If you are using Travis CI to report coverage, update your file .travis.yml to include the following blocks: before_script : - bash <(curl -Ls https://coverage.codacy.com/get.sh) download after_success : - bash <(curl -Ls https://coverage.codacy.com/get.sh) Make sure that you also set your project or account API Token as an environment variable in your Travis CI job. Gradle task # If you're using Gradle to automate your CI/CD you can add use the following example task, where is the name of the task that generates your coverage report: task uploadCoverage ( type: Exec , dependsOn: < COVERAGE_REPORT_TASK >) { description 'Uploads coverage data to Codacy.' commandLine 'bash' , '-c' , 'bash <(curl -Ls https://coverage.codacy.com/get.sh) report' }", "title": "Alternative ways of running Coverage Reporter"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#alternative-ways-of-running-coverage-reporter", "text": "The following sections list the alternative ways of running or installing Codacy Coverage Reporter. Important If you're using Codacy Self-hosted 14.0.0 you must use Codacy Coverage Reporter 13.10.15 to ensure it's compatible with your Codacy instance.", "title": "Alternative ways of running Coverage Reporter"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#bash-script", "text": "The recommended way to run the Codacy Coverage Reporter is by using the self-contained bash script get.sh that automatically downloads and runs the most recent version of the Codacy Coverage Reporter: On Ubuntu, run: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report -r On Alpine Linux, run: wget -qO - https://coverage.codacy.com/get.sh | sh -s -- report -r Note Starting on version 13.0.0 the script automatically validates the checksum of the downloaded binary. To skip the checksum validation, define the following environment variable: export CODACY_REPORTER_SKIP_CHECKSUM = true The self-contained script can cache the binary. To avoid downloading the binary every time that the script runs, add one of the following directories to your CI cached folders: $HOME/.cache/codacy on Linux $HOME/Library/Caches/Codacy on Mac OS X To use a specific version of the Codacy Coverage Reporter, set the following environment variable to one of the released versions : export CODACY_REPORTER_VERSION = ", "title": "Bash script (recommended)"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#docker", "text": "You can use Docker to run Codacy Coverage Reporter. Use the following command where is either one of the released versions , or latest to use the most recent version: docker run -v $PWD :/code codacy/codacy-coverage-reporter: report", "title": "Docker"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#github-action", "text": "If you're using GitHub Actions to report coverage, you can use our GitHub Action codacy/codacy-coverage-reporter-action .", "title": "GitHub Action"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#circleci-orb", "text": "If you're using CircleCI to report coverage, you can use our orb codacy/coverage-reporter .", "title": "CircleCI orb"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#manually-downloading-the-binary", "text": "", "title": "Manually downloading the binary"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#building-from-source", "text": "If you are having any issues with your installation, you can also build the coverage reporter from source. Clone the Codacy Coverage Reporter repository: git clone https://github.com/codacy/codacy-coverage-reporter.git Run the command sbt assembly inside the local repository folder: cd codacy-coverage-reporter sbt assembly This will produce a file target/codacy-coverage-reporter-assembly-.jar that you can run. Execute this .jar in the repository where you want to upload the coverage. For example: /java-project$ java -jar ../codacy-coverage-reporter/target/codacy-coverage-reporter-assembly-.jar report", "title": "Building from source"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#community-supported-alternatives", "text": "", "title": "Community supported alternatives"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/", "text": "Troubleshooting coverage CLI issues # The sections below provide instructions or workarounds to overcome common issues while using Codacy Coverage Reporter CLI: Can't guess any report due to no matching Can't validate checksum Commit SHA-1 hash detection Connect timed out while uploading coverage data coverage-xml/index.xml generated an empty result JsonParseException while uploading coverage data MalformedInputException while parsing report No coverage data was sent Report generated an empty result while uploading C# coverage data SubstrateSegfaultHandler caught signal 11 Can't guess any report due to no matching # Codacy Coverage Reporter automatically searches for coverage reports matching the file name conventions for supported formats . However, if Codacy Coverage Reporter doesn't find your coverage report, you can explicitly define the report file name with the flag -r . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report -r Can't validate checksum # Starting on version 13.0.0 the get.sh script automatically validates the checksum of the downloaded Codacy Coverage Reporter binary. This requires having either the sha512sum or shasum command on the operating system where you're running the script. If you're getting this error while uploading your coverage data to Codacy, install the correct version of sha512sum or shasum for the operating system that you're using. You can also skip validating the checksum of the binary by defining the following environment variable, however, Codacy doesn't recommend this: export CODACY_REPORTER_SKIP_CHECKSUM = true Commit SHA-1 hash detection # The Codacy Coverage Reporter automatically detects the SHA-1 hash of the current commit to associate with the coverage data when you're using one of the following CI/CD platforms: Appveyor Argo CD AWS CodeBuild Azure Pipelines Bitrise Buildkite Circle CI Codefresh Codeship Docker GitLab Greenhouse CI Heroku CI Jenkins Magnum CI Semaphore CI Shippable CI Solano CI TeamCity CI Travis CI Wercker CI If the Codacy Coverage Reporter fails to detect the current commit from the CI workflow context, it will use the current commit from the local Git repository instead. However, you can also force using a specific commit SHA-1 hash with the flag --commit-uuid . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -r report.xml \\ --commit-uuid cd4d000083a744cf1617d46af4ec108b79e06bed Connect timed out while uploading coverage data # If you get a Error doing a post to <...> connect timed out error while uploading your coverage data to Codacy it means that the Codacy Coverage Reporter is timing out while connecting to the Codacy API. This typically happens if you're uploading coverage data for larger repositories. To increase the default timeout while connecting to the Codacy API, use the flag --http-timeout to set a value larger than 10000 milliseconds. For example, to set the timeout to 30 seconds: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -r report.xml \\ --http-timeout 30000 coverage-xml/index.xml generated an empty result # If you're using PHPUnit version 5 or above to generate your coverage report, you must output the report using the Clover format. Codacy Coverage Reporter supports the PHPUnit XML format only for versions 4 and older. To change the output format replace the flag --coverage-xml with --coverage-clover when executing phpunit . See PHPUnit command-line documentation for more information. JsonParseException while uploading coverage data # If you get a com.fasterxml.jackson.core.JsonParseException error while uploading your coverage data to Codacy it means that your coverage report is too big and that Codacy Coverage Reporter hit a limit of 10 MB when uploading the coverage data to Codacy. There are some ways you can solve this: Split your coverage reports into smaller files and upload them to Codacy one at a time . If you're using dotCover to generate coverage reports for your C# projects , you should exclude xUnit files from the coverage analysis as follows: dotCover.exe cover <...> /Filters = -:xunit* By default, dotCover includes xUnit files in the coverage analysis and this results in larger coverage reports. This filter helps ensure that the resulting coverage data doesn't exceed the size limit accepted by the Codacy API when uploading the results. MalformedInputException while parsing report # If you get a java.nio.charset.MalformedInputException when running the Codacy Coverage Reporter it means that the coverage report includes a character that's not encoded in UTF-8. The invalid character can belong to the file name of one of your source code files, or even a class or method name. For maximum compatibility of your coverage reports with the Codacy Coverage Reporter, make sure that your coverage reports use UTF-8 encoding and that they only include UTF-8 characters. No coverage data was sent # You can get the No coverage data was sent error when running the Codacy Coverage Reporter for the following reasons: The coverage report doesn't include any coverage data. The coverage report only includes data for files that don't exist in the associated Git repository. In this case, you also get one or more warnings File: [filename] will be discarded and will not be considered for coverage calculation . Make sure that your coverage report isn't empty and that it includes coverage data for files in the associated Git repository. Note If you upload multiple coverage reports and at least one contains valid data, the Codacy Coverage Reporter uploads the valid reports and ignores the invalid ones. Report generated an empty result while uploading C# coverage data # If you're using dotCover to generate coverage reports for your C# projects, you must use the dotCover detailedXML report format as follows: dotCover.exe cover <...> --reportType = DetailedXml SubstrateSegfaultHandler caught signal 11 # If you're experiencing segmentation faults when uploading the coverage results due to oracle/graal#624 , execute the following command before running the reporter, as a workaround: echo \" $( dig +short api.codacy.com | tail -n1 ) api.codacy.com\" >> /etc/hosts", "title": "Troubleshooting coverage CLI issues"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#troubleshooting-coverage-cli-issues", "text": "The sections below provide instructions or workarounds to overcome common issues while using Codacy Coverage Reporter CLI: Can't guess any report due to no matching Can't validate checksum Commit SHA-1 hash detection Connect timed out while uploading coverage data coverage-xml/index.xml generated an empty result JsonParseException while uploading coverage data MalformedInputException while parsing report No coverage data was sent Report generated an empty result while uploading C# coverage data SubstrateSegfaultHandler caught signal 11", "title": "Troubleshooting coverage CLI issues"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#cant-guess-any-report-due-to-no-matching", "text": "Codacy Coverage Reporter automatically searches for coverage reports matching the file name conventions for supported formats . However, if Codacy Coverage Reporter doesn't find your coverage report, you can explicitly define the report file name with the flag -r . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report -r ", "title": "Can't guess any report due to no matching"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#checksum", "text": "Starting on version 13.0.0 the get.sh script automatically validates the checksum of the downloaded Codacy Coverage Reporter binary. This requires having either the sha512sum or shasum command on the operating system where you're running the script. If you're getting this error while uploading your coverage data to Codacy, install the correct version of sha512sum or shasum for the operating system that you're using. You can also skip validating the checksum of the binary by defining the following environment variable, however, Codacy doesn't recommend this: export CODACY_REPORTER_SKIP_CHECKSUM = true", "title": "Can't validate checksum"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#commit-detection", "text": "The Codacy Coverage Reporter automatically detects the SHA-1 hash of the current commit to associate with the coverage data when you're using one of the following CI/CD platforms: Appveyor Argo CD AWS CodeBuild Azure Pipelines Bitrise Buildkite Circle CI Codefresh Codeship Docker GitLab Greenhouse CI Heroku CI Jenkins Magnum CI Semaphore CI Shippable CI Solano CI TeamCity CI Travis CI Wercker CI If the Codacy Coverage Reporter fails to detect the current commit from the CI workflow context, it will use the current commit from the local Git repository instead. However, you can also force using a specific commit SHA-1 hash with the flag --commit-uuid . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -r report.xml \\ --commit-uuid cd4d000083a744cf1617d46af4ec108b79e06bed", "title": "Commit SHA-1 hash detection"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#connect-timed-out-while-uploading-coverage-data", "text": "If you get a Error doing a post to <...> connect timed out error while uploading your coverage data to Codacy it means that the Codacy Coverage Reporter is timing out while connecting to the Codacy API. This typically happens if you're uploading coverage data for larger repositories. To increase the default timeout while connecting to the Codacy API, use the flag --http-timeout to set a value larger than 10000 milliseconds. For example, to set the timeout to 30 seconds: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -r report.xml \\ --http-timeout 30000", "title": "Connect timed out while uploading coverage data"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#coverage-xmlindexxml-generated-an-empty-result", "text": "If you're using PHPUnit version 5 or above to generate your coverage report, you must output the report using the Clover format. Codacy Coverage Reporter supports the PHPUnit XML format only for versions 4 and older. To change the output format replace the flag --coverage-xml with --coverage-clover when executing phpunit . See PHPUnit command-line documentation for more information.", "title": "coverage-xml/index.xml generated an empty result"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#jsonparseexception-while-uploading-coverage-data", "text": "If you get a com.fasterxml.jackson.core.JsonParseException error while uploading your coverage data to Codacy it means that your coverage report is too big and that Codacy Coverage Reporter hit a limit of 10 MB when uploading the coverage data to Codacy. There are some ways you can solve this: Split your coverage reports into smaller files and upload them to Codacy one at a time . If you're using dotCover to generate coverage reports for your C# projects , you should exclude xUnit files from the coverage analysis as follows: dotCover.exe cover <...> /Filters = -:xunit* By default, dotCover includes xUnit files in the coverage analysis and this results in larger coverage reports. This filter helps ensure that the resulting coverage data doesn't exceed the size limit accepted by the Codacy API when uploading the results.", "title": "JsonParseException while uploading coverage data"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#malformedinputexception-while-parsing-report", "text": "If you get a java.nio.charset.MalformedInputException when running the Codacy Coverage Reporter it means that the coverage report includes a character that's not encoded in UTF-8. The invalid character can belong to the file name of one of your source code files, or even a class or method name. For maximum compatibility of your coverage reports with the Codacy Coverage Reporter, make sure that your coverage reports use UTF-8 encoding and that they only include UTF-8 characters.", "title": "MalformedInputException while parsing report"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#no-coverage-data-was-sent", "text": "You can get the No coverage data was sent error when running the Codacy Coverage Reporter for the following reasons: The coverage report doesn't include any coverage data. The coverage report only includes data for files that don't exist in the associated Git repository. In this case, you also get one or more warnings File: [filename] will be discarded and will not be considered for coverage calculation . Make sure that your coverage report isn't empty and that it includes coverage data for files in the associated Git repository. Note If you upload multiple coverage reports and at least one contains valid data, the Codacy Coverage Reporter uploads the valid reports and ignores the invalid ones.", "title": "No coverage data was sent"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#detailedxml", "text": "If you're using dotCover to generate coverage reports for your C# projects, you must use the dotCover detailedXML report format as follows: dotCover.exe cover <...> --reportType = DetailedXml", "title": "Report generated an empty result while uploading C# coverage data"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#substratesegfaulthandler-caught-signal-11", "text": "If you're experiencing segmentation faults when uploading the coverage results due to oracle/graal#624 , execute the following command before running the reporter, as a workaround: echo \" $( dig +short api.codacy.com | tail -n1 ) api.codacy.com\" >> /etc/hosts", "title": "SubstrateSegfaultHandler caught signal 11"}, {"location": "coverage-reporter/uploading-coverage-in-advanced-scenarios/", "text": "Uploading coverage in advanced scenarios # The following sections include instructions on how to use the Codacy Coverage Reporter to upload coverage data in more advanced scenarios. Uploading multiple coverage reports for the same language # If your test suite is split into different modules or runs in parallel, you must upload multiple coverage reports for the same language either at once or in sequence. Alternatively, consider merging multiple coverage reports before uploading them to Codacy. Most coverage tools support merging or aggregating coverage data. For example, use the merge mojo for JaCoCo . Note If one or more coverage reports mark a line as covered multiple times, Codacy counts it as a single covered line when calculating coverage. Uploading all reports at once # Upload multiple partial coverage reports with a single command by specifying each report with the flag -r . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -l Java -r report1.xml -r report2.xml -r report3.xml You can also upload all your reports dynamically using the command find . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -l Java $( find . -name 'jacoco*.xml' | sed 's,^, -r ,' | xargs echo ) Uploading reports in sequence # Upload multiple partial coverage reports in sequence: Upload each report separately with the flag --partial . If you're sending reports for a language with the flag --partial , you must use the flag in all reports for that language to ensure the correct calculation of the coverage. Notify Codacy with the final command after uploading all reports. For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --partial -l Java -r report1.xml bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --partial -l Java -r report2.xml bash < ( curl -Ls https://coverage.codacy.com/get.sh ) final Uploading the same coverage report for multiple languages # If your test suite generates a single coverage report for more than one language, you must upload the same coverage report for each language. To do this, upload the same report multiple times, specifying each different language with the flag -l . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --partial -l Javascript -r report.xml bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --partial -l TypeScript -r report.xml bash < ( curl -Ls https://coverage.codacy.com/get.sh ) final Uploading coverage for Golang # Codacy can't automatically detect Golang coverage report files because they don't have specific file names. If you're uploading a Golang coverage report, you must also specify the report type: go test -coverprofile = unit.coverage.out ./... bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --force-coverage-parser go -r unit.coverage.out Uploading coverage for unsupported languages # If your language isn't in the list of supported languages , you can still send coverage to Codacy. To do this, provide the correct language with the flag -l , together with --force-language . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -l Kotlin --force-language -r See the list of languages that you can specify using the flag -l .", "title": "Uploading coverage in advanced scenarios"}, {"location": "coverage-reporter/uploading-coverage-in-advanced-scenarios/#uploading-coverage-in-advanced-scenarios", "text": "The following sections include instructions on how to use the Codacy Coverage Reporter to upload coverage data in more advanced scenarios.", "title": "Uploading coverage in advanced scenarios"}, {"location": "coverage-reporter/uploading-coverage-in-advanced-scenarios/#multiple-reports", "text": "If your test suite is split into different modules or runs in parallel, you must upload multiple coverage reports for the same language either at once or in sequence. Alternatively, consider merging multiple coverage reports before uploading them to Codacy. Most coverage tools support merging or aggregating coverage data. For example, use the merge mojo for JaCoCo . Note If one or more coverage reports mark a line as covered multiple times, Codacy counts it as a single covered line when calculating coverage.", "title": "Uploading multiple coverage reports for the same language"}, {"location": "coverage-reporter/uploading-coverage-in-advanced-scenarios/#multiple-languages", "text": "If your test suite generates a single coverage report for more than one language, you must upload the same coverage report for each language. To do this, upload the same report multiple times, specifying each different language with the flag -l . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --partial -l Javascript -r report.xml bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --partial -l TypeScript -r report.xml bash < ( curl -Ls https://coverage.codacy.com/get.sh ) final", "title": "Uploading the same coverage report for multiple languages"}, {"location": "coverage-reporter/uploading-coverage-in-advanced-scenarios/#golang", "text": "Codacy can't automatically detect Golang coverage report files because they don't have specific file names. If you're uploading a Golang coverage report, you must also specify the report type: go test -coverprofile = unit.coverage.out ./... bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --force-coverage-parser go -r unit.coverage.out", "title": "Uploading coverage for Golang"}, {"location": "coverage-reporter/uploading-coverage-in-advanced-scenarios/#unsupported-languages", "text": "If your language isn't in the list of supported languages , you can still send coverage to Codacy. To do this, provide the correct language with the flag -l , together with --force-language . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -l Kotlin --force-language -r See the list of languages that you can specify using the flag -l .", "title": "Uploading coverage for unsupported languages"}, {"location": "faq/code-analysis/can-i-bypass-codacy-status-check/", "text": "Can I bypass Codacy status check? # To protect your code from unwelcome changes, you can configure your Git workflow to block merging pull requests if they don't pass the Codacy status check. However, on very specific and exceptional situations where your pull request merging is blocked due to an unexpected issue not related to the quality of your code, Codacy allows repository admins to bypass the Codacy status check for that pull request. To bypass Codacy status check for a pull request, a repository admin must click Bypass status checks on the pull request status area of the pull request detail screen.", "title": "Can I bypass Codacy status check?"}, {"location": "faq/code-analysis/can-i-bypass-codacy-status-check/#can-i-bypass-codacy-status-check", "text": "To protect your code from unwelcome changes, you can configure your Git workflow to block merging pull requests if they don't pass the Codacy status check. However, on very specific and exceptional situations where your pull request merging is blocked due to an unexpected issue not related to the quality of your code, Codacy allows repository admins to bypass the Codacy status check for that pull request. To bypass Codacy status check for a pull request, a repository admin must click Bypass status checks on the pull request status area of the pull request detail screen.", "title": "Can I bypass Codacy status check?"}, {"location": "faq/code-analysis/does-codacy-check-for-dependencies/", "text": "Does Codacy check for dependencies? # Yes, Codacy scans the manifest files of your repositories and displays any vulnerable dependencies as Codacy issues. For a list of supported languages and manifest files scanned by the Codacy dependency vulnerability scanning tools, see Supported languages and tools .", "title": "Does Codacy check for dependencies?"}, {"location": "faq/code-analysis/does-codacy-check-for-dependencies/#does-codacy-check-for-dependencies", "text": "Yes, Codacy scans the manifest files of your repositories and displays any vulnerable dependencies as Codacy issues. For a list of supported languages and manifest files scanned by the Codacy dependency vulnerability scanning tools, see Supported languages and tools .", "title": "Does Codacy check for dependencies?"}, {"location": "faq/code-analysis/does-codacy-place-limits-on-the-code-analysis/", "text": "Does Codacy place limits on the code analysis? # Codacy uses limits when performing the analysis of your repositories to ensure good performance levels and avoid degradation of service during peak load. The following table describes these limits and includes links to more information and workarounds, if available: Limit Value Rationale File size 150 KB Large source code files are typically generated by or dependent on a third-party, and could significantly delay the analysis. See Why is my file over 150 KB missing? File size for coverage reports 10 MB Codacy doesn't parse code coverage reports that are over the file size limit. See JsonParseException while uploading coverage data Number of files for duplication 5000 Some tools fail to calculate duplication or time out when analyzing a number of files above this number. See Why aren't duplication metrics being calculated? Number of issues per file and per tool 50 Codacy limits the number of issues returned on each file by individual tools as a safeguard against degradation of performance on large or unexpected use cases. This means that in some situations Codacy could report more issues after a push that includes fixes for the currently reported issues. Number of comments on the Git provider 25 Codacy limits the number of comments for reporting found issues on pull requests to avoid triggering too many notification emails and to guard against hitting API rate limits. Showing issues on duplicated lines - For now, Codacy only reports the first code issue when there are issues on duplicated lines on the same file. If you believe that you may have hit any of these limits and need help to overcome them, please contact us at support@codacy.com . See also # Which metrics does Codacy calculate?", "title": "Does Codacy place limits on the code analysis?"}, {"location": "faq/code-analysis/does-codacy-place-limits-on-the-code-analysis/#does-codacy-place-limits-on-the-code-analysis", "text": "Codacy uses limits when performing the analysis of your repositories to ensure good performance levels and avoid degradation of service during peak load. The following table describes these limits and includes links to more information and workarounds, if available: Limit Value Rationale File size 150 KB Large source code files are typically generated by or dependent on a third-party, and could significantly delay the analysis. See Why is my file over 150 KB missing? File size for coverage reports 10 MB Codacy doesn't parse code coverage reports that are over the file size limit. See JsonParseException while uploading coverage data Number of files for duplication 5000 Some tools fail to calculate duplication or time out when analyzing a number of files above this number. See Why aren't duplication metrics being calculated? Number of issues per file and per tool 50 Codacy limits the number of issues returned on each file by individual tools as a safeguard against degradation of performance on large or unexpected use cases. This means that in some situations Codacy could report more issues after a push that includes fixes for the currently reported issues. Number of comments on the Git provider 25 Codacy limits the number of comments for reporting found issues on pull requests to avoid triggering too many notification emails and to guard against hitting API rate limits. Showing issues on duplicated lines - For now, Codacy only reports the first code issue when there are issues on duplicated lines on the same file. If you believe that you may have hit any of these limits and need help to overcome them, please contact us at support@codacy.com .", "title": "Does Codacy place limits on the code analysis?"}, {"location": "faq/code-analysis/does-codacy-place-limits-on-the-code-analysis/#see-also", "text": "Which metrics does Codacy calculate?", "title": "See also"}, {"location": "faq/code-analysis/how-long-does-it-take-for-my-repository-to-be-analyzed/", "text": "How long does it take for my repository to be analyzed? # Codacy usually takes under 5 minutes to analyze your repository. It may however take longer, depending on a number of factors: Whether it's the initial analysis of your repository The initial analysis examines all files in the repository, while each subsequent commit triggers an analysis only on files changed in that commit. Whether tool configurations have been updated Updates to tool configurations trigger a reanalysis of all files in the repository on the next commit and may impact analysis duration. The size of your repository To speed up the analysis, ignore any files and directories that aren't relevant to your project, such as generated code or any third-party libraries included in your repositories. The time it takes your Git provider to trigger the analysis Codacy relies on post-commit hooks sent by your Git provider to trigger the analysis after each push to the repository, so if your analysis is taking a lot of time to start check that the Post-Commit Hook integration for your repository is enabled . The priority of your analysis request and the current load on Codacy's servers Open-source projects have lower priority in the Codacy analysis queues. Whether Codacy or your Git provider is currently experiencing issues or outages Check the Codacy status page and the status page of your Git provider ( GitHub , GitLab , Bitbucket ) to see if there is any ongoing incident that could delay the analysis.", "title": "How long does it take for my repository to be analyzed?"}, {"location": "faq/code-analysis/how-long-does-it-take-for-my-repository-to-be-analyzed/#how-long-does-it-take-for-my-repository-to-be-analyzed", "text": "Codacy usually takes under 5 minutes to analyze your repository. It may however take longer, depending on a number of factors: Whether it's the initial analysis of your repository The initial analysis examines all files in the repository, while each subsequent commit triggers an analysis only on files changed in that commit. Whether tool configurations have been updated Updates to tool configurations trigger a reanalysis of all files in the repository on the next commit and may impact analysis duration. The size of your repository To speed up the analysis, ignore any files and directories that aren't relevant to your project, such as generated code or any third-party libraries included in your repositories. The time it takes your Git provider to trigger the analysis Codacy relies on post-commit hooks sent by your Git provider to trigger the analysis after each push to the repository, so if your analysis is taking a lot of time to start check that the Post-Commit Hook integration for your repository is enabled . The priority of your analysis request and the current load on Codacy's servers Open-source projects have lower priority in the Codacy analysis queues. Whether Codacy or your Git provider is currently experiencing issues or outages Check the Codacy status page and the status page of your Git provider ( GitHub , GitLab , Bitbucket ) to see if there is any ongoing incident that could delay the analysis.", "title": "How long does it take for my repository to be analyzed?"}, {"location": "faq/code-analysis/how-to-configure-php-codesniffer-coding-standards/", "text": "How to configure PHP_CodeSniffer coding standards? # By default, Codacy uses the PHP_CodeSniffer configuration on the Code patterns page when analyzing your repositories. To enforce a specific PHP_CodeSniffer coding standard you must create a configuration file on the root of your repository that references one or more of the following coding standards: Default coding standards packaged together with PHP_CodeSniffer: https://github.com/squizlabs/PHP_CodeSniffer/tree/master/src/Standards Additional coding standards that Codacy packages on the PHP_CodeSniffer tool plugin. Check the repository the additional coding standards to learn how you can reference them in your configuration files: https://github.com/codacy/codacy-codesniffer/blob/master/composer.json For example, create a text file with the name phpcs.xml to use the PSR12 coding standard but excluding the sniffs Generic.WhiteSpace.DisallowTabIndent and PSR12.Operators.OperatorSpacing : PHP_CodeSniffer configuration See also # Check these external resources for more help on customizing your PHP_CodeSniffer configuration: PHP_CodeSniffer configuration file syntax PHP Coding Standard Generator", "title": "How to configure PHP_CodeSniffer coding standards?"}, {"location": "faq/code-analysis/how-to-configure-php-codesniffer-coding-standards/#how-to-configure-php_codesniffer-coding-standards", "text": "By default, Codacy uses the PHP_CodeSniffer configuration on the Code patterns page when analyzing your repositories. To enforce a specific PHP_CodeSniffer coding standard you must create a configuration file on the root of your repository that references one or more of the following coding standards: Default coding standards packaged together with PHP_CodeSniffer: https://github.com/squizlabs/PHP_CodeSniffer/tree/master/src/Standards Additional coding standards that Codacy packages on the PHP_CodeSniffer tool plugin. Check the repository the additional coding standards to learn how you can reference them in your configuration files: https://github.com/codacy/codacy-codesniffer/blob/master/composer.json For example, create a text file with the name phpcs.xml to use the PSR12 coding standard but excluding the sniffs Generic.WhiteSpace.DisallowTabIndent and PSR12.Operators.OperatorSpacing : PHP_CodeSniffer configuration ", "title": "How to configure PHP_CodeSniffer coding standards?"}, {"location": "faq/code-analysis/how-to-configure-php-codesniffer-coding-standards/#see-also", "text": "Check these external resources for more help on customizing your PHP_CodeSniffer configuration: PHP_CodeSniffer configuration file syntax PHP Coding Standard Generator", "title": "See also"}, {"location": "faq/code-analysis/how-to-skip-an-analysis/", "text": "How to skip an analysis? # By default, Codacy automatically analyzes a repository whenever you push changes. However, you can override this behavior by adding one of the \"skip\" tags - [ci skip] , [skip ci] , [codacy skip] or [skip codacy] - anywhere in the subject or body of the commit message. For example: git commit -a -m \"Add eslint-plugin-chai-expect version 1.1.1 [ci skip]\" If you later decide to analyze a skipped commit, you can override any skip tags by reanalyzing the commit . Note This feature isn't supported for pull requests.", "title": "How to skip an analysis?"}, {"location": "faq/code-analysis/how-to-skip-an-analysis/#how-to-skip-an-analysis", "text": "By default, Codacy automatically analyzes a repository whenever you push changes. However, you can override this behavior by adding one of the \"skip\" tags - [ci skip] , [skip ci] , [codacy skip] or [skip codacy] - anywhere in the subject or body of the commit message. For example: git commit -a -m \"Add eslint-plugin-chai-expect version 1.1.1 [ci skip]\" If you later decide to analyze a skipped commit, you can override any skip tags by reanalyzing the commit . Note This feature isn't supported for pull requests.", "title": "How to skip an analysis?"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/", "text": "Which metrics does Codacy calculate? # Codacy performs static code analysis and calculates code duplication, code complexity, and code coverage metrics for most supported programming languages . The following sections describe how Codacy calculates each supported metric and where you can see each metric on the Codacy UI: Grade Issues Complexity Duplication Code coverage Note Depending on certain characteristics of your repository, such as the number of source code files and their size, Codacy may apply limits to the code analysis that impact the calculation of the supported metrics. Grade # Codacy assigns an overall grade to your repository branches and to individual files to help you assess the code quality of your repository. Grades represent a weighted average of the available code quality metrics (issues, complexity, duplication, and coverage), and range from A to F : Highest grade Lowest grade Codacy displays grades on the following places: Place Metric Files page Grade for each file in your repository Repository Dashboard Codacy badge Grade of each analyzed branch in your repository Email notifications Grade of your repository Organization overview Average grade of the repositories in your organization and grade of each repository Repositories list Grade of each repository in your organization Issues # Codacy calculates the number of issues in the following static code analysis categories: Code style: Code formatting and syntax problems, such as variable names style and enforcing the use of brackets and quotation marks Error prone: Code that may hide bugs and language keywords that should be used with caution, such as the operator == in JavaScript or Option.get in Scala Code complexity: High complexity methods and classes that should be refactored Performance: Code that can have performance problems Compatibility: Mainly for frontend code, compatibility problems across different browser versions Unused code: Unused variables and methods, code that can't be reached Security: Potential security vulnerabilities, including hard-coded passwords and keys (secret scanning), vulnerable dependencies (software composition analysis or SCA), and insecure code patterns (static application security testing or SAST). For more information, see the complete list of security issue categories Documentation: Methods and classes that don't have the correct comment annotations Best practice: Code that doesn't follow the recommended coding standards and best practices Comprehensibility: Code that can be difficult to understand and modify Besides this, Codacy also allows you to compare issues across repositories with different sizes by calculating the issue cost relative to a baseline of 1 point per line of code , where the cost of each issue depends on its severity: Critical = 10 points, Medium = 5 points, Minor = 1 point. This means that if your repository has 50% issues, the amount and severity of the issues in your repository is half of the baseline. Codacy displays issues on the following places: Place Metric Commit detail page Pull request detail page Email notifications Number of new and fixed issues introduced by the commit or pull request Files page Number of issues in each file Issues page List of all issues detected in each branch Repository Dashboard Issue percentage and how the metric is evolving over time Organization overview Average issue percentage of the repositories in your organization and issue percentage of each repository Repositories list page Issue percentage in each repository in your organization Complexity # Codacy uses cyclomatic complexity to identify files with complex methods in your repository. Cyclomatic complexity is the number of linearly independent paths through the source code of a method: the more control flow statements used in a method, the higher the value. Methods with a high cyclomatic complexity are more difficult to test and more likely to have defects. Learn more about code complexity on Codacy's blog. Codacy calculates complexity as follows: The complexity value for each file is the highest cyclomatic complexity of the methods in the file. A file is considered complex if its cyclomatic complexity value is higher than the threshold File is complex when over . The complexity value of a commit or pull request is the sum of the cyclomatic complexity of the files that were changed in the commit or pull request and that have a high complexity increase, defined as an increase of 4 or more. Codacy displays complexity on the following places: Place Metric Commit detail page Pull request detail page Email notifications Variation of the complexity value introduced by the commit or pull request Files page Complexity value of each file Repository Dashboard Percentage of complex files in your repository and how the metric is evolving over time Organization overview Average percentage of complex files in the repositories in your organization and percentage of complex files in each repository Repositories list page Percentage of complex files in each repository in your organization Duplication # Codacy identifies clones or sequences of duplicate code that exist in at least two different places of the source code of your repository. Clones typically indicate deeper code quality issues and should be eliminated through abstraction when possible. Codacy calculates duplication as follows: The duplication value for each file is the number of clones in the file. A file is considered duplicated if the number of clones in the file is higher than the threshold File is duplicated when over . The duplication value of a commit or pull request is the number of clones introduced by the commit or pull request. Note You can customize the rules for identifying duplicated blocks of code when using PMD CPD to analyze the source code of your repository. Codacy displays duplication on the following places: Place Metric Commit detail page Pull request detail page Email notifications Number of clones added or fixed by a commit or pull request Files page Duplication value of each file Repository Dashboard Percentage of duplicated files in your repository and how the metric is evolving over time Organization overview Average percentage of duplicated files in the repositories in your organization and percentage of complex files in each repository Repositories list page Percentage of duplicated files in each repository in your organization Code coverage # Code coverage describes the degree to which the source code of a program is tested. There are several types of coverage, but Codacy uses line coverage, which measures the percentage of coverable lines of code that are covered by automated tests. Learn more about code coverage on Codacy's blog. You must set up your CI/CD pipeline to upload code coverage data to Codacy . Because of this, the tool that you use to generate the coverage reports is responsible for creating the data that Codacy then uses to calculate code coverage. Codacy calculates code coverage as follows: The coverage value for each file is the percentage of coverable lines that are covered by tests in the file. If a line is covered multiple times, Codacy counts it as a single covered line when calculating coverage. A repository is considered to have acceptable coverage if the percentage of coverable lines that are covered by tests in the repository is higher than the threshold Coverage is under . The coverage variation of a commit or pull request is the increase or drop in the percentage of coverable lines that are covered by tests in the repository because of the changes of the commit or pull request. The diff coverage of a pull request is the percentage of coverable lines that the pull request added or modified that are covered by tests. If a pull request doesn't add or modify any coverable lines, the diff coverage is \u2205 (not applicable). This scenario happens when the only changes in a pull request are: Deleted lines Added or modified lines that aren't coverable Note If you encounter a situation where Codacy shows an unexpected drop in coverage, learn about the most common reasons causing those scenarios . Once the coverage setup is complete, Codacy displays coverage data on the following places: Place Metric Commit detail page Pull request detail page Email notifications Variation in percentage points of the coverage value for all files in the commit or pull request Pull request detail page Diff coverage for the changes included in the pull request Files page Coverage percentage of each file Repository Dashboard Coverage of the most recent commit of the selected branch and its evolution over time Codacy badge Coverage of the most recent commit of the configured branch Organization overview Average coverage of the repositories in your organization and coverage of each repository Repositories list page Coverage of each repository in your organization See also # Diff coverage: we have a new metric and quality gate rule for PRs Why does Codacy show unexpected coverage changes? Does Codacy place limits on the code analysis?", "title": "Which metrics does Codacy calculate?"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#which-metrics-does-codacy-calculate", "text": "Codacy performs static code analysis and calculates code duplication, code complexity, and code coverage metrics for most supported programming languages . The following sections describe how Codacy calculates each supported metric and where you can see each metric on the Codacy UI: Grade Issues Complexity Duplication Code coverage Note Depending on certain characteristics of your repository, such as the number of source code files and their size, Codacy may apply limits to the code analysis that impact the calculation of the supported metrics.", "title": "Which metrics does Codacy calculate?"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#grade", "text": "Codacy assigns an overall grade to your repository branches and to individual files to help you assess the code quality of your repository. Grades represent a weighted average of the available code quality metrics (issues, complexity, duplication, and coverage), and range from A to F : Highest grade Lowest grade Codacy displays grades on the following places: Place Metric Files page Grade for each file in your repository Repository Dashboard Codacy badge Grade of each analyzed branch in your repository Email notifications Grade of your repository Organization overview Average grade of the repositories in your organization and grade of each repository Repositories list Grade of each repository in your organization", "title": "Grade"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#issues", "text": "Codacy calculates the number of issues in the following static code analysis categories: Code style: Code formatting and syntax problems, such as variable names style and enforcing the use of brackets and quotation marks Error prone: Code that may hide bugs and language keywords that should be used with caution, such as the operator == in JavaScript or Option.get in Scala Code complexity: High complexity methods and classes that should be refactored Performance: Code that can have performance problems Compatibility: Mainly for frontend code, compatibility problems across different browser versions Unused code: Unused variables and methods, code that can't be reached Security: Potential security vulnerabilities, including hard-coded passwords and keys (secret scanning), vulnerable dependencies (software composition analysis or SCA), and insecure code patterns (static application security testing or SAST). For more information, see the complete list of security issue categories Documentation: Methods and classes that don't have the correct comment annotations Best practice: Code that doesn't follow the recommended coding standards and best practices Comprehensibility: Code that can be difficult to understand and modify Besides this, Codacy also allows you to compare issues across repositories with different sizes by calculating the issue cost relative to a baseline of 1 point per line of code , where the cost of each issue depends on its severity: Critical = 10 points, Medium = 5 points, Minor = 1 point. This means that if your repository has 50% issues, the amount and severity of the issues in your repository is half of the baseline. Codacy displays issues on the following places: Place Metric Commit detail page Pull request detail page Email notifications Number of new and fixed issues introduced by the commit or pull request Files page Number of issues in each file Issues page List of all issues detected in each branch Repository Dashboard Issue percentage and how the metric is evolving over time Organization overview Average issue percentage of the repositories in your organization and issue percentage of each repository Repositories list page Issue percentage in each repository in your organization", "title": "Issues"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#complexity", "text": "Codacy uses cyclomatic complexity to identify files with complex methods in your repository. Cyclomatic complexity is the number of linearly independent paths through the source code of a method: the more control flow statements used in a method, the higher the value. Methods with a high cyclomatic complexity are more difficult to test and more likely to have defects. Learn more about code complexity on Codacy's blog. Codacy calculates complexity as follows: The complexity value for each file is the highest cyclomatic complexity of the methods in the file. A file is considered complex if its cyclomatic complexity value is higher than the threshold File is complex when over . The complexity value of a commit or pull request is the sum of the cyclomatic complexity of the files that were changed in the commit or pull request and that have a high complexity increase, defined as an increase of 4 or more. Codacy displays complexity on the following places: Place Metric Commit detail page Pull request detail page Email notifications Variation of the complexity value introduced by the commit or pull request Files page Complexity value of each file Repository Dashboard Percentage of complex files in your repository and how the metric is evolving over time Organization overview Average percentage of complex files in the repositories in your organization and percentage of complex files in each repository Repositories list page Percentage of complex files in each repository in your organization", "title": "Complexity"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#duplication", "text": "Codacy identifies clones or sequences of duplicate code that exist in at least two different places of the source code of your repository. Clones typically indicate deeper code quality issues and should be eliminated through abstraction when possible. Codacy calculates duplication as follows: The duplication value for each file is the number of clones in the file. A file is considered duplicated if the number of clones in the file is higher than the threshold File is duplicated when over . The duplication value of a commit or pull request is the number of clones introduced by the commit or pull request. Note You can customize the rules for identifying duplicated blocks of code when using PMD CPD to analyze the source code of your repository. Codacy displays duplication on the following places: Place Metric Commit detail page Pull request detail page Email notifications Number of clones added or fixed by a commit or pull request Files page Duplication value of each file Repository Dashboard Percentage of duplicated files in your repository and how the metric is evolving over time Organization overview Average percentage of duplicated files in the repositories in your organization and percentage of complex files in each repository Repositories list page Percentage of duplicated files in each repository in your organization", "title": "Duplication"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#code-coverage", "text": "Code coverage describes the degree to which the source code of a program is tested. There are several types of coverage, but Codacy uses line coverage, which measures the percentage of coverable lines of code that are covered by automated tests. Learn more about code coverage on Codacy's blog. You must set up your CI/CD pipeline to upload code coverage data to Codacy . Because of this, the tool that you use to generate the coverage reports is responsible for creating the data that Codacy then uses to calculate code coverage. Codacy calculates code coverage as follows: The coverage value for each file is the percentage of coverable lines that are covered by tests in the file. If a line is covered multiple times, Codacy counts it as a single covered line when calculating coverage. A repository is considered to have acceptable coverage if the percentage of coverable lines that are covered by tests in the repository is higher than the threshold Coverage is under . The coverage variation of a commit or pull request is the increase or drop in the percentage of coverable lines that are covered by tests in the repository because of the changes of the commit or pull request. The diff coverage of a pull request is the percentage of coverable lines that the pull request added or modified that are covered by tests. If a pull request doesn't add or modify any coverable lines, the diff coverage is \u2205 (not applicable). This scenario happens when the only changes in a pull request are: Deleted lines Added or modified lines that aren't coverable Note If you encounter a situation where Codacy shows an unexpected drop in coverage, learn about the most common reasons causing those scenarios . Once the coverage setup is complete, Codacy displays coverage data on the following places: Place Metric Commit detail page Pull request detail page Email notifications Variation in percentage points of the coverage value for all files in the commit or pull request Pull request detail page Diff coverage for the changes included in the pull request Files page Coverage percentage of each file Repository Dashboard Coverage of the most recent commit of the selected branch and its evolution over time Codacy badge Coverage of the most recent commit of the configured branch Organization overview Average coverage of the repositories in your organization and coverage of each repository Repositories list page Coverage of each repository in your organization", "title": "Code coverage"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#see-also", "text": "Diff coverage: we have a new metric and quality gate rule for PRs Why does Codacy show unexpected coverage changes? Does Codacy place limits on the code analysis?", "title": "See also"}, {"location": "faq/code-analysis/why-does-codacy-show-unexpected-coverage-changes/", "text": "Why does Codacy show unexpected coverage changes? # You may encounter some situations where Codacy shows unexpected drops in coverage, potentially causing your quality gates to fail. Usually, these drops in coverage happen in files that the commit or pull request didn't change. There are multiple reasons for this, but it's important to understand that each coverage report that you upload to Codacy contains information about which lines of code in your repository are tested or not in a specific commit. In particular, each coverage report provides the following information about the lines of your source code files: Coverable lines (lines that can be tested), by listing those lines Covered lines (lines that were tested at least once), by marking those lines as tested or having a number of test hits Not coverable lines (lines that can't be tested), by not listing those lines For example, the coverage report represented below includes coverage information for two source code files: File ClassA.java has two coverable lines and all are covered by tests File ClassB.java has three coverable lines but only line 1 is covered by tests File Line number Covered by tests? ClassA.java 2 Yes 4 Yes ClassB.java 1 Yes 3 No 11 No Based on the information obtained from the coverage reports, Codacy calculates code coverage as follows: The coverage for a file, commit, or pull request is the percentage of covered lines in the universe of coverable lines for that file, commit, or pull request. For example, a commit with 85 covered lines out of a total of 100 coverable lines has 85% coverage. The coverage variation of a commit or pull request is the increase or drop in the percentage of coverable lines that are covered by tests in the repository because of the changes of the commit or pull request. The diff coverage of a pull request is the percentage of coverable lines that the pull request added or modified that are covered by tests. If a pull request doesn't add or modify any coverable lines, the diff coverage is \u2205 (not applicable). This scenario happens when the only changes in a pull request are: Deleted lines Added or modified lines that aren't coverable Important Note that changes external to a source code file can affect the lines that are or aren't covered in that file. Common reasons for unexpected coverage changes # There are several reasons that could cause Codacy to report unexpected coverage results, from changes to your source code to external factors. The following is a non-exhaustive list of the most common reasons: Adding new tests or removing existing tests from your project. Even small and localized changes to your tests can have an impact on the amount of covered lines across your repository. Changing the logic of your application or tests. Changing the control flow of your application or tests can mean that different areas of your code start or stop being covered by tests. For example, inverting the result of the Boolean expression of an if statement means that a different branch of your code could now be tested. Failing to upload coverage reports, or uploading a different number of reports between commits. This can be caused by a failed step in your CI/CD pipeline, for example. In the case of pull requests, you should make sure that you upload all relevant coverage reports for both the common ancestor commit and the head commit of the pull request branch. Ignoring files on Codacy. Updating the list of ignored files can have an impact on the amount of coverable and covered lines of the commits that Codacy compares to calculate the coverage variation metric. External factors affecting the execution of tests. A variety of factors that are external to your code can affect the execution of tests and, consequently, the results contained in the coverage reports. A few examples of these external factors are: Updates to dependencies of your project that could result in different test execution paths Misconfiguration of repository secrets that could prevent some test execution paths Tests that are dependent on time, such as running test cases only on specific dates or times of the day \"Flaky\" tests caused by any inconsistent or unreliable behavior of your code, infrastructure, or third-party services The examples below describe in more detail how specific changes in your code impact the coverage metrics that Codacy calculates. Example: Diff coverage is 100% but pull request coverage variation is negative # Consider an example pull request where Codacy shows the following metrics: 100% diff coverage A negative coverage variation There are two possible scenarios that could cause this result: Removing covered lines or tests Since diff coverage only applies to covered lines that the pull request added or modified, removed lines don't affect the diff coverage metric. However, removing covered lines or tests means that there are now less covered lines in the repository, causing a drop in coverage. Application logic changes A change in the flow of execution of your application or tests can mean that a different number of coverable lines in your repository are now covered by tests, causing a drop in coverage. However, if all lines modified in the pull request continue to be covered, the diff coverage metric is 100%. The table below represents two example coverage reports reflecting a pull request that causes line 1 of the file ClassB.java to stop being covered: Common ancestor commit Head commit File Line number Covered by tests? Line number Covered by tests? ClassA.java 2 Yes 2 Yes 4 Yes 4 Yes ClassB.java 1 Yes 1 No 3 No 3 No 11 No 11 No The table below displays the code coverage metrics as calculated by Codacy: Initially, ClassB.java was 33.33% covered but after the changes from the pull request the file is now 0% covered, causing the repository coverage to drop 20% As long as the pull request also modified any covered line that continues to be covered, the diff coverage is 100% Common ancestor commit Head commit Pull request results File Coverable lines Covered lines Coverage Coverable lines Covered lines Coverage Coverage variation Diff coverage ClassA.java 2 2 100% 2 2 100% 0% ClassB.java 3 1 33.33% 3 0 0% -33.33% Total 5 3 60% 5 2 40% -20% 100% Example: Pull request coverage variation is negative but no files have coverage variation # Consider an example pull request where Codacy shows the following metrics: Negative coverage variation There aren't any files with coverage variation Removing covered lines from a file that had 100% coverage means that the file will continue to have 100% coverage. All lines in the file continue to be covered, even though there are now less covered lines. As such, there is no coverage variation for the file. However, since the proportion between the total number of covered and coverable lines across all files in the repository is now different, there can be a drop in the coverage variation for the pull request. Important If you're using the gate Coverage variation is under , configure at least a -0.10% coverage variation margin to ensure that developers aren't blocked while performing code refactors such as the one from this example. The table below represents two example coverage reports reflecting a pull request that removes lines 5 and 6 of the file ClassA.java : Common ancestor commit Head commit File Line number Covered by tests? Line number Covered by tests? ClassA.java 2 Yes 2 Yes 4 Yes 4 Yes 5 Yes 6 Yes ClassB.java 1 Yes 1 Yes 3 No 3 No 11 No 11 No The table below displays the code coverage metrics as calculated by Codacy: Initially, ClassA.java was 100% covered and continues to be 100% covered after the pull request, causing the coverage variation for the file to be 0% However, there were 62.5% lines covered across all files in the repository but after the pull request only 60% of the lines are now covered, causing the pull request coverage variation to drop 2.5% Common ancestor commit Head commit Pull request results File Coverable lines Covered lines Coverage Coverable lines Covered lines Coverage Coverage variation ClassA.java 4 4 100% 2 2 100% 0% ClassB.java 3 1 33.33% 3 1 33.33% 0% Total 7 5 62.5% 5 3 60% -2.5% See also # Which metrics does Codacy calculate? Adding coverage to your repository /*Center text*/ .center { text-align: center !important; } /*Right border*/ th.border { border-right: 1px solid white; } .border { border-right: 1px solid var(--md-default-fg-color--light); } /*Red background*/ .background-red { background-color: #ffe6e6; } /*Green text*/ .text-green { color: #21c178; } /*Red text*/ .text-red { color: #ef5454; }", "title": "Why does Codacy show unexpected coverage changes?"}, {"location": "faq/code-analysis/why-does-codacy-show-unexpected-coverage-changes/#why-does-codacy-show-unexpected-coverage-changes", "text": "You may encounter some situations where Codacy shows unexpected drops in coverage, potentially causing your quality gates to fail. Usually, these drops in coverage happen in files that the commit or pull request didn't change. There are multiple reasons for this, but it's important to understand that each coverage report that you upload to Codacy contains information about which lines of code in your repository are tested or not in a specific commit. In particular, each coverage report provides the following information about the lines of your source code files: Coverable lines (lines that can be tested), by listing those lines Covered lines (lines that were tested at least once), by marking those lines as tested or having a number of test hits Not coverable lines (lines that can't be tested), by not listing those lines For example, the coverage report represented below includes coverage information for two source code files: File ClassA.java has two coverable lines and all are covered by tests File ClassB.java has three coverable lines but only line 1 is covered by tests File Line number Covered by tests? ClassA.java 2 Yes 4 Yes ClassB.java 1 Yes 3 No 11 No Based on the information obtained from the coverage reports, Codacy calculates code coverage as follows: The coverage for a file, commit, or pull request is the percentage of covered lines in the universe of coverable lines for that file, commit, or pull request. For example, a commit with 85 covered lines out of a total of 100 coverable lines has 85% coverage. The coverage variation of a commit or pull request is the increase or drop in the percentage of coverable lines that are covered by tests in the repository because of the changes of the commit or pull request. The diff coverage of a pull request is the percentage of coverable lines that the pull request added or modified that are covered by tests. If a pull request doesn't add or modify any coverable lines, the diff coverage is \u2205 (not applicable). This scenario happens when the only changes in a pull request are: Deleted lines Added or modified lines that aren't coverable Important Note that changes external to a source code file can affect the lines that are or aren't covered in that file.", "title": "Why does Codacy show unexpected coverage changes?"}, {"location": "faq/code-analysis/why-does-codacy-show-unexpected-coverage-changes/#common-reasons-for-unexpected-coverage-changes", "text": "There are several reasons that could cause Codacy to report unexpected coverage results, from changes to your source code to external factors. The following is a non-exhaustive list of the most common reasons: Adding new tests or removing existing tests from your project. Even small and localized changes to your tests can have an impact on the amount of covered lines across your repository. Changing the logic of your application or tests. Changing the control flow of your application or tests can mean that different areas of your code start or stop being covered by tests. For example, inverting the result of the Boolean expression of an if statement means that a different branch of your code could now be tested. Failing to upload coverage reports, or uploading a different number of reports between commits. This can be caused by a failed step in your CI/CD pipeline, for example. In the case of pull requests, you should make sure that you upload all relevant coverage reports for both the common ancestor commit and the head commit of the pull request branch. Ignoring files on Codacy. Updating the list of ignored files can have an impact on the amount of coverable and covered lines of the commits that Codacy compares to calculate the coverage variation metric. External factors affecting the execution of tests. A variety of factors that are external to your code can affect the execution of tests and, consequently, the results contained in the coverage reports. A few examples of these external factors are: Updates to dependencies of your project that could result in different test execution paths Misconfiguration of repository secrets that could prevent some test execution paths Tests that are dependent on time, such as running test cases only on specific dates or times of the day \"Flaky\" tests caused by any inconsistent or unreliable behavior of your code, infrastructure, or third-party services The examples below describe in more detail how specific changes in your code impact the coverage metrics that Codacy calculates.", "title": "Common reasons for unexpected coverage changes"}, {"location": "faq/code-analysis/why-does-codacy-show-unexpected-coverage-changes/#example-diff-coverage-is-100-but-pull-request-coverage-variation-is-negative", "text": "Consider an example pull request where Codacy shows the following metrics: 100% diff coverage A negative coverage variation There are two possible scenarios that could cause this result: Removing covered lines or tests Since diff coverage only applies to covered lines that the pull request added or modified, removed lines don't affect the diff coverage metric. However, removing covered lines or tests means that there are now less covered lines in the repository, causing a drop in coverage. Application logic changes A change in the flow of execution of your application or tests can mean that a different number of coverable lines in your repository are now covered by tests, causing a drop in coverage. However, if all lines modified in the pull request continue to be covered, the diff coverage metric is 100%. The table below represents two example coverage reports reflecting a pull request that causes line 1 of the file ClassB.java to stop being covered: Common ancestor commit Head commit File Line number Covered by tests? Line number Covered by tests? ClassA.java 2 Yes 2 Yes 4 Yes 4 Yes ClassB.java 1 Yes 1 No 3 No 3 No 11 No 11 No The table below displays the code coverage metrics as calculated by Codacy: Initially, ClassB.java was 33.33% covered but after the changes from the pull request the file is now 0% covered, causing the repository coverage to drop 20% As long as the pull request also modified any covered line that continues to be covered, the diff coverage is 100% Common ancestor commit Head commit Pull request results File Coverable lines Covered lines Coverage Coverable lines Covered lines Coverage Coverage variation Diff coverage ClassA.java 2 2 100% 2 2 100% 0% ClassB.java 3 1 33.33% 3 0 0% -33.33% Total 5 3 60% 5 2 40% -20% 100%", "title": "Example: Diff coverage is 100% but pull request coverage variation is negative"}, {"location": "faq/code-analysis/why-does-codacy-show-unexpected-coverage-changes/#example-pull-request-coverage-variation-is-negative-but-no-files-have-coverage-variation", "text": "Consider an example pull request where Codacy shows the following metrics: Negative coverage variation There aren't any files with coverage variation Removing covered lines from a file that had 100% coverage means that the file will continue to have 100% coverage. All lines in the file continue to be covered, even though there are now less covered lines. As such, there is no coverage variation for the file. However, since the proportion between the total number of covered and coverable lines across all files in the repository is now different, there can be a drop in the coverage variation for the pull request. Important If you're using the gate Coverage variation is under , configure at least a -0.10% coverage variation margin to ensure that developers aren't blocked while performing code refactors such as the one from this example. The table below represents two example coverage reports reflecting a pull request that removes lines 5 and 6 of the file ClassA.java : Common ancestor commit Head commit File Line number Covered by tests? Line number Covered by tests? ClassA.java 2 Yes 2 Yes 4 Yes 4 Yes 5 Yes 6 Yes ClassB.java 1 Yes 1 Yes 3 No 3 No 11 No 11 No The table below displays the code coverage metrics as calculated by Codacy: Initially, ClassA.java was 100% covered and continues to be 100% covered after the pull request, causing the coverage variation for the file to be 0% However, there were 62.5% lines covered across all files in the repository but after the pull request only 60% of the lines are now covered, causing the pull request coverage variation to drop 2.5% Common ancestor commit Head commit Pull request results File Coverable lines Covered lines Coverage Coverable lines Covered lines Coverage Coverage variation ClassA.java 4 4 100% 2 2 100% 0% ClassB.java 3 1 33.33% 3 1 33.33% 0% Total 7 5 62.5% 5 3 60% -2.5%", "title": "Example: Pull request coverage variation is negative but no files have coverage variation"}, {"location": "faq/code-analysis/why-does-codacy-show-unexpected-coverage-changes/#see-also", "text": "Which metrics does Codacy calculate? Adding coverage to your repository /*Center text*/ .center { text-align: center !important; } /*Right border*/ th.border { border-right: 1px solid white; } .border { border-right: 1px solid var(--md-default-fg-color--light); } /*Red background*/ .background-red { background-color: #ffe6e6; } /*Green text*/ .text-green { color: #21c178; } /*Red text*/ .text-red { color: #ef5454; }", "title": "See also"}, {"location": "faq/general/does-codacy-keep-audit-logs/", "text": "Does Codacy keep audit logs for my organization? # On Business plan , Codacy logs significant organization events that can be retrieved for audit reporting. See Audit logs for organizations for the complete list of events that Codacy logs, and how to obtain audit log data.", "title": "Does Codacy keep audit logs for my organization?"}, {"location": "faq/general/does-codacy-keep-audit-logs/#does-codacy-keep-audit-logs-for-my-organization", "text": "On Business plan , Codacy logs significant organization events that can be retrieved for audit reporting. See Audit logs for organizations for the complete list of events that Codacy logs, and how to obtain audit log data.", "title": "Does Codacy keep audit logs for my organization?"}, {"location": "faq/general/how-can-i-change-or-cancel-my-plan/", "text": "How can I change or cancel my plan? # You can change or cancel your Codacy plan at any time. If you choose to cancel your annual subscription before the conclusion of the 12 months, your account will continue to work for the remainder of the annual billing period. Codacy values feedback and we thank you in advance for letting us know the primary reason behind your decision to leave, whether budgetary constraints or missing deal-breaker functionality. If you're using Codacy Cloud # If you're using Codacy Cloud see how to change the plan and billing of your Codacy organization . Alternatively, delete your organization to remove all its repositories from Codacy and cancel your existing plan. Note If you're using GitHub Marketplace, update your billing details or cancel your plan directly on your GitHub Billing page . If you cancel your plan or switch to a different Enterprise plan, some repositories may show outdated information in the Codacy UI. To update this information, reanalyze the repositories or push new commits. If you're using Codacy Self-hosted # To help you understand how you're consuming your licensed Codacy seats, use codacy-usage-report to obtain details about the activity of the users in your Codacy Self-hosted instance. If you decide to cancel your plan, please contact support@codacy.com and we'll swiftly process the cancellation. See also # Changing your plan and billing", "title": "How can I change or cancel my plan?"}, {"location": "faq/general/how-can-i-change-or-cancel-my-plan/#how-can-i-change-or-cancel-my-plan", "text": "You can change or cancel your Codacy plan at any time. If you choose to cancel your annual subscription before the conclusion of the 12 months, your account will continue to work for the remainder of the annual billing period. Codacy values feedback and we thank you in advance for letting us know the primary reason behind your decision to leave, whether budgetary constraints or missing deal-breaker functionality.", "title": "How can I change or cancel my plan?"}, {"location": "faq/general/how-can-i-change-or-cancel-my-plan/#if-youre-using-codacy-cloud", "text": "If you're using Codacy Cloud see how to change the plan and billing of your Codacy organization . Alternatively, delete your organization to remove all its repositories from Codacy and cancel your existing plan. Note If you're using GitHub Marketplace, update your billing details or cancel your plan directly on your GitHub Billing page . If you cancel your plan or switch to a different Enterprise plan, some repositories may show outdated information in the Codacy UI. To update this information, reanalyze the repositories or push new commits.", "title": "If you're using Codacy Cloud"}, {"location": "faq/general/how-can-i-change-or-cancel-my-plan/#if-youre-using-codacy-self-hosted", "text": "To help you understand how you're consuming your licensed Codacy seats, use codacy-usage-report to obtain details about the activity of the users in your Codacy Self-hosted instance. If you decide to cancel your plan, please contact support@codacy.com and we'll swiftly process the cancellation.", "title": "If you're using Codacy Self-hosted"}, {"location": "faq/general/how-can-i-change-or-cancel-my-plan/#see-also", "text": "Changing your plan and billing", "title": "See also"}, {"location": "faq/general/how-do-i-allowlist-codacy-cloud-on-my-git-provider/", "text": "How do I allowlist Codacy Cloud on my Git provider? # This is a paid feature If you require an additional layer of security and control on your Git provider, you can configure an allowlist containing the specific IP addresses that are able to access your Git repositories and resources. To allowlist Codacy Cloud on your Git provider: Send an email to success@codacy.com or directly to your CSM asking us to enable static IP addresses for your organization. Note Enabling static IPs for an organization is a paid feature . After receiving a confirmation that static IP addresses are active for your Codacy Cloud organization, add the following IP addresses to the allowlist on your Git provider: 34.254.123.99 18.203.76.9 The following are the instructions on how to allow IP addresses to access resources on each Git provider: GitHub Cloud: Managing allowed IP addresses for your organization GitLab Cloud: Restrict group access by IP address Bitbucket Cloud: Allowlisting IP addresses", "title": "How do I allowlist Codacy Cloud on my Git provider?"}, {"location": "faq/general/how-do-i-allowlist-codacy-cloud-on-my-git-provider/#how-do-i-allowlist-codacy-cloud-on-my-git-provider", "text": "This is a paid feature If you require an additional layer of security and control on your Git provider, you can configure an allowlist containing the specific IP addresses that are able to access your Git repositories and resources. To allowlist Codacy Cloud on your Git provider: Send an email to success@codacy.com or directly to your CSM asking us to enable static IP addresses for your organization. Note Enabling static IPs for an organization is a paid feature . After receiving a confirmation that static IP addresses are active for your Codacy Cloud organization, add the following IP addresses to the allowlist on your Git provider: 34.254.123.99 18.203.76.9 The following are the instructions on how to allow IP addresses to access resources on each Git provider: GitHub Cloud: Managing allowed IP addresses for your organization GitLab Cloud: Restrict group access by IP address Bitbucket Cloud: Allowlisting IP addresses", "title": "How do I allowlist Codacy Cloud on my Git provider?"}, {"location": "faq/general/how-does-codacy-keep-my-data-secure/", "text": "How does Codacy keep my data secure? # Keeping our customers' data protected at all times is our highest priority. This security overview provides a high-level overview of the security practices put in place to achieve that objective. Have questions or feedback? Feel free to reach out to us at security@codacy.com .", "title": "How does Codacy keep my data secure?"}, {"location": "faq/general/how-does-codacy-keep-my-data-secure/#how-does-codacy-keep-my-data-secure", "text": "Keeping our customers' data protected at all times is our highest priority. This security overview provides a high-level overview of the security practices put in place to achieve that objective. Have questions or feedback? Feel free to reach out to us at security@codacy.com .", "title": "How does Codacy keep my data secure?"}, {"location": "faq/general/how-does-codacy-protect-my-privacy/", "text": "How does Codacy protect my privacy? # In May 2018 the new \"General Data Protection Regulation\" ( GDPR ) came into effect. This regulation contains the most significant changes to European data privacy legislation in the last 20 years and gives you more control over your personal data and greater transparency on how it's used. At Codacy, keeping your personal data safe has always been a top priority and we took GDPR as another opportunity for us to strengthen this commitment to you. We've changed our data processing policies, operations, activities, and documentation as a response to GDPR and have updated our Privacy Policy to incorporate said changes and specifically reflect the new regulation. Below are some highlights of the updated policy: Transparency: We've reworded our privacy policy for better navigation and to make it easier to read. Our policy outlines the type of personal data we collect, how we collect and process the data, and for what purposes. It also explains how we store, transfer, and share personal data, and our data retention practices Control: Our policy now further explains the control you have over information about you and your online activities. At any time, you can request information, correction, deletion, or changes to your personal data or/and make changes yourself GDPR: We've included additional language to discuss rights for users located in the European Union (EU) If you have any questions on this, please email us at privacy@codacy.com or reach out through our live chat option.", "title": "How does Codacy protect my privacy?"}, {"location": "faq/general/how-does-codacy-protect-my-privacy/#how-does-codacy-protect-my-privacy", "text": "In May 2018 the new \"General Data Protection Regulation\" ( GDPR ) came into effect. This regulation contains the most significant changes to European data privacy legislation in the last 20 years and gives you more control over your personal data and greater transparency on how it's used. At Codacy, keeping your personal data safe has always been a top priority and we took GDPR as another opportunity for us to strengthen this commitment to you. We've changed our data processing policies, operations, activities, and documentation as a response to GDPR and have updated our Privacy Policy to incorporate said changes and specifically reflect the new regulation. Below are some highlights of the updated policy: Transparency: We've reworded our privacy policy for better navigation and to make it easier to read. Our policy outlines the type of personal data we collect, how we collect and process the data, and for what purposes. It also explains how we store, transfer, and share personal data, and our data retention practices Control: Our policy now further explains the control you have over information about you and your online activities. At any time, you can request information, correction, deletion, or changes to your personal data or/and make changes yourself GDPR: We've included additional language to discuss rights for users located in the European Union (EU) If you have any questions on this, please email us at privacy@codacy.com or reach out through our live chat option.", "title": "How does Codacy protect my privacy?"}, {"location": "faq/general/how-does-codacy-support-bitbucket-cloud/", "text": "How does Codacy support Bitbucket Cloud? # When you use Bitbucket Cloud to sign up or log into Codacy, the Bitbucket teams that you belong to will be available to be added as Organizations on Codacy. After adding a team: Codacy displays the list of all repositories in that team so that you can add them to Codacy as repositories to be analyzed The members of the team will be able to join or request to join Codacy If you have repositories that don't belong to any team, you can still add those on Codacy directly under My Repositories . Limitations # Currently, the integration between Codacy and Bitbucket Cloud has the following limitations: Users that are deleted from Bitbucket Cloud are not automatically removed from Codacy. These users must be manually removed from Codacy, namely to ensure that Codacy only bills seats corresponding to active users. Deleted teams and repositories are not automatically deleted from Codacy. However, you can manually delete the corresponding Organizations or repositories from Codacy. Renamed Team workspace IDs aren't automatically renamed on Codacy, causing Codacy to stop analyzing the repositories in those teams. You must click the button Synchronize in the settings of the corresponding Organization on Codacy to synchronize the workspace ID and resume the analysis of the repositories. Repositories that are moved between teams are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. Codacy only sends commit and pull request notification emails to the authors of the commits and pull requests. Codacy doesn't analyze pull requests submitted from forked repositories. See also # What are organizations", "title": "How does Codacy support Bitbucket Cloud?"}, {"location": "faq/general/how-does-codacy-support-bitbucket-cloud/#how-does-codacy-support-bitbucket-cloud", "text": "When you use Bitbucket Cloud to sign up or log into Codacy, the Bitbucket teams that you belong to will be available to be added as Organizations on Codacy. After adding a team: Codacy displays the list of all repositories in that team so that you can add them to Codacy as repositories to be analyzed The members of the team will be able to join or request to join Codacy If you have repositories that don't belong to any team, you can still add those on Codacy directly under My Repositories .", "title": "How does Codacy support Bitbucket Cloud?"}, {"location": "faq/general/how-does-codacy-support-bitbucket-cloud/#limitations", "text": "Currently, the integration between Codacy and Bitbucket Cloud has the following limitations: Users that are deleted from Bitbucket Cloud are not automatically removed from Codacy. These users must be manually removed from Codacy, namely to ensure that Codacy only bills seats corresponding to active users. Deleted teams and repositories are not automatically deleted from Codacy. However, you can manually delete the corresponding Organizations or repositories from Codacy. Renamed Team workspace IDs aren't automatically renamed on Codacy, causing Codacy to stop analyzing the repositories in those teams. You must click the button Synchronize in the settings of the corresponding Organization on Codacy to synchronize the workspace ID and resume the analysis of the repositories. Repositories that are moved between teams are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. Codacy only sends commit and pull request notification emails to the authors of the commits and pull requests. Codacy doesn't analyze pull requests submitted from forked repositories.", "title": "Limitations"}, {"location": "faq/general/how-does-codacy-support-bitbucket-cloud/#see-also", "text": "What are organizations", "title": "See also"}, {"location": "faq/general/how-does-codacy-support-bitbucket-server/", "text": "How does Codacy support Bitbucket Server? # When you use Bitbucket Server to sign up or log into Codacy, the Bitbucket projects that you belong to will be available to be added as Organizations on Codacy. After adding a project: Codacy displays the list of all repositories that you own in that project so that you can add them to Codacy as repositories to be analyzed The members of the project will be able to join or request to join Codacy Limitations # Currently, the integration between Codacy and Bitbucket Server has the following limitations: Users that are deleted from Bitbucket Server are not automatically removed from Codacy. These users must be manually removed from Codacy, namely to ensure that Codacy only bills seats corresponding to active users. Renamed project keys aren't automatically renamed on Codacy, causing Codacy to stop analyzing the repositories in those projects. You must click the button Synchronize in the settings of the corresponding Organization on Codacy to synchronize the project key and resume the analysis of the repositories. Deleted projects and repositories are not automatically deleted from Codacy. However, you can manually delete the corresponding Organizations or repositories from Codacy. Repositories that are moved between teams are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. Personal repositories are not supported. You can only add repositories to Codacy if they belong to a project. Codacy only sends commit and pull request notification emails to the authors of the commits and pull requests. Pull request summaries aren't available The Repositories screen doesn't include the \"Last updated\" date for each repository. As such, the repositories are sorted alphabetically. Codacy doesn't analyze pull requests submitted from forked repositories. See also # What are organizations", "title": "How does Codacy support Bitbucket Server?"}, {"location": "faq/general/how-does-codacy-support-bitbucket-server/#how-does-codacy-support-bitbucket-server", "text": "When you use Bitbucket Server to sign up or log into Codacy, the Bitbucket projects that you belong to will be available to be added as Organizations on Codacy. After adding a project: Codacy displays the list of all repositories that you own in that project so that you can add them to Codacy as repositories to be analyzed The members of the project will be able to join or request to join Codacy", "title": "How does Codacy support Bitbucket Server?"}, {"location": "faq/general/how-does-codacy-support-bitbucket-server/#limitations", "text": "Currently, the integration between Codacy and Bitbucket Server has the following limitations: Users that are deleted from Bitbucket Server are not automatically removed from Codacy. These users must be manually removed from Codacy, namely to ensure that Codacy only bills seats corresponding to active users. Renamed project keys aren't automatically renamed on Codacy, causing Codacy to stop analyzing the repositories in those projects. You must click the button Synchronize in the settings of the corresponding Organization on Codacy to synchronize the project key and resume the analysis of the repositories. Deleted projects and repositories are not automatically deleted from Codacy. However, you can manually delete the corresponding Organizations or repositories from Codacy. Repositories that are moved between teams are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. Personal repositories are not supported. You can only add repositories to Codacy if they belong to a project. Codacy only sends commit and pull request notification emails to the authors of the commits and pull requests. Pull request summaries aren't available The Repositories screen doesn't include the \"Last updated\" date for each repository. As such, the repositories are sorted alphabetically. Codacy doesn't analyze pull requests submitted from forked repositories.", "title": "Limitations"}, {"location": "faq/general/how-does-codacy-support-bitbucket-server/#see-also", "text": "What are organizations", "title": "See also"}, {"location": "faq/general/how-does-codacy-support-gitlab-cloud/", "text": "How does Codacy support GitLab Cloud? # When you use GitLab Cloud to sign up or log into Codacy, the GitLab Groups that you belong to will be available to be added as Organizations on Codacy. After adding a Group: Codacy displays the list of all repositories that you own in that Group and Subgroups so that you can add them to Codacy as repositories to be analyzed The members of the Group will be able to join or request to join Codacy If you have repositories that don't belong to any Group, you can still add those on Codacy by choosing your \"personal\" organization . Limitations # Currently, the integration between Codacy and GitLab Cloud has the following limitations: Users that are deleted from GitLab are not automatically removed from Codacy. These users must be manually removed from Codacy, namely to ensure that Codacy only bills seats corresponding to active users. Renamed Group paths aren't automatically renamed on Codacy, causing Codacy to stop analyzing the repositories in those groups. You must click the button Synchronize in the settings of the corresponding Organization on Codacy to synchronize the Group path and resume the analysis of the repositories. Deleted Groups are not automatically deleted from Codacy. However, you can manually delete the corresponding Organizations from Codacy. Repositories that are moved between Groups are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. It is not possible to add repositories with the same name to the Codacy organization. Repositories having the same name but belonging to different GitLab Subgroups would collide if they were added to the same Codacy organization. Codacy doesn't analyze pull requests submitted from forked repositories. Share projects with other groups isn't fully supported on Codacy. Users from the \"other groups\" can join the Organization that owns the project on the Codacy side, and Codacy will analyze the commits from those users. However, those users won't be able to access the project on the Codacy UI. See also # What are organizations", "title": "How does Codacy support GitLab Cloud?"}, {"location": "faq/general/how-does-codacy-support-gitlab-cloud/#how-does-codacy-support-gitlab-cloud", "text": "When you use GitLab Cloud to sign up or log into Codacy, the GitLab Groups that you belong to will be available to be added as Organizations on Codacy. After adding a Group: Codacy displays the list of all repositories that you own in that Group and Subgroups so that you can add them to Codacy as repositories to be analyzed The members of the Group will be able to join or request to join Codacy If you have repositories that don't belong to any Group, you can still add those on Codacy by choosing your \"personal\" organization .", "title": "How does Codacy support GitLab Cloud?"}, {"location": "faq/general/how-does-codacy-support-gitlab-cloud/#limitations", "text": "Currently, the integration between Codacy and GitLab Cloud has the following limitations: Users that are deleted from GitLab are not automatically removed from Codacy. These users must be manually removed from Codacy, namely to ensure that Codacy only bills seats corresponding to active users. Renamed Group paths aren't automatically renamed on Codacy, causing Codacy to stop analyzing the repositories in those groups. You must click the button Synchronize in the settings of the corresponding Organization on Codacy to synchronize the Group path and resume the analysis of the repositories. Deleted Groups are not automatically deleted from Codacy. However, you can manually delete the corresponding Organizations from Codacy. Repositories that are moved between Groups are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. It is not possible to add repositories with the same name to the Codacy organization. Repositories having the same name but belonging to different GitLab Subgroups would collide if they were added to the same Codacy organization. Codacy doesn't analyze pull requests submitted from forked repositories. Share projects with other groups isn't fully supported on Codacy. Users from the \"other groups\" can join the Organization that owns the project on the Codacy side, and Codacy will analyze the commits from those users. However, those users won't be able to access the project on the Codacy UI.", "title": "Limitations"}, {"location": "faq/general/how-does-codacy-support-gitlab-cloud/#see-also", "text": "What are organizations", "title": "See also"}, {"location": "faq/general/how-does-codacy-support-gitlab-enterprise/", "text": "How does Codacy support GitLab Enterprise? # When you use GitLab Enterprise to sign up or log into Codacy, the GitLab Groups that you belong to will be available to be added as Organizations on Codacy. After adding a Group: Codacy displays the list of all repositories that you own in that Group and Subgroups so that you can add them to Codacy as repositories to be analyzed The members of the Group will be able to join or request to join Codacy If you have repositories that don't belong to any Group, you can still add those on Codacy by choosing your \"personal\" organization . Limitations # Currently, the integration between Codacy and GitLab Enterprise has the following limitations: Repositories that are moved between Groups are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. It is not possible to add repositories with the same name to the Codacy organization. Repositories having the same name but belonging to different GitLab Subgroups would collide if they were added to the same Codacy organization. Codacy doesn't analyze pull requests submitted from forked repositories. Share projects with other groups isn't fully supported on Codacy. Users from the \"other groups\" can join the Organization that owns the project on the Codacy side, and Codacy will analyze the commits from those users. However, those users won't be able to access the project on the Codacy UI. See also # What are organizations", "title": "How does Codacy support GitLab Enterprise?"}, {"location": "faq/general/how-does-codacy-support-gitlab-enterprise/#how-does-codacy-support-gitlab-enterprise", "text": "When you use GitLab Enterprise to sign up or log into Codacy, the GitLab Groups that you belong to will be available to be added as Organizations on Codacy. After adding a Group: Codacy displays the list of all repositories that you own in that Group and Subgroups so that you can add them to Codacy as repositories to be analyzed The members of the Group will be able to join or request to join Codacy If you have repositories that don't belong to any Group, you can still add those on Codacy by choosing your \"personal\" organization .", "title": "How does Codacy support GitLab Enterprise?"}, {"location": "faq/general/how-does-codacy-support-gitlab-enterprise/#limitations", "text": "Currently, the integration between Codacy and GitLab Enterprise has the following limitations: Repositories that are moved between Groups are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. It is not possible to add repositories with the same name to the Codacy organization. Repositories having the same name but belonging to different GitLab Subgroups would collide if they were added to the same Codacy organization. Codacy doesn't analyze pull requests submitted from forked repositories. Share projects with other groups isn't fully supported on Codacy. Users from the \"other groups\" can join the Organization that owns the project on the Codacy side, and Codacy will analyze the commits from those users. However, those users won't be able to access the project on the Codacy UI.", "title": "Limitations"}, {"location": "faq/general/how-does-codacy-support-gitlab-enterprise/#see-also", "text": "What are organizations", "title": "See also"}, {"location": "faq/general/which-platforms-and-technologies-does-codacy-support/", "text": "Which platforms and technologies does Codacy support? # This page includes information about software platforms and technologies compatible with Codacy. Supported version control systems and Git providers # Codacy supports repositories from the following Git providers: Hosting model Name used on Codacy Required Codacy version GitHub GitHub.com GitHub Cloud Codacy Cloud or Codacy Self-hosted GitHub Enterprise Server version 3.6.2 or later GitHub Enterprise Codacy Self-hosted GitLab GitLab SaaS GitLab Cloud Codacy Cloud or Codacy Self-hosted GitLab Self-managed version 14.8 or later GitLab Enterprise Codacy Self-hosted Bitbucket Bitbucket Cloud Bitbucket Cloud Codacy Cloud or Codacy Self-hosted Bitbucket Data Center Bitbucket Server version 6.6.0 or later Bitbucket Server Codacy Self-hosted Note Although older versions of the self-hosted Git providers may work with Codacy without loss of functionality, Codacy will only fix issues and ensure compatibility with the versions listed above. Supported browsers # Codacy runs on every modern browser supporting HTML5 and CSS3: Chrome 67+ Firefox 45+ Internet Explorer 11+ Microsoft Edge 13+ Supported character encodings # Codacy supports the UTF-8 character encoding standard.", "title": "Which platforms and technologies does Codacy support?"}, {"location": "faq/general/which-platforms-and-technologies-does-codacy-support/#which-platforms-and-technologies-does-codacy-support", "text": "This page includes information about software platforms and technologies compatible with Codacy.", "title": "Which platforms and technologies does Codacy support?"}, {"location": "faq/general/which-platforms-and-technologies-does-codacy-support/#supported-version-control-systems-and-git-providers", "text": "Codacy supports repositories from the following Git providers: Hosting model Name used on Codacy Required Codacy version GitHub GitHub.com GitHub Cloud Codacy Cloud or Codacy Self-hosted GitHub Enterprise Server version 3.6.2 or later GitHub Enterprise Codacy Self-hosted GitLab GitLab SaaS GitLab Cloud Codacy Cloud or Codacy Self-hosted GitLab Self-managed version 14.8 or later GitLab Enterprise Codacy Self-hosted Bitbucket Bitbucket Cloud Bitbucket Cloud Codacy Cloud or Codacy Self-hosted Bitbucket Data Center Bitbucket Server version 6.6.0 or later Bitbucket Server Codacy Self-hosted Note Although older versions of the self-hosted Git providers may work with Codacy without loss of functionality, Codacy will only fix issues and ensure compatibility with the versions listed above.", "title": "Supported version control systems and Git providers"}, {"location": "faq/general/which-platforms-and-technologies-does-codacy-support/#supported-browsers", "text": "Codacy runs on every modern browser supporting HTML5 and CSS3: Chrome 67+ Firefox 45+ Internet Explorer 11+ Microsoft Edge 13+", "title": "Supported browsers"}, {"location": "faq/general/which-platforms-and-technologies-does-codacy-support/#supported-character-encodings", "text": "Codacy supports the UTF-8 character encoding standard.", "title": "Supported character encodings"}, {"location": "faq/repositories/how-do-i-reanalyze-my-repository/", "text": "How do I reanalyze my repository? # Organization admins can manage access to this feature Reanalyze the last commit in your branch or pull request: To update the Codacy analysis results taking into account the most recent configurations for your repository without waiting for a new commit to trigger the analysis If the grade or Codacy badge for your branch is greyed out and displays an exclamation mark, which means that the analysis information isn't available for the last commit of the branch: Important If you have the setting Run analysis on your build server enabled in your repository Settings page so that you can run client-side tools , you can't trigger a new analysis from the Codacy UI. Instead, you must manually run the client-side tools or wait for them to report the results for a new commit. You can only reanalyze commits to branches or pull requests in your repository if the committer is part of your organization . Reanalyzing a branch # To reanalyze a branch in your repository: Open the Commits page for your repository and select the correct branch at the top of the page if you configured Codacy to analyze multiple branches . Then, select the most recent commit for that branch at the top of the list: Click the Reanalyze link to trigger a reanalysis. Codacy will display the status of the reanalysis request. Reanalyzing a pull request # To reanalyze a pull request in your repository: Open the Pull Requests page for your repository and select the pull request that you want to reanalyze. Click the Reanalyze button to trigger a reanalysis. Codacy will display the status of the reanalysis request. See also # Commit status Pull request status", "title": "How do I reanalyze my repository?"}, {"location": "faq/repositories/how-do-i-reanalyze-my-repository/#how-do-i-reanalyze-my-repository", "text": "Organization admins can manage access to this feature Reanalyze the last commit in your branch or pull request: To update the Codacy analysis results taking into account the most recent configurations for your repository without waiting for a new commit to trigger the analysis If the grade or Codacy badge for your branch is greyed out and displays an exclamation mark, which means that the analysis information isn't available for the last commit of the branch: Important If you have the setting Run analysis on your build server enabled in your repository Settings page so that you can run client-side tools , you can't trigger a new analysis from the Codacy UI. Instead, you must manually run the client-side tools or wait for them to report the results for a new commit. You can only reanalyze commits to branches or pull requests in your repository if the committer is part of your organization .", "title": "How do I reanalyze my repository?"}, {"location": "faq/repositories/how-do-i-reanalyze-my-repository/#reanalyzing-a-branch", "text": "To reanalyze a branch in your repository: Open the Commits page for your repository and select the correct branch at the top of the page if you configured Codacy to analyze multiple branches . Then, select the most recent commit for that branch at the top of the list: Click the Reanalyze link to trigger a reanalysis. Codacy will display the status of the reanalysis request.", "title": "Reanalyzing a branch"}, {"location": "faq/repositories/how-do-i-reanalyze-my-repository/#reanalyzing-a-pull-request", "text": "To reanalyze a pull request in your repository: Open the Pull Requests page for your repository and select the pull request that you want to reanalyze. Click the Reanalyze button to trigger a reanalysis. Codacy will display the status of the reanalysis request.", "title": "Reanalyzing a pull request"}, {"location": "faq/repositories/how-do-i-reanalyze-my-repository/#see-also", "text": "Commit status Pull request status", "title": "See also"}, {"location": "faq/repositories/i-moved-my-repository-on-the-git-provider/", "text": "I moved my repository on the Git provider # Currently, Codacy doesn't automatically detect moves of repositories between two organizations. To ensure that Codacy continues to analyze a repository that was moved to another organization on your Git provider: Delete the repository from the original organization on Codacy, taking note of the settings for this repository Add the repository to the new organization on Codacy and reconfigure the repository with the same settings as the original one If you can't find your repository in the original Codacy organization or if you need more help with this process, please contact us at support@codacy.com .", "title": "I moved my repository on the Git provider"}, {"location": "faq/repositories/i-moved-my-repository-on-the-git-provider/#i-moved-my-repository-on-the-git-provider", "text": "Currently, Codacy doesn't automatically detect moves of repositories between two organizations. To ensure that Codacy continues to analyze a repository that was moved to another organization on your Git provider: Delete the repository from the original organization on Codacy, taking note of the settings for this repository Add the repository to the new organization on Codacy and reconfigure the repository with the same settings as the original one If you can't find your repository in the original Codacy organization or if you need more help with this process, please contact us at support@codacy.com .", "title": "I moved my repository on the Git provider"}, {"location": "faq/repositories/i-renamed-my-repository-on-the-git-provider/", "text": "I renamed my repository on the Git provider # If you changed the name or URL of your repository on your Git provider, you can update the name and URL of the repository on Codacy to point to the new location. This ensures that you won't lose historical data about your repository on Codacy. To rename your repository on Codacy, open the page Settings and click the button Update repository .", "title": "I renamed my repository on the Git provider"}, {"location": "faq/repositories/i-renamed-my-repository-on-the-git-provider/#i-renamed-my-repository-on-the-git-provider", "text": "If you changed the name or URL of your repository on your Git provider, you can update the name and URL of the repository on Codacy to point to the new location. This ensures that you won't lose historical data about your repository on Codacy. To rename your repository on Codacy, open the page Settings and click the button Update repository .", "title": "I renamed my repository on the Git provider"}, {"location": "faq/troubleshooting/error-line-endings/", "text": "Error caused by incompatible line endings # Codacy executes the git diff command when analyzing new commits and pull requests to identify the lines of code that were changed. Codacy then uses this information to display the issues that were caused by the changes introduced by the commits or pull requests. If you have files in your repository that use the carriage return (CR) as the line end control character, the command git diff doesn't correctly identify line endings in the changed files. Because of this, Codacy is unable to use the output of the command and the Diff step of your commit or pull request analysis logs will display the message An error occurred during this step. Please, retry your analysis or contact support . The CR line end control character was used by older Classic Mac OS systems, and for the sake of interoperability it's recommended that you: Find the files in your repository that include CR line endings. Tip On *nix operating systems including macOS, you can use the command file to detect files in your repository that use CR line endings. For example, run the following command on the root of your repository: find . -type f -exec file {} \\; | grep \"CR line\" Update the line endings in your source code files to use either the control characters: LF, if primarily using Unix-like systems such as Linux or the newer macOS operating system CRLF, if primarily using the Microsoft Windows operating system Tip This article on Wikipedia includes examples on how to convert the line endings in your files. After converting the line endings in your source code files, you may also want to check the following resources for help on standardizing the line endings on your repositories and how to configure Git to correctly handle line endings: What's the recommended way to store files in Git? Customizing Git - Formatting and Whitespace Configuring Git to handle line endings Mind the End of Your Line", "title": "Error caused by incompatible line endings"}, {"location": "faq/troubleshooting/error-line-endings/#error-caused-by-incompatible-line-endings", "text": "Codacy executes the git diff command when analyzing new commits and pull requests to identify the lines of code that were changed. Codacy then uses this information to display the issues that were caused by the changes introduced by the commits or pull requests. If you have files in your repository that use the carriage return (CR) as the line end control character, the command git diff doesn't correctly identify line endings in the changed files. Because of this, Codacy is unable to use the output of the command and the Diff step of your commit or pull request analysis logs will display the message An error occurred during this step. Please, retry your analysis or contact support . The CR line end control character was used by older Classic Mac OS systems, and for the sake of interoperability it's recommended that you: Find the files in your repository that include CR line endings. Tip On *nix operating systems including macOS, you can use the command file to detect files in your repository that use CR line endings. For example, run the following command on the root of your repository: find . -type f -exec file {} \\; | grep \"CR line\" Update the line endings in your source code files to use either the control characters: LF, if primarily using Unix-like systems such as Linux or the newer macOS operating system CRLF, if primarily using the Microsoft Windows operating system Tip This article on Wikipedia includes examples on how to convert the line endings in your files. After converting the line endings in your source code files, you may also want to check the following resources for help on standardizing the line endings on your repositories and how to configure Git to correctly handle line endings: What's the recommended way to store files in Git? Customizing Git - Formatting and Whitespace Configuring Git to handle line endings Mind the End of Your Line", "title": "Error caused by incompatible line endings"}, {"location": "faq/troubleshooting/not-a-member-of-the-organization/", "text": "Not a member of the organization # This page applies only to Codacy Cloud When you see the message Not a member of the organization it means that Codacy Cloud can't analyze a commit because the associated email address doesn't belong to any member or committer of your Codacy organization . You can check which email address is associated with a commit by hovering the cursor on the name of the committer on the page for the commit: To verify which email addresses are associated with the Codacy Cloud account, the user must click on their avatar on the top right-hand corner, select Your account , and open the page Emails : There may be different reasons for this issue to happen: The user making the commit hasn't signed in to Codacy Cloud and joined the organization yet The user must join the organization or, if you're the organization admin, you can add the user instead. The commit email address isn't associated with the account of a Codacy Cloud user Make sure the user updates the email addresses associated with their Codacy account to include the missing commit email address. Git isn't configured with the correct email address Make sure the user sets the Git email address correctly.", "title": "Not a member of the organization"}, {"location": "faq/troubleshooting/not-a-member-of-the-organization/#not-a-member-of-the-organization", "text": "This page applies only to Codacy Cloud When you see the message Not a member of the organization it means that Codacy Cloud can't analyze a commit because the associated email address doesn't belong to any member or committer of your Codacy organization . You can check which email address is associated with a commit by hovering the cursor on the name of the committer on the page for the commit: To verify which email addresses are associated with the Codacy Cloud account, the user must click on their avatar on the top right-hand corner, select Your account , and open the page Emails : There may be different reasons for this issue to happen: The user making the commit hasn't signed in to Codacy Cloud and joined the organization yet The user must join the organization or, if you're the organization admin, you can add the user instead. The commit email address isn't associated with the account of a Codacy Cloud user Make sure the user updates the email addresses associated with their Codacy account to include the missing commit email address. Git isn't configured with the correct email address Make sure the user sets the Git email address correctly.", "title": "Not a member of the organization"}, {"location": "faq/troubleshooting/we-no-longer-have-access-to-this-repository/", "text": "We no longer have access to this repository, check your SSH keys # Some changes on your Git provider can prevent Codacy from cloning your private repository. When this happens, Codacy displays the error message \"We no longer have access to this repository\" on the Repository Dashboard page. The repository was renamed or moved # If you renamed the repository or moved it to a different account on the Git provider: On Codacy, open your Repository Settings , tab General . Click the button Update repository in the Synchronize with provider area. The user that configured the repository no longer has access # This section applies only to GitLab and Bitbucket On GitLab and Bitbucket organizations, Codacy uses SSH keys to clone your private repositories. Depending on the level of access that the user configuring the repository on Codacy has on the remote Git provider, an SSH key can be added either: Directly to the repository itself, if the user has permissions to add SSH keys to the repository To the user account, if the user only has read or commit permissions on the repository If the user that initially configured the repository on Codacy was using a user account SSH key but no longer has access to the repository on GitLab or Bitbucket: On Codacy, open your Repository Settings , tab General . Click the button Generate New Repository Key to add a new SSH key to your repository deployment keys. This is only possible if the user configuring the integration with the remote Git provider has administrator access to the repository. Otherwise, this operation will fail. Alternatively, you can do this process manually by copying the SSH key. Note If your repository is using submodules on Codacy , add a new SSH user key to your Git provider account instead. Open the tab Integrations , and refresh your GitLab or Bitbucket integration.", "title": "We no longer have access to this repository, check your SSH keys"}, {"location": "faq/troubleshooting/we-no-longer-have-access-to-this-repository/#we-no-longer-have-access-to-this-repository-check-your-ssh-keys", "text": "Some changes on your Git provider can prevent Codacy from cloning your private repository. When this happens, Codacy displays the error message \"We no longer have access to this repository\" on the Repository Dashboard page.", "title": "We no longer have access to this repository, check your SSH keys"}, {"location": "faq/troubleshooting/we-no-longer-have-access-to-this-repository/#the-repository-was-renamed-or-moved", "text": "If you renamed the repository or moved it to a different account on the Git provider: On Codacy, open your Repository Settings , tab General . Click the button Update repository in the Synchronize with provider area.", "title": "The repository was renamed or moved"}, {"location": "faq/troubleshooting/we-no-longer-have-access-to-this-repository/#the-user-that-configured-the-repository-no-longer-has-access", "text": "This section applies only to GitLab and Bitbucket On GitLab and Bitbucket organizations, Codacy uses SSH keys to clone your private repositories. Depending on the level of access that the user configuring the repository on Codacy has on the remote Git provider, an SSH key can be added either: Directly to the repository itself, if the user has permissions to add SSH keys to the repository To the user account, if the user only has read or commit permissions on the repository If the user that initially configured the repository on Codacy was using a user account SSH key but no longer has access to the repository on GitLab or Bitbucket: On Codacy, open your Repository Settings , tab General . Click the button Generate New Repository Key to add a new SSH key to your repository deployment keys. This is only possible if the user configuring the integration with the remote Git provider has administrator access to the repository. Otherwise, this operation will fail. Alternatively, you can do this process manually by copying the SSH key. Note If your repository is using submodules on Codacy , add a new SSH user key to your Git provider account instead. Open the tab Integrations , and refresh your GitLab or Bitbucket integration.", "title": "The user that configured the repository no longer has access"}, {"location": "faq/troubleshooting/why-arent-duplication-metrics-being-calculated/", "text": "Why aren't duplication metrics being calculated? # For performance reasons, Codacy skips the calculation of code duplication for programming languages that have more than 5000 source code files in a repository. Besides this, if Codacy fails to calculate code duplication for a specific programming language in a repository three times in a row (for example, because the tool calculating the analysis runs out of memory or times out), Codacy stops trying to analyze the metric for that language and repository. When this happens, Codacy doesn't display code duplication metrics for the affected language: The Files page on your repository displays a blank duplication value for files of the affected language. The Commits and Pull Request pages display an empty Duplication tab. The analysis logs for commits won't display a duplication analysis task for the tool corresponding to the affected language. As a workaround, if you're exceeding the maximum number of source code files: Use a Codacy configuration file to exclude source code files of the affected language from your project to decrease the number of files to be analyzed. For example, you may be able to exclude files that are automatically generated from your test suite or files belonging to dependencies that aren't maintained by your team, such as the node_modules folder for JavaScript projects. Reanalyze the last commit in the repository so that Codacy runs the code duplication analysis. If the analysis finishes but the code duplication metric wasn't calculated, follow the next steps: If you're using Codacy Self-hosted , open the Admin panel , Repositories , select the repository, tab Settings , and reset the code duplication analysis in Duplication settings . Then, reanalyze the last commit in the repository so that Codacy runs the code duplication analysis. If you're analyzing your repository locally with the Codacy Analysis CLI, consider using the flag --tool-timeout to specify a larger timeout for the execution of the tool. If you're using Codacy Cloud or if the steps above didn't solve the issue, please contact us at support@codacy.com .", "title": "Why aren't duplication metrics being calculated?"}, {"location": "faq/troubleshooting/why-arent-duplication-metrics-being-calculated/#why-arent-duplication-metrics-being-calculated", "text": "For performance reasons, Codacy skips the calculation of code duplication for programming languages that have more than 5000 source code files in a repository. Besides this, if Codacy fails to calculate code duplication for a specific programming language in a repository three times in a row (for example, because the tool calculating the analysis runs out of memory or times out), Codacy stops trying to analyze the metric for that language and repository. When this happens, Codacy doesn't display code duplication metrics for the affected language: The Files page on your repository displays a blank duplication value for files of the affected language. The Commits and Pull Request pages display an empty Duplication tab. The analysis logs for commits won't display a duplication analysis task for the tool corresponding to the affected language. As a workaround, if you're exceeding the maximum number of source code files: Use a Codacy configuration file to exclude source code files of the affected language from your project to decrease the number of files to be analyzed. For example, you may be able to exclude files that are automatically generated from your test suite or files belonging to dependencies that aren't maintained by your team, such as the node_modules folder for JavaScript projects. Reanalyze the last commit in the repository so that Codacy runs the code duplication analysis. If the analysis finishes but the code duplication metric wasn't calculated, follow the next steps: If you're using Codacy Self-hosted , open the Admin panel , Repositories , select the repository, tab Settings , and reset the code duplication analysis in Duplication settings . Then, reanalyze the last commit in the repository so that Codacy runs the code duplication analysis. If you're analyzing your repository locally with the Codacy Analysis CLI, consider using the flag --tool-timeout to specify a larger timeout for the execution of the tool. If you're using Codacy Cloud or if the steps above didn't solve the issue, please contact us at support@codacy.com .", "title": "Why aren't duplication metrics being calculated?"}, {"location": "faq/troubleshooting/why-cant-i-see-my-organization/", "text": "Why can't I see my organization? # If you can't add your organization to Codacy because it doesn't appear on the Organizations page, please try re-adding your Git provider by clicking Add provider on the Organizations page: If you still can't see your organization on Codacy, follow the steps below to check if the issue is solved: Re-add your Git provider by clicking Add provider on the Organizations page. Make sure that you have access to the organization on the Git provider using the account that you used to log in on Codacy. If you're using GitHub install and authorize Codacy on your organization . Revoke Codacy's OAuth integration with your Git provider and log in again to Codacy. If these steps don't solve the issue, please contact us at support@codacy.com .", "title": "Why can't I see my organization?"}, {"location": "faq/troubleshooting/why-cant-i-see-my-organization/#why-cant-i-see-my-organization", "text": "If you can't add your organization to Codacy because it doesn't appear on the Organizations page, please try re-adding your Git provider by clicking Add provider on the Organizations page: If you still can't see your organization on Codacy, follow the steps below to check if the issue is solved: Re-add your Git provider by clicking Add provider on the Organizations page. Make sure that you have access to the organization on the Git provider using the account that you used to log in on Codacy. If you're using GitHub install and authorize Codacy on your organization . Revoke Codacy's OAuth integration with your Git provider and log in again to Codacy. If these steps don't solve the issue, please contact us at support@codacy.com .", "title": "Why can't I see my organization?"}, {"location": "faq/troubleshooting/why-did-codacy-stop-commenting-on-pull-requests/", "text": "Why did Codacy stop commenting on pull requests? # Outdated app permissions # This section applies to Codacy Coverage on GitHub Coverage information is currently sent to GitHub by a new version of the Codacy Coverage engine, which depends on updated app permissions. If you stopped receiving coverage summaries on your pull requests, please review and accept the updated Codacy app permissions on GitHub . For more information on the rollout of the new Coverage engine, see the relevant release note . Outdated permissions or invalid SSH key # This section applies to GitLab and Bitbucket Different reasons can cause Codacy to stop analyzing and commenting on pull requests, but the most common is that the user who initially enabled the GitLab or Bitbucket integration no longer has permissions on the repository or that the SSH key is no longer valid. To fix this issue and avoid future disruptions, refresh the GitLab or Bitbucket integration on Codacy using a dedicated service account on your Git provider: Create a service account on your Git provider exclusively dedicated to integrating Codacy with your repositories. Note The service account must: Have administrator permissions on the repositories to integrate with Codacy Not be shared by other systems to ensure that Codacy doesn't hit the API rate limits of the Git provider when using this account Tip Using a dedicated service account also has the advantage of any pull request comments made by Codacy appearing as authored by the service account instead of by a regular organization member. You can name this account \"Codacy\" and use this Codacy logo as the account picture so that your pull request comments look like the following example: Log out of both your Git provider and of Codacy. Log in to Codacy using the new service account. Open your repository Settings , tab Integrations , and click the link Refresh connection to refresh the existing Git provider integration: Make sure the Git provider integration is configured as needed: Configuring the GitLab integration Configuring the Bitbucket integration See also # We no longer have access to this repository, check your SSH keys", "title": "Why did Codacy stop commenting on pull requests?"}, {"location": "faq/troubleshooting/why-did-codacy-stop-commenting-on-pull-requests/#why-did-codacy-stop-commenting-on-pull-requests", "text": "", "title": "Why did Codacy stop commenting on pull requests?"}, {"location": "faq/troubleshooting/why-did-codacy-stop-commenting-on-pull-requests/#outdated-app-permissions", "text": "This section applies to Codacy Coverage on GitHub Coverage information is currently sent to GitHub by a new version of the Codacy Coverage engine, which depends on updated app permissions. If you stopped receiving coverage summaries on your pull requests, please review and accept the updated Codacy app permissions on GitHub . For more information on the rollout of the new Coverage engine, see the relevant release note .", "title": "Outdated app permissions"}, {"location": "faq/troubleshooting/why-did-codacy-stop-commenting-on-pull-requests/#outdated-permissions", "text": "This section applies to GitLab and Bitbucket Different reasons can cause Codacy to stop analyzing and commenting on pull requests, but the most common is that the user who initially enabled the GitLab or Bitbucket integration no longer has permissions on the repository or that the SSH key is no longer valid. To fix this issue and avoid future disruptions, refresh the GitLab or Bitbucket integration on Codacy using a dedicated service account on your Git provider: Create a service account on your Git provider exclusively dedicated to integrating Codacy with your repositories. Note The service account must: Have administrator permissions on the repositories to integrate with Codacy Not be shared by other systems to ensure that Codacy doesn't hit the API rate limits of the Git provider when using this account Tip Using a dedicated service account also has the advantage of any pull request comments made by Codacy appearing as authored by the service account instead of by a regular organization member. You can name this account \"Codacy\" and use this Codacy logo as the account picture so that your pull request comments look like the following example: Log out of both your Git provider and of Codacy. Log in to Codacy using the new service account. Open your repository Settings , tab Integrations , and click the link Refresh connection to refresh the existing Git provider integration: Make sure the Git provider integration is configured as needed: Configuring the GitLab integration Configuring the Bitbucket integration", "title": "Outdated permissions or invalid SSH key"}, {"location": "faq/troubleshooting/why-did-codacy-stop-commenting-on-pull-requests/#see-also", "text": "We no longer have access to this repository, check your SSH keys", "title": "See also"}, {"location": "faq/troubleshooting/why-is-my-file-over-150-kb-missing/", "text": "Why is my file over 150 KB missing? # Codacy Cloud currently doesn't analyze files that are larger than 150 KB . Codacy doesn't display these files on the Files page , and doesn't take them into account when grading your repository. Why is there a limit? # As part of our performance improvement measures, we spent time breaking down the total time it takes to analyze a repository and found that a large percentage of time was spent on files that didn't add value to our users. Those files tend to be the biggest in the repository and are typically generated by or dependent on a third-party. It increased analysis time significantly due to the file size and even resulted in timeouts at some point, preventing the flagging of real issues. As a solution to this problem, we placed a size limit to the files that Codacy would analyze. This decreased the average analysis time and the number of timeouts, thus improving the overall performance for our users. What if I need to analyze a file that exceeds this limit? # While Codacy will ignore your file by default, you can still analyze it by running the analysis locally using the Codacy Analysis CLI . The Codacy Analysis CLI doesn't have any limitation on file size. What about Codacy Self-hosted? # By default, Codacy Self-hosted has the same limit of 150 KB as Codacy Cloud. However, in this case the limit is configurable because the resource allocation for on-premise instances is decided by each organization. To update the file size limit: Edit the value of global.workerManager.workers.config.analysis.maxFileSizeBytes in the values-production.yaml file that you used to install Codacy: global : workerManager : workers : config : analysis : maxFileSizeBytes : 150000 Apply the new configuration by performing a Helm upgrade and specifying the Codacy Self-hosted version currently installed. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "Why is my file over 150 KB missing?"}, {"location": "faq/troubleshooting/why-is-my-file-over-150-kb-missing/#why-is-my-file-over-150-kb-missing", "text": "Codacy Cloud currently doesn't analyze files that are larger than 150 KB . Codacy doesn't display these files on the Files page , and doesn't take them into account when grading your repository.", "title": "Why is my file over 150 KB missing?"}, {"location": "faq/troubleshooting/why-is-my-file-over-150-kb-missing/#why-is-there-a-limit", "text": "As part of our performance improvement measures, we spent time breaking down the total time it takes to analyze a repository and found that a large percentage of time was spent on files that didn't add value to our users. Those files tend to be the biggest in the repository and are typically generated by or dependent on a third-party. It increased analysis time significantly due to the file size and even resulted in timeouts at some point, preventing the flagging of real issues. As a solution to this problem, we placed a size limit to the files that Codacy would analyze. This decreased the average analysis time and the number of timeouts, thus improving the overall performance for our users.", "title": "Why is there a limit?"}, {"location": "faq/troubleshooting/why-is-my-file-over-150-kb-missing/#what-if-i-need-to-analyze-a-file-that-exceeds-this-limit", "text": "While Codacy will ignore your file by default, you can still analyze it by running the analysis locally using the Codacy Analysis CLI . The Codacy Analysis CLI doesn't have any limitation on file size.", "title": "What if I need to analyze a file that exceeds this limit?"}, {"location": "faq/troubleshooting/why-is-my-file-over-150-kb-missing/#what-about-codacy-self-hosted", "text": "By default, Codacy Self-hosted has the same limit of 150 KB as Codacy Cloud. However, in this case the limit is configurable because the resource allocation for on-premise instances is decided by each organization. To update the file size limit: Edit the value of global.workerManager.workers.config.analysis.maxFileSizeBytes in the values-production.yaml file that you used to install Codacy: global : workerManager : workers : config : analysis : maxFileSizeBytes : 150000 Apply the new configuration by performing a Helm upgrade and specifying the Codacy Self-hosted version currently installed. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "What about Codacy Self-hosted?"}, {"location": "faq/troubleshooting/why-isnt-my-public-repository-being-analyzed/", "text": "Why isn't my public repository being analyzed? # Codacy only analyzes open source repositories if the admin of the repository is a committer to that repository.", "title": "Why isn't my public repository being analyzed?"}, {"location": "faq/troubleshooting/why-isnt-my-public-repository-being-analyzed/#why-isnt-my-public-repository-being-analyzed", "text": "Codacy only analyzes open source repositories if the admin of the repository is a committer to that repository.", "title": "Why isn't my public repository being analyzed?"}, {"location": "getting-started/adding-a-codacy-badge/", "text": "Adding a Codacy badge # Add a Codacy badge to the README of your repository to display the current code quality grade or code coverage of your repository. To obtain your Codacy badge, open your repository Settings , tab General , select the markup language, and copy the generated code to your README file. You can also add a badge for your coverage if you have set up code coverage for your repository. To display the grade or code coverage information of a different branch analyzed by Codacy, append ?branch= to the URL of the badge. For example: https://app.codacy.com/project/badge/Grade/cba8fd0874ac4f569f4f880e473cbac9?branch=dev Fixing your Codacy badge # The Codacy badges for your repository may become unavailable or grayed out if the analysis or code coverage information for the last commit isn't available, or if you renamed or re-added your repository on Codacy: To fix each badge: Reanalyze the branch associated with the code quality badge Make sure that you're generating and uploading code coverage reports for all the commits in the branch associated with the coverage badge If these steps don't fix your Codacy badges it can mean that the badges are no longer valid. In this case, repeat the steps above to replace the existing badges with new ones.", "title": "Adding a Codacy badge"}, {"location": "getting-started/adding-a-codacy-badge/#adding-a-codacy-badge", "text": "Add a Codacy badge to the README of your repository to display the current code quality grade or code coverage of your repository. To obtain your Codacy badge, open your repository Settings , tab General , select the markup language, and copy the generated code to your README file. You can also add a badge for your coverage if you have set up code coverage for your repository. To display the grade or code coverage information of a different branch analyzed by Codacy, append ?branch= to the URL of the badge. For example: https://app.codacy.com/project/badge/Grade/cba8fd0874ac4f569f4f880e473cbac9?branch=dev", "title": "Adding a Codacy badge"}, {"location": "getting-started/adding-a-codacy-badge/#fixing-your-codacy-badge", "text": "The Codacy badges for your repository may become unavailable or grayed out if the analysis or code coverage information for the last commit isn't available, or if you renamed or re-added your repository on Codacy: To fix each badge: Reanalyze the branch associated with the code quality badge Make sure that you're generating and uploading code coverage reports for all the commits in the branch associated with the coverage badge If these steps don't fix your Codacy badges it can mean that the badges are no longer valid. In this case, repeat the steps above to replace the existing badges with new ones.", "title": "Fixing your Codacy badge"}, {"location": "getting-started/codacy-quickstart/", "text": "Codacy quickstart (5 min) # Codacy is an automated code quality and coverage platform that analyzes your source code and identifies issues as you go, helping your team ship robust software by scanning over 40 programming languages, such as JavaScript, Python, Java, C#, and PHP. Check out our product demo for an overview of Codacy's main features (recorded on May 13, 2024): By integrating with your Git provider, Codacy keeps track of your team\u2019s work, analyzes relevant commits, highlights problems, suggests improvements, and protects your codebase from unwelcome changes. From organization and repository level to individual files, pull requests, and commits, Codacy monitors the following metrics across your projects: Issues : violations of a given rule, standard, convention, or best practice, from inconsistent code formatting to security risks Complexity : a measure of the number of execution paths through a program's source code Duplication : the amount of duplicated portions of code Coverage : the percentage of lines of code covered by automated tests Adding your first repository # This page is part of the following guided path: Adding your first repository Configuring your repository Integrating Codacy with your Git workflow To get started, head to codacy.com and click Start free . Then, follow these steps: Signing up Choosing an organization Adding repositories 1. Signing up # Sign up with a Git provider such as GitHub, GitLab, or Bitbucket. This links your Codacy user with your Git provider user, making it easier to add repositories to Codacy and invite your teammates. Codacy will request access to your Git provider during the authorization flow. Check the permissions that Codacy requires and why . 2. Choosing an organization # Now, you'll need to add or join the organizations that contain your repositories. The organization with the same name as your Git provider username contains your personal repositories. Read more about organizations on Codacy . To start adding your repositories, select one of the organizations. Note If you can't see the organization you're looking for, follow these troubleshooting instructions . 3. Adding repositories # Next, add the repositories that you wish to analyze. Codacy begins an initial analysis as soon as you add a repository and sets everything up to ensure your next commits on that repository are analyzed. Note You can only add repositories on Codacy if you have the necessary permissions on your Git provider . Click the repository name to navigate to the repository dashboard and see the code quality overview of your repository as soon as the initial analysis is complete: Congratulations, your new repository is ready! To explore the initial analysis results, check the Issues page . Next steps # The first analysis is based on default tool and pattern configurations. It's now important that you configure your repository to integrate code analysis seamlessly into your existing pipeline. See how to configure your repository to match the use cases of your team .", "title": "Codacy quickstart (5 min)"}, {"location": "getting-started/codacy-quickstart/#codacy-quickstart-5-min", "text": "Codacy is an automated code quality and coverage platform that analyzes your source code and identifies issues as you go, helping your team ship robust software by scanning over 40 programming languages, such as JavaScript, Python, Java, C#, and PHP. Check out our product demo for an overview of Codacy's main features (recorded on May 13, 2024): By integrating with your Git provider, Codacy keeps track of your team\u2019s work, analyzes relevant commits, highlights problems, suggests improvements, and protects your codebase from unwelcome changes. From organization and repository level to individual files, pull requests, and commits, Codacy monitors the following metrics across your projects: Issues : violations of a given rule, standard, convention, or best practice, from inconsistent code formatting to security risks Complexity : a measure of the number of execution paths through a program's source code Duplication : the amount of duplicated portions of code Coverage : the percentage of lines of code covered by automated tests", "title": "Codacy quickstart (5 min)"}, {"location": "getting-started/codacy-quickstart/#adding-your-first-repository", "text": "This page is part of the following guided path: Adding your first repository Configuring your repository Integrating Codacy with your Git workflow To get started, head to codacy.com and click Start free . Then, follow these steps: Signing up Choosing an organization Adding repositories", "title": "Adding your first repository"}, {"location": "getting-started/codacy-quickstart/#signing-up", "text": "Sign up with a Git provider such as GitHub, GitLab, or Bitbucket. This links your Codacy user with your Git provider user, making it easier to add repositories to Codacy and invite your teammates. Codacy will request access to your Git provider during the authorization flow. Check the permissions that Codacy requires and why .", "title": "1. Signing up"}, {"location": "getting-started/codacy-quickstart/#choosing-organization", "text": "Now, you'll need to add or join the organizations that contain your repositories. The organization with the same name as your Git provider username contains your personal repositories. Read more about organizations on Codacy . To start adding your repositories, select one of the organizations. Note If you can't see the organization you're looking for, follow these troubleshooting instructions .", "title": "2. Choosing an organization"}, {"location": "getting-started/codacy-quickstart/#adding-repositories", "text": "Next, add the repositories that you wish to analyze. Codacy begins an initial analysis as soon as you add a repository and sets everything up to ensure your next commits on that repository are analyzed. Note You can only add repositories on Codacy if you have the necessary permissions on your Git provider . Click the repository name to navigate to the repository dashboard and see the code quality overview of your repository as soon as the initial analysis is complete: Congratulations, your new repository is ready! To explore the initial analysis results, check the Issues page .", "title": "3. Adding repositories"}, {"location": "getting-started/codacy-quickstart/#next-steps", "text": "The first analysis is based on default tool and pattern configurations. It's now important that you configure your repository to integrate code analysis seamlessly into your existing pipeline. See how to configure your repository to match the use cases of your team .", "title": "Next steps"}, {"location": "getting-started/configuring-your-repository/", "text": "Configuring your repository # This page is part of the following guided path: Adding your first repository Configuring your repository Integrating Codacy with your Git workflow Once you've added your first repository, it's important that you configure Codacy's analysis tools to match the use cases of your team, such as configuring any coding conventions and best practices that your team may already be following or that you want to promote. It's also critical to review the configurations to avoid reporting false positives or any other issues that don't bring value to your team, which can introduce unwanted delays to the development process. You can optionally add coverage reports to detail how much of your code is covered by tests and unify your quality and coverage pipelines. You can generate coverage reports and upload them to Codacy using a range of options, such as CI/CD integration, CLI, Docker, GitHub action, and more. To configure your repository, follow these steps: Ignoring files Configuring code patterns Adding coverage reports (optional) 1. Ignoring files # Ignore any files and directories that aren't relevant for the Codacy analysis, such as generated code or any third-party libraries included in your repositories. 2. Configuring code patterns # Configure the tools and code patterns that Codacy uses to analyze your repository. If security is important for your team, review the security and risk management dashboard to ensure that your configuration detects potential security issues. Tip To ensure that multiple repositories consistently follow the same global tool and code pattern configurations, use an organization coding standard . 3. Adding coverage to your repository (optional) # If you want to use code coverage to block merging pull requests that don't meet your quality standards, make sure that you add coverage to your repository . It's important that you set up coverage beforehand because Codacy can only report the coverage status for pull requests after receiving reports for the last commits on both the pull request branch and the target branch . Next steps # Once you\u2019re satisfied with your setup, integrate Codacy with your Git workflow to flag potential issues, block problematic pull requests, and display other useful suggestions directly on your Git provider. Tip To showcase the current code quality grade and coverage, add a Codacy badge to your repository .", "title": "Configuring your repository"}, {"location": "getting-started/configuring-your-repository/#configuring-your-repository", "text": "This page is part of the following guided path: Adding your first repository Configuring your repository Integrating Codacy with your Git workflow Once you've added your first repository, it's important that you configure Codacy's analysis tools to match the use cases of your team, such as configuring any coding conventions and best practices that your team may already be following or that you want to promote. It's also critical to review the configurations to avoid reporting false positives or any other issues that don't bring value to your team, which can introduce unwanted delays to the development process. You can optionally add coverage reports to detail how much of your code is covered by tests and unify your quality and coverage pipelines. You can generate coverage reports and upload them to Codacy using a range of options, such as CI/CD integration, CLI, Docker, GitHub action, and more. To configure your repository, follow these steps: Ignoring files Configuring code patterns Adding coverage reports (optional)", "title": "Configuring your repository"}, {"location": "getting-started/configuring-your-repository/#ignoring-files", "text": "Ignore any files and directories that aren't relevant for the Codacy analysis, such as generated code or any third-party libraries included in your repositories.", "title": "1. Ignoring files"}, {"location": "getting-started/configuring-your-repository/#configuring-code-patterns", "text": "Configure the tools and code patterns that Codacy uses to analyze your repository. If security is important for your team, review the security and risk management dashboard to ensure that your configuration detects potential security issues. Tip To ensure that multiple repositories consistently follow the same global tool and code pattern configurations, use an organization coding standard .", "title": "2. Configuring code patterns"}, {"location": "getting-started/configuring-your-repository/#adding-coverage", "text": "If you want to use code coverage to block merging pull requests that don't meet your quality standards, make sure that you add coverage to your repository . It's important that you set up coverage beforehand because Codacy can only report the coverage status for pull requests after receiving reports for the last commits on both the pull request branch and the target branch .", "title": "3. Adding coverage to your repository (optional)"}, {"location": "getting-started/configuring-your-repository/#next-steps", "text": "Once you\u2019re satisfied with your setup, integrate Codacy with your Git workflow to flag potential issues, block problematic pull requests, and display other useful suggestions directly on your Git provider. Tip To showcase the current code quality grade and coverage, add a Codacy badge to your repository .", "title": "Next steps"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/", "text": "Integrating Codacy with IntelliJ IDEs # The Codacy IntelliJ plugin is an open-source plugin for IntelliJ IDEs that lets you review the result of the Codacy analysis for a pull request, get the full list of problems found, and navigate to any Quality issue that you want to review and fix. To use this plugin you need a Codacy account Interface overview # The main view of the Codacy IntelliJ plugin provides a summary of the code quality and coverage changes introduced by the pull request of the currently checked-out branch. In the main view, you can find the following information: The Quality status of the pull request, either up to standards or not up to standards, based on the Quality gates set for the repository. Any Quality issues introduced or fixed by the pull request. These are the same issues you find in the Quality Issues tabs in the Codacy app and are also visible in IntelliJ's Problems tab. When this item is expanded, the number next to each file name is the total number of Quality issues that the pull request adds to that file. The diff coverage introduced by the pull request. This is the same value you find in the Pull request coverage overview panel in the Codacy app. The percentage next to each file name is the coverage variation for that file. Sequences of duplicate code (clones) introduced by the pull request. These are the same ones you find in the Quality Duplication tabs in the Codacy app. Variations in code complexity introduced by the pull request. Installing the Codacy IntelliJ plugin # The Codacy IntelliJ plugin is compatible with IntelliJ IDEA (Ultimate, Community), Android Studio, and Aqua. Make sure that the repository you\u2019re working on is analyzed by Codacy and that you have a repository read role or higher. Tip If this is your first time using Codacy, see how to add and analyze your first repository . Install the plugin from the JetBrains Marketplace or through the plugin settings panel in your IntelliJ IDE. Getting pull request quality and coverage data # To see Codacy quality and coverage data for an open pull request, follow these steps: Open the repository directory in your IntelliJ IDE. Note If the repository isn't on Codacy yet, add it to Codacy first. Open the main view by clicking the Codacy logo in the left tool window bar. If you\u2019re not signed in, click the Sign in button to authorize IntelliJ on Codacy. Check out the pull request of interest. After completing these steps, the main view shows the result of the latest Codacy analysis for the pull request. Reviewing pull request issues # In the Problems tool window , Codacy displays the same Quality issues you find in the main view and lets you navigate to the exact line of code where the issue was found. Note Code coverage, duplicates, and complexity aren't currently shown in the Problems tool window. To review Quality issues: Open the file you want to review. You can find the list of files with issues in the main view of the Codacy plugin. Double-click the file name to open it in the editor. Open the Problems tool window (use Ctrl+6 on Windows/Linux or Cmd+6 on macOS) and select the File tab. Click the name of the issue you want to review. Hover over a highlighted issue in the code editor to view available actions and suggested quick fixes, if available. For a list of tools that support suggested fixes, see Supported languages and tools . Once you've addressed the problems in your code, push your changes to the Git provider so that Codacy analyzes the updated code. When the analysis is complete, the Codacy plugin automatically refreshes the pull request analysis result. You can also refresh the pull request data manually by clicking the Refresh Pull Request button in the main view. See also # Troubleshooting the Codacy IntelliJ plugin", "title": "Integrating Codacy with IntelliJ IDEs"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/#integrating-codacy-with-intellij-ides", "text": "The Codacy IntelliJ plugin is an open-source plugin for IntelliJ IDEs that lets you review the result of the Codacy analysis for a pull request, get the full list of problems found, and navigate to any Quality issue that you want to review and fix. To use this plugin you need a Codacy account", "title": "Integrating Codacy with IntelliJ IDEs"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/#interface-overview", "text": "The main view of the Codacy IntelliJ plugin provides a summary of the code quality and coverage changes introduced by the pull request of the currently checked-out branch. In the main view, you can find the following information: The Quality status of the pull request, either up to standards or not up to standards, based on the Quality gates set for the repository. Any Quality issues introduced or fixed by the pull request. These are the same issues you find in the Quality Issues tabs in the Codacy app and are also visible in IntelliJ's Problems tab. When this item is expanded, the number next to each file name is the total number of Quality issues that the pull request adds to that file. The diff coverage introduced by the pull request. This is the same value you find in the Pull request coverage overview panel in the Codacy app. The percentage next to each file name is the coverage variation for that file. Sequences of duplicate code (clones) introduced by the pull request. These are the same ones you find in the Quality Duplication tabs in the Codacy app. Variations in code complexity introduced by the pull request.", "title": "Interface overview"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/#installing-the-codacy-intellij-plugin", "text": "The Codacy IntelliJ plugin is compatible with IntelliJ IDEA (Ultimate, Community), Android Studio, and Aqua. Make sure that the repository you\u2019re working on is analyzed by Codacy and that you have a repository read role or higher. Tip If this is your first time using Codacy, see how to add and analyze your first repository . Install the plugin from the JetBrains Marketplace or through the plugin settings panel in your IntelliJ IDE.", "title": "Installing the Codacy IntelliJ plugin"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/#getting-pull-request-quality-and-coverage-data", "text": "To see Codacy quality and coverage data for an open pull request, follow these steps: Open the repository directory in your IntelliJ IDE. Note If the repository isn't on Codacy yet, add it to Codacy first. Open the main view by clicking the Codacy logo in the left tool window bar. If you\u2019re not signed in, click the Sign in button to authorize IntelliJ on Codacy. Check out the pull request of interest. After completing these steps, the main view shows the result of the latest Codacy analysis for the pull request.", "title": "Getting pull request quality and coverage data"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/#reviewing-pull-request-issues", "text": "In the Problems tool window , Codacy displays the same Quality issues you find in the main view and lets you navigate to the exact line of code where the issue was found. Note Code coverage, duplicates, and complexity aren't currently shown in the Problems tool window. To review Quality issues: Open the file you want to review. You can find the list of files with issues in the main view of the Codacy plugin. Double-click the file name to open it in the editor. Open the Problems tool window (use Ctrl+6 on Windows/Linux or Cmd+6 on macOS) and select the File tab. Click the name of the issue you want to review. Hover over a highlighted issue in the code editor to view available actions and suggested quick fixes, if available. For a list of tools that support suggested fixes, see Supported languages and tools . Once you've addressed the problems in your code, push your changes to the Git provider so that Codacy analyzes the updated code. When the analysis is complete, the Codacy plugin automatically refreshes the pull request analysis result. You can also refresh the pull request data manually by clicking the Refresh Pull Request button in the main view.", "title": "Reviewing pull request issues"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/#see-also", "text": "Troubleshooting the Codacy IntelliJ plugin", "title": "See also"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/", "text": "Integrating Codacy with Visual Studio Code # The Codacy Visual Studio Code extension is an open-source project that enables developers to review directly in VS Code the result of Codacy analysis for the pull requests they\u2019re working on. Use this extension to get the full list of problems found by Codacy for a pull request and navigate to any Quality issue that you want to review and fix. To use this extension you need a Codacy account Interface overview # The main view of the extension displays information about the code quality and coverage changes introduced by the pull requests you're working on, as well as the quality status of analyzed branches. This information is grouped into three panels: Pull request status Open pull requests Analyzed branch Status tab # The Pull request status tab displays the following information for the pull request of the currently checked-out branch: The Quality status of the pull request, either up to standards or not up to standards, based on the Quality gates set for the repository. Any Quality issues introduced or fixed by the pull request. These are the same issues you find in the Quality Issues tabs in the Codacy app and are also visible in VS Code's Problems tab. When this item is expanded, the number next to each file name is the total number of Quality issues that the pull request adds to or removes from that file. The number farther to the right, added by VS Code, is the total number of problems in that file, which may or may not be Quality issues from Codacy. If there are any Medium or Critical Quality issues, the file name is also highlighted in yellow (Medium) or red (Critical). The diff coverage and coverage variation introduced by the pull request. These are the same values you find in the Pull request coverage overview panel in the Codacy app. When this item is expanded, the percentage next to each file name is the coverage variation for that file. You can toggle on/off the inline coverage to see/hide the line-by-line diff coverage and a comparison of the old and new file content for each modified file - uncovered lines (red), covered lines with its test coverage count (green), and non-coverable lines (no background). These are the same details you find in the coverage Diff tab of the pull request in the Codacy app. Sequences of duplicate code (clones) introduced by the pull request. These are the same ones you find in the Quality Duplication tabs in the Codacy app. Variations in code complexity introduced by the pull request. Open pull requests tab # The Open Pull Requests tab lists all open pull requests for the repository, including the following information for each: The status of the pull request, which is visible on hover: Analyzing, if Codacy is analyzing the branch. Up to standards or not up to standards, based on the Quality gates set for the repository. The author of the pull request. The source and target branches of the pull request. Any Quality issues introduced or fixed by the pull request. These are the same issues you find in the Quality Issues tabs in the Codacy app. Sequences of duplicate code (clones) introduced by the pull request. These are the same ones you find in the Quality Duplication tabs in the Codacy app. Variations in code complexity introduced by the pull request. This is the same value you find on the Pull request quality overview in the Codacy app. Analyzed branch tab # The Analyzed Branch tab appears if you switch to an analyzed branch that doesn't have an open pull request, such as the main or master branch. This tab shows an overview of the Quality issues found in that branch, grouped by recently added, introduced by the current user, issue category, and issue severity. See how to manage the analysis of your repository's branches . Installing the Codacy VS Code extension # Make sure that the repository you\u2019re working on is analyzed by Codacy and that you have a repository read role or higher. Tip If this is your first time using Codacy, see how to add and analyze your first repository . Install the extension from the Visual Studio Marketplace or through the Extensions view in VS Code . Alternatively, you can install it manually by downloading the latest release as a VSIX package . Getting pull request quality and coverage data # To see Codacy quality and coverage data for an open pull request, follow these steps: Open the repository directory in VS Code. Note If the repository isn't on Codacy yet, add it to Codacy first. Open the main view by clicking the Codacy logo in the activity bar or the Codacy tab in the status bar. If you\u2019re not signed in, click the Sign in button to authorize VS Code on Codacy. Tip To access a complete list of Codacy commands, open the VS Code command palette ( Ctrl+Shift+P on Windows/Linux or Cmd+Shift+P on macOS) and type \"Codacy\". Check out the pull request of interest. You can do it either manually or from the Open Pull Requests tab, by clicking the arrow button or using the contextual right-click menu. After completing these steps, the main view shows the result of the latest Codacy analysis for the pull request. The VS Code Problems tab lists the Quality issues found. Reviewing pull request issues # In the Problems tab , Codacy displays the same Quality issues you find in the Status tab and lets you navigate to the exact line of code where the issue was found. Note Code coverage, duplicates, and complexity aren't currently shown in the Problems tab. To review Quality issues: Open the Problems tab (use Ctrl+Shift+M on Windows/Linux or Cmd+Shift+M on macOS). Click the name of the issue you want to review. Hover over a highlighted issue in the code editor to view available actions and suggested quick fixes (if available). For a list of tools that support quick fixes, see Supported languages and tools . Once you've addressed the problems in your code, push your changes to the Git provider so that Codacy analyzes the updated code. When the analysis is complete, the Codacy extension automatically refreshes the pull request analysis result. You can also refresh the pull request data manually by clicking the Refresh Pull Request button in the main view. See also # Troubleshooting the Codacy VS Code extension", "title": "Integrating Codacy with Visual Studio Code"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/#integrating-codacy-with-visual-studio-code", "text": "The Codacy Visual Studio Code extension is an open-source project that enables developers to review directly in VS Code the result of Codacy analysis for the pull requests they\u2019re working on. Use this extension to get the full list of problems found by Codacy for a pull request and navigate to any Quality issue that you want to review and fix. To use this extension you need a Codacy account", "title": "Integrating Codacy with Visual Studio Code"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/#interface-overview", "text": "The main view of the extension displays information about the code quality and coverage changes introduced by the pull requests you're working on, as well as the quality status of analyzed branches. This information is grouped into three panels: Pull request status Open pull requests Analyzed branch", "title": "Interface overview"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/#installing-the-codacy-vs-code-extension", "text": "Make sure that the repository you\u2019re working on is analyzed by Codacy and that you have a repository read role or higher. Tip If this is your first time using Codacy, see how to add and analyze your first repository . Install the extension from the Visual Studio Marketplace or through the Extensions view in VS Code . Alternatively, you can install it manually by downloading the latest release as a VSIX package .", "title": "Installing the Codacy VS Code extension"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/#getting-pull-request-quality-and-coverage-data", "text": "To see Codacy quality and coverage data for an open pull request, follow these steps: Open the repository directory in VS Code. Note If the repository isn't on Codacy yet, add it to Codacy first. Open the main view by clicking the Codacy logo in the activity bar or the Codacy tab in the status bar. If you\u2019re not signed in, click the Sign in button to authorize VS Code on Codacy. Tip To access a complete list of Codacy commands, open the VS Code command palette ( Ctrl+Shift+P on Windows/Linux or Cmd+Shift+P on macOS) and type \"Codacy\". Check out the pull request of interest. You can do it either manually or from the Open Pull Requests tab, by clicking the arrow button or using the contextual right-click menu. After completing these steps, the main view shows the result of the latest Codacy analysis for the pull request. The VS Code Problems tab lists the Quality issues found.", "title": "Getting pull request quality and coverage data"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/#reviewing-pull-request-issues", "text": "In the Problems tab , Codacy displays the same Quality issues you find in the Status tab and lets you navigate to the exact line of code where the issue was found. Note Code coverage, duplicates, and complexity aren't currently shown in the Problems tab. To review Quality issues: Open the Problems tab (use Ctrl+Shift+M on Windows/Linux or Cmd+Shift+M on macOS). Click the name of the issue you want to review. Hover over a highlighted issue in the code editor to view available actions and suggested quick fixes (if available). For a list of tools that support quick fixes, see Supported languages and tools . Once you've addressed the problems in your code, push your changes to the Git provider so that Codacy analyzes the updated code. When the analysis is complete, the Codacy extension automatically refreshes the pull request analysis result. You can also refresh the pull request data manually by clicking the Refresh Pull Request button in the main view.", "title": "Reviewing pull request issues"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/#see-also", "text": "Troubleshooting the Codacy VS Code extension", "title": "See also"}, {"location": "getting-started/integrating-codacy-with-your-git-workflow/", "text": "Integrating Codacy with your Git workflow # This page is part of the following guided path: Adding your first repository Configuring your repository Integrating Codacy with your Git workflow Once you've configured your repository to best match your use case, integrate Codacy with your Git workflow to display analysis results and code coverage as status checks on your pull requests. In particular, you can configure quality gates to block merging pull requests that don't meet the quality standards of your team. This ensures the quality of the changes to your codebase, preventing the introduction of security issues and untested code. To integrate Codacy with your Git workflow, follow these steps: Configuring the quality gate rules Configuring the Git provider integration Blocking merging pull requests (optional) 1. Configuring the quality gate rules # Review and adjust the quality gates of your repository to decide which pull requests should fail the Codacy quality gate. Tip The default quality gate rules are designed to help maintain the current code quality of your repository. In particular, the default value for the coverage rule might be demanding. Depending on factors such as the current code quality of your repository and the maturity of your team practices, consider the balance between implementing stricter quality gates and the possibility of delaying or blocking the development progress. Codacy generally recommends that on a first stage you configure rules that focus on stopping new critical issues from entering your code base, such as: High severity issues Security issues Considerable drops in code coverage Important If you want to use code coverage to block merging pull requests that don't meet your standards, make sure that you enable the rule Diff coverage is under or Coverage variation is under . This is required for Codacy to report the coverage status directly on your pull requests. 2. Configuring the Git provider integration # Make sure you enable the option Status checks ( GitHub ) or Pull request status ( GitLab and Bitbucket ). Tip Configure the default Git provider integration settings that Codacy applies to new repositories to help ensure that all new repositories have the same settings. 3. Blocking merging pull requests (optional) # Once you've tested out Codacy for a while and you're happy with the level of feedback provided, you can decide to enforce the quality gates and use Codacy to block merging pull requests on your Git provider. This is the best way to protect your code from unwelcome changes and fully integrates code quality and coverage analysis into your development pipeline. Important To eliminate any false positives that could inadvertently block the work of your team, it's important that before activating this feature you: Validate that Codacy is reporting the intended status on your pull requests Double check you repository's tool and code pattern settings and quality gate settings Follow the instructions from your Git provider to block merging pull requests if they don't pass the Codacy status check: GitHub: set Codacy as a required status check GitLab: only allow merge requests to be merged if the pipeline succeeds Bitbucket: configure Bitbucket to prevent a merge with unresolved merge checks You're all set! \ud83c\udf89 # Congratulations! You've successfully integrated and set up your first repository.", "title": "Integrating Codacy with your Git workflow"}, {"location": "getting-started/integrating-codacy-with-your-git-workflow/#integrating-codacy-with-your-git-workflow", "text": "This page is part of the following guided path: Adding your first repository Configuring your repository Integrating Codacy with your Git workflow Once you've configured your repository to best match your use case, integrate Codacy with your Git workflow to display analysis results and code coverage as status checks on your pull requests. In particular, you can configure quality gates to block merging pull requests that don't meet the quality standards of your team. This ensures the quality of the changes to your codebase, preventing the introduction of security issues and untested code. To integrate Codacy with your Git workflow, follow these steps: Configuring the quality gate rules Configuring the Git provider integration Blocking merging pull requests (optional)", "title": "Integrating Codacy with your Git workflow"}, {"location": "getting-started/integrating-codacy-with-your-git-workflow/#configuring-gate", "text": "Review and adjust the quality gates of your repository to decide which pull requests should fail the Codacy quality gate. Tip The default quality gate rules are designed to help maintain the current code quality of your repository. In particular, the default value for the coverage rule might be demanding. Depending on factors such as the current code quality of your repository and the maturity of your team practices, consider the balance between implementing stricter quality gates and the possibility of delaying or blocking the development progress. Codacy generally recommends that on a first stage you configure rules that focus on stopping new critical issues from entering your code base, such as: High severity issues Security issues Considerable drops in code coverage Important If you want to use code coverage to block merging pull requests that don't meet your standards, make sure that you enable the rule Diff coverage is under or Coverage variation is under . This is required for Codacy to report the coverage status directly on your pull requests.", "title": "1. Configuring the quality gate rules"}, {"location": "getting-started/integrating-codacy-with-your-git-workflow/#git-provider-integration", "text": "Make sure you enable the option Status checks ( GitHub ) or Pull request status ( GitLab and Bitbucket ). Tip Configure the default Git provider integration settings that Codacy applies to new repositories to help ensure that all new repositories have the same settings.", "title": "2. Configuring the Git provider integration"}, {"location": "getting-started/integrating-codacy-with-your-git-workflow/#blocking-pull-requests", "text": "Once you've tested out Codacy for a while and you're happy with the level of feedback provided, you can decide to enforce the quality gates and use Codacy to block merging pull requests on your Git provider. This is the best way to protect your code from unwelcome changes and fully integrates code quality and coverage analysis into your development pipeline. Important To eliminate any false positives that could inadvertently block the work of your team, it's important that before activating this feature you: Validate that Codacy is reporting the intended status on your pull requests Double check you repository's tool and code pattern settings and quality gate settings Follow the instructions from your Git provider to block merging pull requests if they don't pass the Codacy status check: GitHub: set Codacy as a required status check GitLab: only allow merge requests to be merged if the pipeline succeeds Bitbucket: configure Bitbucket to prevent a merge with unresolved merge checks", "title": "3. Blocking merging pull requests (optional)"}, {"location": "getting-started/integrating-codacy-with-your-git-workflow/#youre-all-set", "text": "Congratulations! You've successfully integrated and set up your first repository.", "title": "You're all set! \ud83c\udf89"}, {"location": "getting-started/supported-languages-and-tools/", "text": "Supported languages and tools # Codacy uses industry-leading tools to perform automatic static code analysis over 40 supported languages: For programming languages , Codacy provides static analysis as well as code duplication, code complexity, secret detection, dependency vulnerability scanning, and code coverage metrics for key languages. For cloud infrastructure-as-code platforms , Codacy provides static analysis and secret detection to enforce security and compliance best practices. The table below lists all languages that Codacy supports and the corresponding tools that Codacy uses to analyze your source code. Besides this, Codacy uses cloc to calculate the source lines of code for all supported languages and supports multiple code coverage report formats . Important Codacy runs security and other analysis tools when code changes are pushed to your repositories. These tools don't scan code for issues continuously. Language Static analysis Suggested fixes Secret detection Dependency vulnerability scanning Duplication Complexity Apex PMD , Semgrep 1 - Semgrep - - - AsyncAPI Spectral - - - - - AWS CloudFormation Checkov - Checkov , Semgrep 2 , Trivy 2 - - - Azure Resource Manager Templates Checkov - - - - - C Clang-Tidy 3 , Cppcheck , Flawfinder , Semgrep 1 Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans conan.lock (Conan) PMD CPD - C++ Clang-Tidy 3 , Cppcheck 4 , Flawfinder , Semgrep 1 - Semgrep , Trivy Trivy , scans conan.lock (Conan) PMD CPD - C# Semgrep 1 , SonarC# Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans .deps.json (.Net), packages.lock.json (NuGet) PMD CPD SonarC# CoffeeScript CoffeeLint - - - jscpd - Crystal Ameba - - - - - CSS Stylelint - - - - - Dart dartanalyzer 5 - Trivy Trivy , scans pubspec.lock jscpd - Dockerfile Hadolint , Semgrep 1 Semgrep \ud83d\udd27 Semgrep , Trivy - - - Elixir Credo , Semgrep 1 - Trivy Trivy , scans mix.lock (Mix) jscpd - GitHub Actions Semgrep 1 - Semgrep , Trivy - - - Go aligncheck 3 , deadcode 3 , Gosec 3 , Revive , Semgrep 1 , Staticcheck 3 Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans go.mod PMD CPD Gocyclo Groovy CodeNarc - - - jscpd - Helm - - Semgrep 2 , Trivy 2 - - - Java Checkstyle , PMD , Semgrep 1 , SpotBugs 3 Semgrep \ud83d\udd27 PMD , Semgrep , Trivy Trivy , scans pom.xml and gradle.lockfile PMD CPD PMD 6 JavaScript ESLint , PMD , Semgrep 1 ESLint \ud83d\udd27 Semgrep , Trivy Trivy , scans package.json and package-lock.json (npm), yarn.lock (Yarn) PMD CPD ESLint 6 JSON Jackson Linter - Checkov , Trivy - - - JSP PMD - - - - - Kotlin detekt , Semgrep 1 - Semgrep Trivy , scans pom.xml and gradle.lockfile jscpd detekt Kubernetes Checkov , Semgrep 2 Semgrep \ud83d\udd27 Checkov , Semgrep 2 , Trivy 2 - - - Less Stylelint - - - - - Markdown remark-lint , markdownlint markdownlint \ud83d\udd27 - - - - Objective-C Clang-Tidy 3 - - - jscpd - OpenAPI Spectral - - - - - PHP PHP_CodeSniffer , PHP Mess Detector , Semgrep 1 - Semgrep , Trivy Trivy , scans composer.lock (Composer) PHPCPD PHP Depend PL/SQL PMD - - - - - PostgreSQL SQLint - - - - - PowerShell PSScriptAnalyser - - - - - Python Bandit , Prospector , Pylint , Semgrep 1 Semgrep \ud83d\udd27 Bandit , Prospector , Semgrep , Trivy Trivy , scans requirements.txt (pip), Pipfile.lock (pipenv), poetry.lock (Poetry) PMD CPD Radon Ruby Brakeman 7 , RuboCop , Semgrep 1 Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans Gemfile.lock (Bundler) Flay RuboCop 6 Rust Semgrep 1 - Semgrep , Trivy Trivy , scans Cargo.lock (Cargo) jscpd - Sass Stylelint - - - - - Scala Codacy Scalameta Pro , Scalastyle , Semgrep 1 , SpotBugs 3 - Semgrep , Trivy Trivy , scans build.sbt.lock (sbt) 9 PMD CPD Scalastyle , Scala 2 compiler and standard library Serverless Framework Checkov - - - - - Shell ShellCheck , Semgrep 1 - Semgrep - - - Swift Semgrep 1 , SwiftLint - Semgrep , Trivy Trivy , scans Package.resolved (SwiftPM) PMD CPD SwiftLint 6 8 Terraform Checkov , Semgrep 1 - Checkov , Semgrep , Trivy - - - Transact-SQL TSQLLint - - - - - TypeScript ESLint , Semgrep 1 ESLint \ud83d\udd27 Semgrep , Trivy Trivy , scans package.json and package-lock.json (npm), yarn.lock (Yarn) jscpd ESLint 6 Unity Unity Roslyn Analyzers 3 - - - - - Velocity PMD - - - - - Visual Basic SonarVB - - - jscpd - Visualforce PMD - - - - - XML PMD - Trivy - - - XSL PMD - - - - - YAML - - Trivy - - - Docker images of supported tools # Codacy adds support for new languages and tools by using a Docker image to run each tool . The following table lists the Codacy GitHub repositories corresponding to each supported tool. Use these repositories to check the extra plugins supported by each tool or to submit GitHub issues related to each tool. To learn more about the tool versions used by Codacy, see the latest release notes . Tool name Codacy GitHub repository aligncheck 3 codacy/codacy-aligncheck Ameba codacy/codacy-ameba Bandit codacy/codacy-bandit Brakeman 7 codacy/codacy-brakeman Checkov codacy/codacy-checkov Checkstyle codacy/codacy-checkstyle Clang-Tidy 3 codacy/codacy-clang-tidy Codacy Scalameta Pro codacy/codacy-scalameta CodeNarc codacy/codacy-codenarc CoffeeLint codacy/codacy-coffeelint Cppcheck 4 codacy/codacy-cppcheck Credo codacy/codacy-credo dartanalyzer 5 codacy/codacy-dartanalyzer deadcode 3 codacy/codacy-deadcode detekt codacy/codacy-detekt ESLint 6 codacy/codacy-eslint Flawfinder codacy/codacy-flawfinder Gosec 3 codacy/codacy-gosec Hadolint codacy/codacy-hadolint Jackson Linter codacy/codacy-jackson-linter markdownlint codacy/codacy-markdownlint PHP_CodeSniffer codacy/codacy-codesniffer PHP Mess Detector codacy/codacy-phpmd PMD 6 codacy/codacy-pmd Prospector codacy/codacy-prospector PSScriptAnalyser codacy/codacy-psscriptanalyzer Pylint codacy/codacy-pylint-python3 remark-lint codacy/codacy-remark-lint Revive codacy/codacy-gorevive RuboCop 6 codacy/codacy-rubocop Scalastyle codacy/codacy-scalastyle Semgrep 1 codacy/codacy-semgrep ShellCheck codacy/codacy-shellcheck SonarC# codacy/codacy-sonar-csharp SonarVB codacy/codacy-sonar-visual-basic Spectral codacy/codacy-spectral SpotBugs 3 codacy/codacy-spotbugs SQLint codacy/codacy-sqlint Staticcheck 3 codacy/codacy-staticcheck Stylelint codacy/codacy-stylelint SwiftLint 6 8 codacy/codacy-swiftlint Trivy codacy/codacy-trivy TSQLLint codacy/codacy-tsqllint Unity Roslyn Analyzers 3 codacy/codacy-roslyn 1 : Semgrep supports additional security rules when signing up for Semgrep Pro . This tool doesn't support custom file extensions . 2 : Currently, only YAML file scanning is supported on this platform. 3 : Supported as a client-side tool . 4 : Currently, Cppcheck only supports checking the MISRA guidelines for C . 5 : Currently, Codacy only supports including the packages lints and flutter_lints on dartanalyzer configuration files. 6 : Doesn't calculate the number of methods and the complexity per method for each file. 7 : Due to licensing limitations, Codacy doesn't support the latest version of Brakeman. To analyze your Ruby code for the latest security vulnerabilities, use Semgrep , which provides comprehensive and up-to-date security scanning. 8 : Supports reporting warnings or errors on functions above specific complexity thresholds. Enable the rule Cyclomatic Complexity on the Code patterns page , or use a configuration file to customize the thresholds. 9 : Requires the sbt-dependency-lock plugin for generating the lockfile. \ud83d\udd27 : Supports suggesting fixes for identified issues. See also # Codacy quickstart (5 min) Client-side tools Which metrics does Codacy calculate?", "title": "Supported languages and tools"}, {"location": "getting-started/supported-languages-and-tools/#supported-languages-and-tools", "text": "Codacy uses industry-leading tools to perform automatic static code analysis over 40 supported languages: For programming languages , Codacy provides static analysis as well as code duplication, code complexity, secret detection, dependency vulnerability scanning, and code coverage metrics for key languages. For cloud infrastructure-as-code platforms , Codacy provides static analysis and secret detection to enforce security and compliance best practices. The table below lists all languages that Codacy supports and the corresponding tools that Codacy uses to analyze your source code. Besides this, Codacy uses cloc to calculate the source lines of code for all supported languages and supports multiple code coverage report formats . Important Codacy runs security and other analysis tools when code changes are pushed to your repositories. These tools don't scan code for issues continuously. Language Static analysis Suggested fixes Secret detection Dependency vulnerability scanning Duplication Complexity Apex PMD , Semgrep 1 - Semgrep - - - AsyncAPI Spectral - - - - - AWS CloudFormation Checkov - Checkov , Semgrep 2 , Trivy 2 - - - Azure Resource Manager Templates Checkov - - - - - C Clang-Tidy 3 , Cppcheck , Flawfinder , Semgrep 1 Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans conan.lock (Conan) PMD CPD - C++ Clang-Tidy 3 , Cppcheck 4 , Flawfinder , Semgrep 1 - Semgrep , Trivy Trivy , scans conan.lock (Conan) PMD CPD - C# Semgrep 1 , SonarC# Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans .deps.json (.Net), packages.lock.json (NuGet) PMD CPD SonarC# CoffeeScript CoffeeLint - - - jscpd - Crystal Ameba - - - - - CSS Stylelint - - - - - Dart dartanalyzer 5 - Trivy Trivy , scans pubspec.lock jscpd - Dockerfile Hadolint , Semgrep 1 Semgrep \ud83d\udd27 Semgrep , Trivy - - - Elixir Credo , Semgrep 1 - Trivy Trivy , scans mix.lock (Mix) jscpd - GitHub Actions Semgrep 1 - Semgrep , Trivy - - - Go aligncheck 3 , deadcode 3 , Gosec 3 , Revive , Semgrep 1 , Staticcheck 3 Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans go.mod PMD CPD Gocyclo Groovy CodeNarc - - - jscpd - Helm - - Semgrep 2 , Trivy 2 - - - Java Checkstyle , PMD , Semgrep 1 , SpotBugs 3 Semgrep \ud83d\udd27 PMD , Semgrep , Trivy Trivy , scans pom.xml and gradle.lockfile PMD CPD PMD 6 JavaScript ESLint , PMD , Semgrep 1 ESLint \ud83d\udd27 Semgrep , Trivy Trivy , scans package.json and package-lock.json (npm), yarn.lock (Yarn) PMD CPD ESLint 6 JSON Jackson Linter - Checkov , Trivy - - - JSP PMD - - - - - Kotlin detekt , Semgrep 1 - Semgrep Trivy , scans pom.xml and gradle.lockfile jscpd detekt Kubernetes Checkov , Semgrep 2 Semgrep \ud83d\udd27 Checkov , Semgrep 2 , Trivy 2 - - - Less Stylelint - - - - - Markdown remark-lint , markdownlint markdownlint \ud83d\udd27 - - - - Objective-C Clang-Tidy 3 - - - jscpd - OpenAPI Spectral - - - - - PHP PHP_CodeSniffer , PHP Mess Detector , Semgrep 1 - Semgrep , Trivy Trivy , scans composer.lock (Composer) PHPCPD PHP Depend PL/SQL PMD - - - - - PostgreSQL SQLint - - - - - PowerShell PSScriptAnalyser - - - - - Python Bandit , Prospector , Pylint , Semgrep 1 Semgrep \ud83d\udd27 Bandit , Prospector , Semgrep , Trivy Trivy , scans requirements.txt (pip), Pipfile.lock (pipenv), poetry.lock (Poetry) PMD CPD Radon Ruby Brakeman 7 , RuboCop , Semgrep 1 Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans Gemfile.lock (Bundler) Flay RuboCop 6 Rust Semgrep 1 - Semgrep , Trivy Trivy , scans Cargo.lock (Cargo) jscpd - Sass Stylelint - - - - - Scala Codacy Scalameta Pro , Scalastyle , Semgrep 1 , SpotBugs 3 - Semgrep , Trivy Trivy , scans build.sbt.lock (sbt) 9 PMD CPD Scalastyle , Scala 2 compiler and standard library Serverless Framework Checkov - - - - - Shell ShellCheck , Semgrep 1 - Semgrep - - - Swift Semgrep 1 , SwiftLint - Semgrep , Trivy Trivy , scans Package.resolved (SwiftPM) PMD CPD SwiftLint 6 8 Terraform Checkov , Semgrep 1 - Checkov , Semgrep , Trivy - - - Transact-SQL TSQLLint - - - - - TypeScript ESLint , Semgrep 1 ESLint \ud83d\udd27 Semgrep , Trivy Trivy , scans package.json and package-lock.json (npm), yarn.lock (Yarn) jscpd ESLint 6 Unity Unity Roslyn Analyzers 3 - - - - - Velocity PMD - - - - - Visual Basic SonarVB - - - jscpd - Visualforce PMD - - - - - XML PMD - Trivy - - - XSL PMD - - - - - YAML - - Trivy - - -", "title": "Supported languages and tools"}, {"location": "getting-started/supported-languages-and-tools/#docker-images-of-supported-tools", "text": "Codacy adds support for new languages and tools by using a Docker image to run each tool . The following table lists the Codacy GitHub repositories corresponding to each supported tool. Use these repositories to check the extra plugins supported by each tool or to submit GitHub issues related to each tool. To learn more about the tool versions used by Codacy, see the latest release notes . Tool name Codacy GitHub repository aligncheck 3 codacy/codacy-aligncheck Ameba codacy/codacy-ameba Bandit codacy/codacy-bandit Brakeman 7 codacy/codacy-brakeman Checkov codacy/codacy-checkov Checkstyle codacy/codacy-checkstyle Clang-Tidy 3 codacy/codacy-clang-tidy Codacy Scalameta Pro codacy/codacy-scalameta CodeNarc codacy/codacy-codenarc CoffeeLint codacy/codacy-coffeelint Cppcheck 4 codacy/codacy-cppcheck Credo codacy/codacy-credo dartanalyzer 5 codacy/codacy-dartanalyzer deadcode 3 codacy/codacy-deadcode detekt codacy/codacy-detekt ESLint 6 codacy/codacy-eslint Flawfinder codacy/codacy-flawfinder Gosec 3 codacy/codacy-gosec Hadolint codacy/codacy-hadolint Jackson Linter codacy/codacy-jackson-linter markdownlint codacy/codacy-markdownlint PHP_CodeSniffer codacy/codacy-codesniffer PHP Mess Detector codacy/codacy-phpmd PMD 6 codacy/codacy-pmd Prospector codacy/codacy-prospector PSScriptAnalyser codacy/codacy-psscriptanalyzer Pylint codacy/codacy-pylint-python3 remark-lint codacy/codacy-remark-lint Revive codacy/codacy-gorevive RuboCop 6 codacy/codacy-rubocop Scalastyle codacy/codacy-scalastyle Semgrep 1 codacy/codacy-semgrep ShellCheck codacy/codacy-shellcheck SonarC# codacy/codacy-sonar-csharp SonarVB codacy/codacy-sonar-visual-basic Spectral codacy/codacy-spectral SpotBugs 3 codacy/codacy-spotbugs SQLint codacy/codacy-sqlint Staticcheck 3 codacy/codacy-staticcheck Stylelint codacy/codacy-stylelint SwiftLint 6 8 codacy/codacy-swiftlint Trivy codacy/codacy-trivy TSQLLint codacy/codacy-tsqllint Unity Roslyn Analyzers 3 codacy/codacy-roslyn 1 : Semgrep supports additional security rules when signing up for Semgrep Pro . This tool doesn't support custom file extensions . 2 : Currently, only YAML file scanning is supported on this platform. 3 : Supported as a client-side tool . 4 : Currently, Cppcheck only supports checking the MISRA guidelines for C . 5 : Currently, Codacy only supports including the packages lints and flutter_lints on dartanalyzer configuration files. 6 : Doesn't calculate the number of methods and the complexity per method for each file. 7 : Due to licensing limitations, Codacy doesn't support the latest version of Brakeman. To analyze your Ruby code for the latest security vulnerabilities, use Semgrep , which provides comprehensive and up-to-date security scanning. 8 : Supports reporting warnings or errors on functions above specific complexity thresholds. Enable the rule Cyclomatic Complexity on the Code patterns page , or use a configuration file to customize the thresholds. 9 : Requires the sbt-dependency-lock plugin for generating the lockfile. \ud83d\udd27 : Supports suggesting fixes for identified issues.", "title": "Docker images of supported tools"}, {"location": "getting-started/supported-languages-and-tools/#see-also", "text": "Codacy quickstart (5 min) Client-side tools Which metrics does Codacy calculate?", "title": "See also"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/", "text": "Which permissions does Codacy need from my account? # Codacy Cloud uses the OAuth protocol to handle logins and supports the following providers: GitHub Cloud GitLab Cloud Bitbucket Cloud Codacy requests only the necessary permissions from your Git provider to analyze your code and keeps your information secure . See the sections below for the detailed list of permissions that Codacy asks for depending on the provider. GitHub Cloud # If you log in with GitHub, Codacy requires the following app permissions : Scope Permissions Description Repository permissions: Checks Read & Write Codacy creates and updates check runs with the results of code analysis. Issues Read & Write Codacy can create GitHub issues from issues found during code analysis. Metadata Read-Only Codacy retrieves repository metadata, such as name, languages, collaborators and commit information. Pull requests Read & Write Codacy retrieves pull request information to display on its side. Codacy might also create comments and suggestions on the pull request, according to the results of code analysis. Webhooks Read & Write Codacy creates webhooks for code pushes and pull request events (created, merged, etc.). These events might trigger code analysis. Commit statuses Read & Write Codacy sets the status of commits according to the result of code analysis. Contents Read-Only Codacy retrieves repository contents to get installation access tokens when integrating with your repositories and clone them, and for code coverage analysis. Codacy requests this permission since September 2023. Make sure an organization owner approves Codacy GitHub App updated permissions on your GitHub organization. Organization permissions: Webhooks Read & Write Codacy creates webhooks for organization and repository events (creation, deletion, member added, etc.). Members Read-Only Codacy retrieves information about organization members and teams to enforce permissions and user management. User permissions: These permissions are granted on an individual user basis as part of the user authorization flow. They will be also be displayed during account installation for transparency. Email addresses Read-Only Codacy retrieves the user's email addresses to enforce which commits are eligible for analysis. GitLab Cloud # If you sign up with GitLab Cloud, Codacy requires the following permissions/scopes : Scope Description api Codacy uses GitLab's API to read and update pull requests, create webhooks for code push events, list commits, repositories, groups, members and permissions. read_user Codacy retrieves the user's email addresses to enforce which commits are eligible for analysis. read_repository Codacy retrieves repository metadata, such as name, languages and collaborators. openid Codacy uses this permission for authentication using OpenID Connect . Bitbucket Cloud # If you log in with Bitbucket, Codacy requires the following permissions/scopes : Scope and permissions Description account:write Codacy retrieves the user's email addresses to enforce which commits are eligible for analysis. repository:admin Codacy retrieves repository metadata, such as name, languages and collaborators, and commit information. Codacy creates an SSH key on the repository to allow cloning and integrating with your repository. pullrequest:write Codacy retrieves pull request information to display on its side. Codacy might also create comments on the pull request, according to the results of code analysis. issue:write Codacy can create Bitbucket issues from issues found during code analysis. webhook Codacy creates webhooks for code pushes and pull request events (created, merged, etc.). These events might trigger code analysis. team Codacy uses your group/team membership information to enforce permissions. Read your workspace's project settings and read repositories contained within your workspace's projects. Revoking access to integrations # To revoke the access from Codacy to one or more of the OAuth providers: Click on your avatar on the top right-hand corner and select Your Account , tab Access Management . The Access Management page lists all current integrations with Git providers that you used to sign in or log in to Codacy. To revoke access to an integration, click the button Revoke access for the intended integration. To ensure that the integration is removed not only on Codacy but also on the integration side, it's important that you revoke the Codacy OAuth application access on your provider: GitHub Cloud GitLab Cloud Bitbucket Cloud After revoking an integration, Codacy will no longer be able to access or manipulate resources that require API calls, such as detecting new pull requests or adding comments to pull requests. However, Codacy will still be able to perform operations that only require using the Git protocol either via SSH or HTTPS, such as detecting new commits and calculating diffs. To remove your repositories from Codacy and stop the analysis you must delete them from your Codacy account . If you need to use an integration that you have previously revoked, log in again to Codacy with that integration so that Codacy can request the required permissions from the provider. Why does Codacy ask for permission to create SSH keys? # This section applies only to GitLab and Bitbucket On GitLab and Bitbucket organizations, when you add a private repository to Codacy, Codacy uses the integration with your Git provider to create a new SSH key on the repository. Codacy then uses that SSH key every time it needs to clone the repository. Codacy only adds read-only SSH keys and can't access any of your existing SSH keys. You have full control over which organizations and repositories Codacy is authorized to access. Codacy doesn't change the contents or member privileges of any repository you authorize it to analyze. We understand the desire for security and privacy and find that the SSH protocol is preferable to HTTPS as it separates Codacy's access rights from the one of the users. Tip You can revoke the keys created by Codacy at any time. See GitLab or Bitbucket documentation for further details.", "title": "Which permissions does Codacy need from my account?"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/#which-permissions-does-codacy-need-from-my-account", "text": "Codacy Cloud uses the OAuth protocol to handle logins and supports the following providers: GitHub Cloud GitLab Cloud Bitbucket Cloud Codacy requests only the necessary permissions from your Git provider to analyze your code and keeps your information secure . See the sections below for the detailed list of permissions that Codacy asks for depending on the provider.", "title": "Which permissions does Codacy need from my account?"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/#github-cloud", "text": "If you log in with GitHub, Codacy requires the following app permissions : Scope Permissions Description Repository permissions: Checks Read & Write Codacy creates and updates check runs with the results of code analysis. Issues Read & Write Codacy can create GitHub issues from issues found during code analysis. Metadata Read-Only Codacy retrieves repository metadata, such as name, languages, collaborators and commit information. Pull requests Read & Write Codacy retrieves pull request information to display on its side. Codacy might also create comments and suggestions on the pull request, according to the results of code analysis. Webhooks Read & Write Codacy creates webhooks for code pushes and pull request events (created, merged, etc.). These events might trigger code analysis. Commit statuses Read & Write Codacy sets the status of commits according to the result of code analysis. Contents Read-Only Codacy retrieves repository contents to get installation access tokens when integrating with your repositories and clone them, and for code coverage analysis. Codacy requests this permission since September 2023. Make sure an organization owner approves Codacy GitHub App updated permissions on your GitHub organization. Organization permissions: Webhooks Read & Write Codacy creates webhooks for organization and repository events (creation, deletion, member added, etc.). Members Read-Only Codacy retrieves information about organization members and teams to enforce permissions and user management. User permissions: These permissions are granted on an individual user basis as part of the user authorization flow. They will be also be displayed during account installation for transparency. Email addresses Read-Only Codacy retrieves the user's email addresses to enforce which commits are eligible for analysis.", "title": "GitHub Cloud"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/#gitlab-cloud", "text": "If you sign up with GitLab Cloud, Codacy requires the following permissions/scopes : Scope Description api Codacy uses GitLab's API to read and update pull requests, create webhooks for code push events, list commits, repositories, groups, members and permissions. read_user Codacy retrieves the user's email addresses to enforce which commits are eligible for analysis. read_repository Codacy retrieves repository metadata, such as name, languages and collaborators. openid Codacy uses this permission for authentication using OpenID Connect .", "title": "GitLab Cloud"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/#bitbucket-cloud", "text": "If you log in with Bitbucket, Codacy requires the following permissions/scopes : Scope and permissions Description account:write Codacy retrieves the user's email addresses to enforce which commits are eligible for analysis. repository:admin Codacy retrieves repository metadata, such as name, languages and collaborators, and commit information. Codacy creates an SSH key on the repository to allow cloning and integrating with your repository. pullrequest:write Codacy retrieves pull request information to display on its side. Codacy might also create comments on the pull request, according to the results of code analysis. issue:write Codacy can create Bitbucket issues from issues found during code analysis. webhook Codacy creates webhooks for code pushes and pull request events (created, merged, etc.). These events might trigger code analysis. team Codacy uses your group/team membership information to enforce permissions. Read your workspace's project settings and read repositories contained within your workspace's projects.", "title": "Bitbucket Cloud"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/#revoking-access-to-integrations", "text": "To revoke the access from Codacy to one or more of the OAuth providers: Click on your avatar on the top right-hand corner and select Your Account , tab Access Management . The Access Management page lists all current integrations with Git providers that you used to sign in or log in to Codacy. To revoke access to an integration, click the button Revoke access for the intended integration. To ensure that the integration is removed not only on Codacy but also on the integration side, it's important that you revoke the Codacy OAuth application access on your provider: GitHub Cloud GitLab Cloud Bitbucket Cloud After revoking an integration, Codacy will no longer be able to access or manipulate resources that require API calls, such as detecting new pull requests or adding comments to pull requests. However, Codacy will still be able to perform operations that only require using the Git protocol either via SSH or HTTPS, such as detecting new commits and calculating diffs. To remove your repositories from Codacy and stop the analysis you must delete them from your Codacy account . If you need to use an integration that you have previously revoked, log in again to Codacy with that integration so that Codacy can request the required permissions from the provider.", "title": "Revoking access to integrations"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/#why-does-codacy-ask-for-permission-to-create-ssh-keys", "text": "This section applies only to GitLab and Bitbucket On GitLab and Bitbucket organizations, when you add a private repository to Codacy, Codacy uses the integration with your Git provider to create a new SSH key on the repository. Codacy then uses that SSH key every time it needs to clone the repository. Codacy only adds read-only SSH keys and can't access any of your existing SSH keys. You have full control over which organizations and repositories Codacy is authorized to access. Codacy doesn't change the contents or member privileges of any repository you authorize it to analyze. We understand the desire for security and privacy and find that the SSH protocol is preferable to HTTPS as it separates Codacy's access rights from the one of the users. Tip You can revoke the keys created by Codacy at any time. See GitLab or Bitbucket documentation for further details.", "title": "Why does Codacy ask for permission to create SSH keys?"}, {"location": "organizations/audit-logs-for-organizations/", "text": "Audit logs for organizations # This feature is only available on Business plan Codacy logs important events in your organization, reflecting when your team members execute specific operations. This enables the generation of comprehensive reports to assist you with the audit process. For example, you can track who added a repository to Codacy, or changed the settings of a coding standard. Organization admins and organization managers can obtain the audit log data of the organization events using the Codacy API endpoint listAuditLogsForOrganization . The retention period of audit logs for organization events is one year. Audit log events # Each audit log tracks when a Codacy user executed a specific operation in your organization using the Codacy app or the Codacy API . Each operation is identified by an action . For the detailed content of each audit log, see the Codacy API reference . The sections below list the events that Codacy logs for your organization at user, organization, and repository levels. User # Event Description Action Log in User logged in to Codacy user.login Create account API token New account API token created user.tokens.create Read account API token List of account API tokens retrieved user.tokens.read Delete account API token Account API token deleted user.tokens.delete Organization # Event Description Action Add organization Organization added to Codacy organizations.create Add people to organization New people added to the organization organizations.people.create Join organization User joined the organization organizations.join Update repository management permissions Repository management permissions updated organizations.analysisconfigurationminimumpermission.update Assign organization manager role Organization manager role assigned to a team member organizations.security.managers.create Revoke organization manager role Organization manager role revoked from a team member organizations.security.managers.delete Update default Git provider configuration Default Git provider configuration for the organization updated organizations.integrations.providersettings.update Apply default Git provider configuration to all repositories Default Git provider configuration applied to all repositories of the organization organizations.integrations.providersettings.apply Create new organization hook New organization webhook created organizations.settings.hooks.create Create new gate policy New gate policy created organizations.gatepolicies.create Update gate policy Quality gate definition updated organizations.gatepolicies.update Apply gate policy to repositories Gate policy applied to a list of repositories organizations.gatepolicies.repositories.apply Make gate policy default Gate policy was made the default for the organization organizations.gatepolicies.setdefault Make Codacy gate policy default Built-in Codacy gate policy was made the default for the organization organizations.gatepolicies.setcodacydefault Delete gate policy Gate policy deleted organizations.gatepolicies.delete Create new coding standard using preset sensitivity levels New coding standard created organizations.presetsstandards.create Create new coding standard draft using individual language and code pattern settings New coding standard draft created organizations.codingstandards.create Create new coding standard from draft New coding standard created organizations.codingstandards.promote Update coding standard from draft Coding standard updated organizations.codingstandards.promote Apply coding standard to repositories Coding standard applied to a list of repositories organizations.codingstandards.repositories.apply Make coding standard default Coding standard was made the default organizations.codingstandards.setdefault Delete coding standard Coding standard deleted organizations.codingstandards.delete Repository # Event Description Action Create new post-commit hook New repository hook created repositories.integrations.postcommithook Create repository API token New repository API token created repositories.tokens.create Read repository API token List of repository API tokens retrieved repositories.tokens.read Delete repository API token Repository API token deleted repositories.tokens.delete Update Git provider integration settings ( GitHub , Bitbucket , or GitLab ) Git provider integration settings for the repository updated repositories.integrations.providersettings.update Refresh Git provider integration (applies only to Bitbucket and GitLab ) Git provider integration for the repository refreshed repositories.integrations.refreshprovider", "title": "Audit logs for organizations"}, {"location": "organizations/audit-logs-for-organizations/#audit-logs-for-organizations", "text": "This feature is only available on Business plan Codacy logs important events in your organization, reflecting when your team members execute specific operations. This enables the generation of comprehensive reports to assist you with the audit process. For example, you can track who added a repository to Codacy, or changed the settings of a coding standard. Organization admins and organization managers can obtain the audit log data of the organization events using the Codacy API endpoint listAuditLogsForOrganization . The retention period of audit logs for organization events is one year.", "title": "Audit logs for organizations"}, {"location": "organizations/audit-logs-for-organizations/#audit-log-events", "text": "Each audit log tracks when a Codacy user executed a specific operation in your organization using the Codacy app or the Codacy API . Each operation is identified by an action . For the detailed content of each audit log, see the Codacy API reference . The sections below list the events that Codacy logs for your organization at user, organization, and repository levels.", "title": "Audit log events"}, {"location": "organizations/changing-your-plan-and-billing/", "text": "Changing your plan and billing # Each organization on Codacy has a dedicated plan and associated billing. To make changes to the plan and billing of an organization, open your organization Settings , page Plan and billing . Note If you're using GitHub Marketplace, update your billing details or cancel your plan directly on your GitHub Billing page . If you cancel your plan or switch to a different Enterprise plan, some repositories may show outdated information in the Codacy UI. To update this information, reanalyze the repositories or push new commits. To upgrade to the Pro plan click Choose plan , choose between monthly or yearly billing, and provide your payment and invoice details To make changes to your Pro plan or invoice details click Edit plan details or click Edit invoice details If you have any questions or need help with your account, please contact support@codacy.com . Allowing new people to join your organization # On Codacy Cloud , organization admins control if team members need an approval before joining their organization. Codacy updates your seats automatically when new users join an organization. Note If you're using GitHub Marketplace, this configuration isn't available and team members must always wait for an organization owner to manually approve their requests to join the organization. In some Enterprise plans , Codacy automatically adds to the organization new people that commit to your private repositories. However, they still need to join the organization on the Codacy app if they want to use the UI. Choose one of the following options in your organization Settings , page Plan and billing : Allow new people to join immediately: people with access to the organization on the Git provider can join the organization on the Codacy app immediately, as long as there are seats available. Review join requests from new people: when people with access to the organization on the Git provider join the organization on Codacy app, an organization admin must manually approve their requests to join on the page People . Your teammates that have already been invited to join or were added to the organization are automatically approved, and you can also skip the approval process for organization admins.", "title": "Changing your plan and billing"}, {"location": "organizations/changing-your-plan-and-billing/#changing-your-plan-and-billing", "text": "Each organization on Codacy has a dedicated plan and associated billing. To make changes to the plan and billing of an organization, open your organization Settings , page Plan and billing . Note If you're using GitHub Marketplace, update your billing details or cancel your plan directly on your GitHub Billing page . If you cancel your plan or switch to a different Enterprise plan, some repositories may show outdated information in the Codacy UI. To update this information, reanalyze the repositories or push new commits. To upgrade to the Pro plan click Choose plan , choose between monthly or yearly billing, and provide your payment and invoice details To make changes to your Pro plan or invoice details click Edit plan details or click Edit invoice details If you have any questions or need help with your account, please contact support@codacy.com .", "title": "Changing your plan and billing"}, {"location": "organizations/changing-your-plan-and-billing/#allowing-new-people-to-join-your-organization", "text": "On Codacy Cloud , organization admins control if team members need an approval before joining their organization. Codacy updates your seats automatically when new users join an organization. Note If you're using GitHub Marketplace, this configuration isn't available and team members must always wait for an organization owner to manually approve their requests to join the organization. In some Enterprise plans , Codacy automatically adds to the organization new people that commit to your private repositories. However, they still need to join the organization on the Codacy app if they want to use the UI. Choose one of the following options in your organization Settings , page Plan and billing : Allow new people to join immediately: people with access to the organization on the Git provider can join the organization on the Codacy app immediately, as long as there are seats available. Review join requests from new people: when people with access to the organization on the Git provider join the organization on Codacy app, an organization admin must manually approve their requests to join on the page People . Your teammates that have already been invited to join or were added to the organization are automatically approved, and you can also skip the approval process for organization admins.", "title": "Allowing new people to join your organization"}, {"location": "organizations/managing-people/", "text": "Managing people # People signing up to the Codacy app and joining an organization become members of that organization. Members of a Codacy organization can see the dashboards and details of the organization repositories. Depending on their permissions on the Git provider, members can also manage the organization and repository settings on Codacy. For private repositories , Codacy only analyzes commits from people in your Codacy organization. To make sure that Codacy analyzes all relevant commits, add to your Codacy organization the committers that aren't members of the organization yet. Important Make sure that you invite or ask your teammates to join your organization on Codacy so that Codacy analyzes their commits to private repositories. Committers who aren't part of your Git provider organization can't join your organization on Codacy app, but you should still add them to your Codacy organization to analyze their commits to private repositories. To list and manage the people in your organization, open your organization Settings , page People . This page also shows their last activity on Codacy. Note In some Enterprise plans, Codacy automatically assigns a seat to any person with at least one analyzed commit to your private repositories over the past 90 days and frees up the seat after 90 days of code analysis inactivity. Joining an organization # To become a member of an organization on Codacy app you must sign up to Codacy using your Git provider and follow the instructions to either join an existing organization or add a new one. To join or add an organization after completing the sign-up process, click Organizations on the top right-hand menu under your avatar: Note On Codacy Cloud , organization admins control if team members need an approval before joining their organizations. Adding people to your organization # On Codacy Cloud , organization admins can also add teammates to their organization on Codacy. This is useful to allow Codacy to analyze commits to private repositories by committers who haven't signed up to Codacy or joined the organization yet. Tip You can also use the Codacy API to add people to your Codacy organization . This is useful while adding a large amount of people or to automatically add new members of your Git provider organization to Codacy. To add people to your organization: Open your organization Settings , page People , and click the button Add people . Note For Enterprise plans where Codacy automatically adds new committers to your organization, you can invite them to join the organization on the Codacy app by clicking the Invite people button. Select people from the list displaying pending requests to join the organization, as well as recent committers to the private repositories in your organization. Alternatively, click Add people using email addresses to manually enter the list of email addresses of the people you wish to add. Important To prevent the same person from occupying more than one seat in your organization, make sure your teammates update the email addresses associated with their Codacy account . On GitHub and Bitbucket organizations , Codacy automatically reduces seat duplication when commits are pushed by associating all the commit email addresses from the same Git provider user with a single Codacy committer. This mechanism requires that all developers committing to your private repositories set their Git email address and add all their email addresses to their GitHub account or Bitbucket account . Confirm the updated billing details displayed at the bottom of the window and click the button Add people . Codacy emails the newly added people inviting them to log in. Removing people from your organization # Members of an organization on Codacy can remove themselves from the organization, and organization admins can also remove other members and committers. When a member or committer leaves an organization: Codacy stops analyzing their commits to private repositories in the organization On GitLab and Bitbucket organizations Codacy stops analyzing repositories that were added by the member Organizations must have at least one admin, so when the last organization admin leaves the organization they must either add someone else as admin or delete the organization To remove people from your organization open your organization Settings , page People , click the icon next to the member or committer you wish to remove, and select Remove from organization . Note For Enterprise plans where Codacy automatically manages seat usage for your organization, you can't remove people who had their commits analyzed within the last 90 days because their are still active within the billing period. However, if you remove them from the organization on your Git provider, they no longer have permissions to your repositories on Codacy. See also # Adding people to Codacy programmatically Roles and permissions for organizations", "title": "Managing people"}, {"location": "organizations/managing-people/#managing-people", "text": "People signing up to the Codacy app and joining an organization become members of that organization. Members of a Codacy organization can see the dashboards and details of the organization repositories. Depending on their permissions on the Git provider, members can also manage the organization and repository settings on Codacy. For private repositories , Codacy only analyzes commits from people in your Codacy organization. To make sure that Codacy analyzes all relevant commits, add to your Codacy organization the committers that aren't members of the organization yet. Important Make sure that you invite or ask your teammates to join your organization on Codacy so that Codacy analyzes their commits to private repositories. Committers who aren't part of your Git provider organization can't join your organization on Codacy app, but you should still add them to your Codacy organization to analyze their commits to private repositories. To list and manage the people in your organization, open your organization Settings , page People . This page also shows their last activity on Codacy. Note In some Enterprise plans, Codacy automatically assigns a seat to any person with at least one analyzed commit to your private repositories over the past 90 days and frees up the seat after 90 days of code analysis inactivity.", "title": "Managing people"}, {"location": "organizations/managing-people/#joining", "text": "To become a member of an organization on Codacy app you must sign up to Codacy using your Git provider and follow the instructions to either join an existing organization or add a new one. To join or add an organization after completing the sign-up process, click Organizations on the top right-hand menu under your avatar: Note On Codacy Cloud , organization admins control if team members need an approval before joining their organizations.", "title": "Joining an organization"}, {"location": "organizations/managing-people/#adding-people", "text": "On Codacy Cloud , organization admins can also add teammates to their organization on Codacy. This is useful to allow Codacy to analyze commits to private repositories by committers who haven't signed up to Codacy or joined the organization yet. Tip You can also use the Codacy API to add people to your Codacy organization . This is useful while adding a large amount of people or to automatically add new members of your Git provider organization to Codacy. To add people to your organization: Open your organization Settings , page People , and click the button Add people . Note For Enterprise plans where Codacy automatically adds new committers to your organization, you can invite them to join the organization on the Codacy app by clicking the Invite people button. Select people from the list displaying pending requests to join the organization, as well as recent committers to the private repositories in your organization. Alternatively, click Add people using email addresses to manually enter the list of email addresses of the people you wish to add. Important To prevent the same person from occupying more than one seat in your organization, make sure your teammates update the email addresses associated with their Codacy account . On GitHub and Bitbucket organizations , Codacy automatically reduces seat duplication when commits are pushed by associating all the commit email addresses from the same Git provider user with a single Codacy committer. This mechanism requires that all developers committing to your private repositories set their Git email address and add all their email addresses to their GitHub account or Bitbucket account . Confirm the updated billing details displayed at the bottom of the window and click the button Add people . Codacy emails the newly added people inviting them to log in.", "title": "Adding people to your organization"}, {"location": "organizations/managing-people/#removing-people", "text": "Members of an organization on Codacy can remove themselves from the organization, and organization admins can also remove other members and committers. When a member or committer leaves an organization: Codacy stops analyzing their commits to private repositories in the organization On GitLab and Bitbucket organizations Codacy stops analyzing repositories that were added by the member Organizations must have at least one admin, so when the last organization admin leaves the organization they must either add someone else as admin or delete the organization To remove people from your organization open your organization Settings , page People , click the icon next to the member or committer you wish to remove, and select Remove from organization . Note For Enterprise plans where Codacy automatically manages seat usage for your organization, you can't remove people who had their commits analyzed within the last 90 days because their are still active within the billing period. However, if you remove them from the organization on your Git provider, they no longer have permissions to your repositories on Codacy.", "title": "Removing people from your organization"}, {"location": "organizations/managing-people/#see-also", "text": "Adding people to Codacy programmatically Roles and permissions for organizations", "title": "See also"}, {"location": "organizations/managing-repositories/", "text": "Managing repositories # Users with the necessary permissions on your Git provider can add repositories to Codacy to start analyzing them. The remaining organization members with access to the added repositories can then follow on Codacy the repositories of their interest. Important To see your repositories on Codacy, make sure that you have the necessary permissions over the repositories on the Git provider and that Codacy has the necessary permissions to access the repositories. To see all the repositories that you follow on Codacy, open the page Repositories under your organization. Organization admins also see the total number of repositories that have already been added to the organization . Across the application, Codacy calculates and displays data for the repositories on this list. This page lists the repositories that you follow on Codacy sorted by last updated date , and allows you to compare the repositories on the list according to the following metrics: Grade Issues Complexity Duplication Coverage The list also displays error and warning messages for repositories that have issues, such as when there are no committers added to the organization or when Codacy stopped having access to the repository. Hover the mouse cursor over the warning icons or open the repository to see more details. If you follow many repositories, you can use the search field above the list to quickly find a specific repository. Adding a repository # Analyzing private repositories is only available on paid plans Users with the necessary permissions can add a repository to Codacy to start analyzing it. Note When a user adds a new repository to Codacy, all organization admins start following it automatically. To add new repositories to Codacy: Click the button Manage repositories at the top right-hand corner of the page. This opens a window listing your organization repositories. Click Add next to the repositories you want to add. If you have many repositories, you can use the search field above the list to quickly find a specific repository. When you're done, close the window to return to your repositories list. Although Codacy immediately starts analyzing newly added repositories, they display empty metrics until the first analysis returns results. Following or unfollowing a repository # Users with no permission to add a repository to Codacy, can follow that repository after it has been added to Codacy, and stop following it at any time. To follow or unfollow repositories on Codacy: Click the button Manage repositories at the top right-hand corner of the page. This opens a window listing your organization repositories. Click Follow or Unfollow next to the repositories you want to follow or unfollow. If you have many repositories, you can use the search field above the list to quickly find a specific repository. When you're done, close the window to return to your repositories list. Note You automatically start following a repository as soon as you access any page from that repository. For example, when you access the repository using a direct link on your Git provider UI. Conversely, you automatically stop following a repository as soon as you try accessing any page from that repository but you don't have permissions to see that repository anymore. See also # Which metrics does Codacy calculate?", "title": "Managing repositories"}, {"location": "organizations/managing-repositories/#managing-repositories", "text": "Users with the necessary permissions on your Git provider can add repositories to Codacy to start analyzing them. The remaining organization members with access to the added repositories can then follow on Codacy the repositories of their interest. Important To see your repositories on Codacy, make sure that you have the necessary permissions over the repositories on the Git provider and that Codacy has the necessary permissions to access the repositories. To see all the repositories that you follow on Codacy, open the page Repositories under your organization. Organization admins also see the total number of repositories that have already been added to the organization . Across the application, Codacy calculates and displays data for the repositories on this list. This page lists the repositories that you follow on Codacy sorted by last updated date , and allows you to compare the repositories on the list according to the following metrics: Grade Issues Complexity Duplication Coverage The list also displays error and warning messages for repositories that have issues, such as when there are no committers added to the organization or when Codacy stopped having access to the repository. Hover the mouse cursor over the warning icons or open the repository to see more details. If you follow many repositories, you can use the search field above the list to quickly find a specific repository.", "title": "Managing repositories"}, {"location": "organizations/managing-repositories/#adding-a-repository", "text": "Analyzing private repositories is only available on paid plans Users with the necessary permissions can add a repository to Codacy to start analyzing it. Note When a user adds a new repository to Codacy, all organization admins start following it automatically. To add new repositories to Codacy: Click the button Manage repositories at the top right-hand corner of the page. This opens a window listing your organization repositories. Click Add next to the repositories you want to add. If you have many repositories, you can use the search field above the list to quickly find a specific repository. When you're done, close the window to return to your repositories list. Although Codacy immediately starts analyzing newly added repositories, they display empty metrics until the first analysis returns results.", "title": "Adding a repository"}, {"location": "organizations/managing-repositories/#follow-unfollow", "text": "Users with no permission to add a repository to Codacy, can follow that repository after it has been added to Codacy, and stop following it at any time. To follow or unfollow repositories on Codacy: Click the button Manage repositories at the top right-hand corner of the page. This opens a window listing your organization repositories. Click Follow or Unfollow next to the repositories you want to follow or unfollow. If you have many repositories, you can use the search field above the list to quickly find a specific repository. When you're done, close the window to return to your repositories list. Note You automatically start following a repository as soon as you access any page from that repository. For example, when you access the repository using a direct link on your Git provider UI. Conversely, you automatically stop following a repository as soon as you try accessing any page from that repository but you don't have permissions to see that repository anymore.", "title": "Following or unfollowing a repository"}, {"location": "organizations/managing-repositories/#see-also", "text": "Which metrics does Codacy calculate?", "title": "See also"}, {"location": "organizations/managing-security-and-risk/", "text": "Managing security and risk # The Security and risk management feature helps you quickly identify, track, and address security across your organization by automatically opening time-bound, prioritized findings whenever security problems are detected in your organization repositories, in your connected Jira instance , or as a result of penetration testing . Under Security and risk management, you can find the following pages to help you monitor the security of your repositories: Overview Findings In addition, on these pages, you can share filtered views of findings , export findings as a CSV file , and review severity rules and integration settings Overview # The Security and risk management overview page provides a high-level view of the security posture of your organization, including the number of open findings, the distribution of open findings by severity, the history of finding resolution, and a breakdown of the most high-risk repositories and most detected security categories. Use this page to assess your organization's security posture and its progress over time, identify areas for improvement, and share findings with stakeholders. To access the overview page, select an organization from the top navigation bar and select Security and risk on the left navigation sidebar. The overview page includes six panels: Open findings overview Open findings distribution Open findings history Activity history Top 10 high-risk repositories Top 10 common security categories To limit the information displayed in each panel to a specific set of repositories, use the filter drop-down above the main area. Open findings overview # The Open findings overview panel displays the total number of open security findings and the number of findings of each severity, helping you quickly assess the overall security posture of your organization and quickly review findings that are critical or overdue. To access the findings page with the corresponding filter applied, click on a number. Open findings distribution # The Open findings distribution panel shows the relative distribution of open findings by scan type, severity, or status, helping you evaluate the distribution of risk across different criteria and identify areas that may need immediate attention. To select the desired distribution, use the drop-down in the top right-hand corner of the panel. To access the findings page with the corresponding filter applied, click on a number. Open findings history # The Open findings history graph shows the open findings trends over the past three months, grouped by week and severity. It details the progression of your organization's risk and security posture over time and can, for example, help you understand if the right issues are being addressed. For a detailed view of the distribution on a specific week, hover over the graph. Activity history # The Activity history graph shows weekly counts of open and closed findings over the past three months, overlaid on the overall open findings trend. It complements the Open findings history graph with more information, such as the volume of findings addressed each week and a visual representation of the new/closed ratio. To filter the graph by finding severity, use the drop-down in the top right-hand corner of the panel. For a detailed view of the counts on a specific week, hover over the graph. Top 10 high-risk repositories # The Top 10 high-risk repositories list shows the repositories with the highest number of open findings, ordered by severity. Note This panel may list fewer than ten repositories if there are fewer than ten repositories with open findings in the organization or if fewer than ten repositories are selected in the dropdown Repository filter. Top 10 common security categories # The Top 10 common security categories list shows the most common security categories of open findings, ordered by count. To access the findings page with the corresponding filter applied, click on a category. Findings # The Security and risk management findings page displays a filtered list of findings. By default, this list is sorted by status, and you can click the First detected column name to sort the findings by the detection date. Use this page to review and prioritize findings and track the progress of your security efforts. To access the findings page, access the overview page and click the Findings tab. When viewing the findings, you can update the filtering criteria by clicking the Severity , Status , Repository , Security category , or Scan type drop-downs above the list. The Details column offers a quick overview of each finding in the list, including its title, source platform , scan type , security category , and related information such as the repository name, Jira issue key, or penetration testing report URL. To find out more, click this overview to navigate to the finding details on the source platform. Sharing a filtered view of findings # To share the current view of the overview or findings page, click the Copy URL button in the top right-hand corner of the page. This action copies the URL with the current filters applied to the clipboard. Exporting findings # This feature is available only to organization admins and organization managers To export a list of findings as a CSV file, click the options menu in the top right-hand corner of the page and select Export findings (.csv) . The exported list always includes all findings, ignoring any applied filters. Reviewing severity rules and integration settings # To review the severity assignment rules or manage the integration with Jira or Slack , click the options menu in the top right-hand corner of the page and select respectively See severity rules or View integrations . How Codacy manages findings # Important To open and close findings, Codacy must detect when the associated issues are introduced and fixed. The detection logic is platform-dependent and is described below. Codacy opens a new finding whenever a source platform detects a new security issue. The new finding is automatically assigned a severity and a status: The priority of the issue on the source platform sets the severity of the finding . In turn, the severity of the finding defines a deadline to close the finding. The time to the deadline sets the status of the finding . The finding then moves through different statuses as the deadline is approached, met, or missed. Codacy closes a finding when the source platform stops detecting the associated security issue. The following section details when Codacy opens and closes findings for each supported platform. How Codacy manages findings detected on Git repositories # Note To make sure that Codacy detects security issues correctly: Enable code patterns belonging to the Security category. These patterns are enabled by default, but may not be on custom configurations. Alternatively, apply a coding standard that includes patterns belonging to the Security category. Confirm that the latest commits to the default branches of your repositories are analyzed. Codacy opens a new finding when it detects a new security issue on the default branch of a repository. Codacy closes a finding in either of the following cases: Codacy detects that the associated issue isn't present in the most recent analyzed commit and therefore is fixed You ignore the associated issue You disable the tool that found the associated issue Important Deleting a repository deletes all open findings belonging to that repository. How Codacy manages findings detected on Jira # Note For Codacy to detect Jira issues, you must integrate Jira with Security and risk management . Codacy retrieves updates from Jira once a day. If an issue is opened and closed on the same day, Codacy may not detect it. To make sure that Codacy detects Jira issues correctly, assign the security label when creating the issue or immediately after. Codacy opens a new finding when it detects a new Jira issue with a security label (case-insensitive). Codacy closes a finding when it detects that the associated Jira issue is marked as Closed. How Codacy manages findings detected during penetration testing # Note Penetration testing is available upon request and is provided by a third-party partner. See how to request penetration testing for your organization . Codacy opens a finding for each security issue detected during a penetration test. Codacy closes a finding when a subsequent penetration test doesn't detect the underlying security issue. How Codacy manages findings detected during application scanning (DAST) # Note To view application scanning findings, also known as DAST (Dynamic Application Security Testing) findings, you must first generate a DAST report and upload it to Codacy . Codacy opens a finding for each security issue detected in the DAST report. If subsequent reports identify the same issue, Codacy updates the existing finding. Codacy closes a finding when it's not detected in a subsequent DAST report. If a previously closed issue reappears in a later report, Codacy reopens the finding. Finding severities and deadlines # Note Currently, Codacy doesn't support customizing the severity rules for security findings. The following table defines finding severities and the number of days to the deadline to fix the associated security issue, based on the importance of the underlying issue: Finding severity Days to deadline Underlying Codacy issue severity Underlying Jira issue priority 1 Critical 30 Critical Highest High 60 - High Medium 90 Medium Medium Low 120 Minor Low and other/custom 1 Those listed are the default Jira priority names. If you rename a default Jira priority, it keeps the correct mapping. Finding statuses # The following table describes how finding statuses map to deadlines: Status category Finding status Deadline Open Overdue The deadline has been missed Due soon Fewer than 15 days to the deadline On track 15 days or more to the deadline Closed Closed late Closed after the deadline Closed on time Closed before the deadline Supported security categories # Note Due to a recent update, some issues may be temporarily assigned the Not yet categorized category. To categorize these issues, you can reanalyze the default branch of the relevant repository . For a list of repositories that have issues with this category, use the Security category filter on the Findings page. Each Codacy issue reported by Security and risk management belongs to one of the following security categories: Security category Description Android Android-specific security issues. Authentication Broken authentication and authorization attacks consist in gaining access to accounts that allow disclosing sensitive information or performing operations that could compromise the system. Command Injection Command injection attacks aim to execute arbitrary commands on the host operating system. Cookies Security issues related to insecure cookies. Cryptography Cryptography attacks exploit failures related to cryptography (or lack thereof), potentially leading to exposure of sensitive data. CSRF Cross-Site Request Forgery (CSRF) attacks force an end user to execute unwanted actions on a web application in which they're currently authenticated. Denial of Service Denial of Service (DoS) attacks make a resource (site, application, server) unavailable for legitimate users, typically by flooding the resource with requests or exploiting a vulnerability to trigger a crash. File Access File access security issues may allow an attacker to access arbitrary files and directories stored on the file system such as application source code, configuration, and critical system files. HTTP Headers Insecure HTTP headers are a common attack vector for malicious users. Input Validation Client input should always be validated to prevent malformed or malicious data from entering the workflow of an information system. Insecure Modules and Libraries Security issues related to modules or libraries that can potentially include vulnerabilities. Insecure Storage Security issues related to insecure storage of sensitive data. Malicious Code Security issues related to code patterns that are potentially unsafe. Mass Assignment Unprotected mass assignments are a Rails feature that could allow an attacker to update sensitive model attributes. Regex Regular expressions can be used in Denial of Service attacks, exploiting the fact that in most regular expression implementations the computational load grows exponentially with input size. Routes Badly configured routes can give unintended access to an attacker. SQL Injection SQL injection attacks insert or \"inject\" malicious SQL queries into the application via the client input data. SSL Security issues related with old SSL versions or configurations that have known cryptographic weaknesses and should no longer be used. Unexpected Behaviour Security issues related to potentially insecure system API calls. Visibility Logging should always be included for security events to better allow attack detection and help defend against vulnerabilities. XSS Cross-Site Scripting (XSS) attacks inject malicious client-side scripts into trusted websites that are visited by the end users. Other Other language-specific security issues. Scan types # Security and risk management classifies each finding with a Scan type , indicating the specific source or method used to detect the finding. This information helps you understand the origin of the finding and the context in which the underlying issue was detected. The following table lists the available scan types and their descriptions: Scan type Description Code Scanning Analysis of source code for vulnerabilities without execution. Also known as Static Application Security Testing ( SAST ). Software Composition Analysis Analysis of external libraries and packages for vulnerabilities or outdated versions. Exposed Secrets Detection of sensitive information, such as passwords or API keys, inadvertently included in the code. Infrastructure as Code Detection of configuration issues within infrastructure-as-code (IaC) files that could pose risks. Penetration Testing Results from penetration testing to find security vulnerabilities in running code. App Scanning Simulated attacks on live applications to find vulnerabilities. Also known as Dynamic Application Security Testing ( DAST ). Languages checked for security issues # Security and risk management supports checking the languages and infrastructure-as-code platforms below for any Codacy security issues reported by the corresponding tools: Language Tools that report security issues Apex PMD , Semgrep 1 AWS CloudFormation Checkov , Trivy 2 C Clang-Tidy 3 , Cppcheck , Flawfinder , Semgrep 1 , Trivy C# SonarC# , Semgrep 1 , Trivy C++ Clang-Tidy 3 , Cppcheck , Flawfinder , Semgrep 1 , Trivy Dart Trivy Dockerfile Hadolint , Semgrep 1 , Trivy Elixir Credo , Trivy GitHub Actions Semgrep 1 Go Gosec 3 , Semgrep 1 , Trivy Groovy CodeNarc Helm Trivy 2 Java Semgrep 1 , SpotBugs 3 4 , Trivy JavaScript ESLint 5 , Semgrep 1 , Trivy JSON Trivy Kotlin Semgrep 1 Kubernetes Trivy 2 Objective-C Clang-Tidy 3 PHP PHP_CodeSniffer , PHP Mess Detector , Semgrep 1 , Trivy PowerShell PSScriptAnalyser Python Bandit , Prospector , Pylint , Semgrep 1 , Trivy Ruby Brakeman , RuboCop , Semgrep 1 , Trivy Rust Semgrep 1 , Trivy Scala Codacy Scalameta Pro , Semgrep 1 , SpotBugs 3 4 Swift Semgrep 1 Shell ShellCheck Semgrep 1 Terraform Semgrep 1 , Trivy Transact-SQL TSQLLint TypeScript ESLint 5 , Semgrep 1 , Trivy Visual Basic SonarVB 1 : Semgrep supports additional security rules when signing up for Semgrep Pro . 2 : Currently, Trivy only supports scanning YAML files on this platform. 3 : Supported as a client-side tool . 4 : Includes the plugin Find Security Bugs . 5 : Includes the plugins no-unsanitized , security , security-node , and xss .", "title": "Managing security and risk"}, {"location": "organizations/managing-security-and-risk/#managing-security-and-risk", "text": "The Security and risk management feature helps you quickly identify, track, and address security across your organization by automatically opening time-bound, prioritized findings whenever security problems are detected in your organization repositories, in your connected Jira instance , or as a result of penetration testing . Under Security and risk management, you can find the following pages to help you monitor the security of your repositories: Overview Findings In addition, on these pages, you can share filtered views of findings , export findings as a CSV file , and review severity rules and integration settings", "title": "Managing security and risk"}, {"location": "organizations/managing-security-and-risk/#dashboard", "text": "The Security and risk management overview page provides a high-level view of the security posture of your organization, including the number of open findings, the distribution of open findings by severity, the history of finding resolution, and a breakdown of the most high-risk repositories and most detected security categories. Use this page to assess your organization's security posture and its progress over time, identify areas for improvement, and share findings with stakeholders. To access the overview page, select an organization from the top navigation bar and select Security and risk on the left navigation sidebar. The overview page includes six panels: Open findings overview Open findings distribution Open findings history Activity history Top 10 high-risk repositories Top 10 common security categories To limit the information displayed in each panel to a specific set of repositories, use the filter drop-down above the main area.", "title": "Overview"}, {"location": "organizations/managing-security-and-risk/#item-list", "text": "The Security and risk management findings page displays a filtered list of findings. By default, this list is sorted by status, and you can click the First detected column name to sort the findings by the detection date. Use this page to review and prioritize findings and track the progress of your security efforts. To access the findings page, access the overview page and click the Findings tab. When viewing the findings, you can update the filtering criteria by clicking the Severity , Status , Repository , Security category , or Scan type drop-downs above the list. The Details column offers a quick overview of each finding in the list, including its title, source platform , scan type , security category , and related information such as the repository name, Jira issue key, or penetration testing report URL. To find out more, click this overview to navigate to the finding details on the source platform.", "title": "Findings"}, {"location": "organizations/managing-security-and-risk/#sharing-filtered-view", "text": "To share the current view of the overview or findings page, click the Copy URL button in the top right-hand corner of the page. This action copies the URL with the current filters applied to the clipboard.", "title": "Sharing a filtered view of findings"}, {"location": "organizations/managing-security-and-risk/#exporting-the-security-item-list", "text": "This feature is available only to organization admins and organization managers To export a list of findings as a CSV file, click the options menu in the top right-hand corner of the page and select Export findings (.csv) . The exported list always includes all findings, ignoring any applied filters.", "title": "Exporting findings"}, {"location": "organizations/managing-security-and-risk/#reviewing-settings", "text": "To review the severity assignment rules or manage the integration with Jira or Slack , click the options menu in the top right-hand corner of the page and select respectively See severity rules or View integrations .", "title": "Reviewing severity rules and integration settings"}, {"location": "organizations/managing-security-and-risk/#opening-and-closing-items", "text": "Important To open and close findings, Codacy must detect when the associated issues are introduced and fixed. The detection logic is platform-dependent and is described below. Codacy opens a new finding whenever a source platform detects a new security issue. The new finding is automatically assigned a severity and a status: The priority of the issue on the source platform sets the severity of the finding . In turn, the severity of the finding defines a deadline to close the finding. The time to the deadline sets the status of the finding . The finding then moves through different statuses as the deadline is approached, met, or missed. Codacy closes a finding when the source platform stops detecting the associated security issue. The following section details when Codacy opens and closes findings for each supported platform.", "title": "How Codacy manages findings"}, {"location": "organizations/managing-security-and-risk/#item-severities-and-deadlines", "text": "Note Currently, Codacy doesn't support customizing the severity rules for security findings. The following table defines finding severities and the number of days to the deadline to fix the associated security issue, based on the importance of the underlying issue: Finding severity Days to deadline Underlying Codacy issue severity Underlying Jira issue priority 1 Critical 30 Critical Highest High 60 - High Medium 90 Medium Medium Low 120 Minor Low and other/custom 1 Those listed are the default Jira priority names. If you rename a default Jira priority, it keeps the correct mapping.", "title": "Finding severities and deadlines"}, {"location": "organizations/managing-security-and-risk/#item-statuses", "text": "The following table describes how finding statuses map to deadlines: Status category Finding status Deadline Open Overdue The deadline has been missed Due soon Fewer than 15 days to the deadline On track 15 days or more to the deadline Closed Closed late Closed after the deadline Closed on time Closed before the deadline", "title": "Finding statuses"}, {"location": "organizations/managing-security-and-risk/#supported-security-categories", "text": "Note Due to a recent update, some issues may be temporarily assigned the Not yet categorized category. To categorize these issues, you can reanalyze the default branch of the relevant repository . For a list of repositories that have issues with this category, use the Security category filter on the Findings page. Each Codacy issue reported by Security and risk management belongs to one of the following security categories: Security category Description Android Android-specific security issues. Authentication Broken authentication and authorization attacks consist in gaining access to accounts that allow disclosing sensitive information or performing operations that could compromise the system. Command Injection Command injection attacks aim to execute arbitrary commands on the host operating system. Cookies Security issues related to insecure cookies. Cryptography Cryptography attacks exploit failures related to cryptography (or lack thereof), potentially leading to exposure of sensitive data. CSRF Cross-Site Request Forgery (CSRF) attacks force an end user to execute unwanted actions on a web application in which they're currently authenticated. Denial of Service Denial of Service (DoS) attacks make a resource (site, application, server) unavailable for legitimate users, typically by flooding the resource with requests or exploiting a vulnerability to trigger a crash. File Access File access security issues may allow an attacker to access arbitrary files and directories stored on the file system such as application source code, configuration, and critical system files. HTTP Headers Insecure HTTP headers are a common attack vector for malicious users. Input Validation Client input should always be validated to prevent malformed or malicious data from entering the workflow of an information system. Insecure Modules and Libraries Security issues related to modules or libraries that can potentially include vulnerabilities. Insecure Storage Security issues related to insecure storage of sensitive data. Malicious Code Security issues related to code patterns that are potentially unsafe. Mass Assignment Unprotected mass assignments are a Rails feature that could allow an attacker to update sensitive model attributes. Regex Regular expressions can be used in Denial of Service attacks, exploiting the fact that in most regular expression implementations the computational load grows exponentially with input size. Routes Badly configured routes can give unintended access to an attacker. SQL Injection SQL injection attacks insert or \"inject\" malicious SQL queries into the application via the client input data. SSL Security issues related with old SSL versions or configurations that have known cryptographic weaknesses and should no longer be used. Unexpected Behaviour Security issues related to potentially insecure system API calls. Visibility Logging should always be included for security events to better allow attack detection and help defend against vulnerabilities. XSS Cross-Site Scripting (XSS) attacks inject malicious client-side scripts into trusted websites that are visited by the end users. Other Other language-specific security issues.", "title": "Supported security categories"}, {"location": "organizations/managing-security-and-risk/#scan-types", "text": "Security and risk management classifies each finding with a Scan type , indicating the specific source or method used to detect the finding. This information helps you understand the origin of the finding and the context in which the underlying issue was detected. The following table lists the available scan types and their descriptions: Scan type Description Code Scanning Analysis of source code for vulnerabilities without execution. Also known as Static Application Security Testing ( SAST ). Software Composition Analysis Analysis of external libraries and packages for vulnerabilities or outdated versions. Exposed Secrets Detection of sensitive information, such as passwords or API keys, inadvertently included in the code. Infrastructure as Code Detection of configuration issues within infrastructure-as-code (IaC) files that could pose risks. Penetration Testing Results from penetration testing to find security vulnerabilities in running code. App Scanning Simulated attacks on live applications to find vulnerabilities. Also known as Dynamic Application Security Testing ( DAST ).", "title": "Scan types"}, {"location": "organizations/managing-security-and-risk/#languages-checked-for-security-issues", "text": "Security and risk management supports checking the languages and infrastructure-as-code platforms below for any Codacy security issues reported by the corresponding tools: Language Tools that report security issues Apex PMD , Semgrep 1 AWS CloudFormation Checkov , Trivy 2 C Clang-Tidy 3 , Cppcheck , Flawfinder , Semgrep 1 , Trivy C# SonarC# , Semgrep 1 , Trivy C++ Clang-Tidy 3 , Cppcheck , Flawfinder , Semgrep 1 , Trivy Dart Trivy Dockerfile Hadolint , Semgrep 1 , Trivy Elixir Credo , Trivy GitHub Actions Semgrep 1 Go Gosec 3 , Semgrep 1 , Trivy Groovy CodeNarc Helm Trivy 2 Java Semgrep 1 , SpotBugs 3 4 , Trivy JavaScript ESLint 5 , Semgrep 1 , Trivy JSON Trivy Kotlin Semgrep 1 Kubernetes Trivy 2 Objective-C Clang-Tidy 3 PHP PHP_CodeSniffer , PHP Mess Detector , Semgrep 1 , Trivy PowerShell PSScriptAnalyser Python Bandit , Prospector , Pylint , Semgrep 1 , Trivy Ruby Brakeman , RuboCop , Semgrep 1 , Trivy Rust Semgrep 1 , Trivy Scala Codacy Scalameta Pro , Semgrep 1 , SpotBugs 3 4 Swift Semgrep 1 Shell ShellCheck Semgrep 1 Terraform Semgrep 1 , Trivy Transact-SQL TSQLLint TypeScript ESLint 5 , Semgrep 1 , Trivy Visual Basic SonarVB 1 : Semgrep supports additional security rules when signing up for Semgrep Pro . 2 : Currently, Trivy only supports scanning YAML files on this platform. 3 : Supported as a client-side tool . 4 : Includes the plugin Find Security Bugs . 5 : Includes the plugins no-unsanitized , security , security-node , and xss .", "title": "Languages checked for security issues"}, {"location": "organizations/organization-overview/", "text": "Organization overview # The Organization overview provides an overview of the repositories belonging to your Git provider organization that you follow on Codacy . Here you can compare their statuses and check for items that require your attention. To access your Organization overview, select an organization from the top navigation bar and select Overview on the left navigation sidebar. Important The Organization overview calculates metrics and displays data only for the repositories that you follow on Codacy. This means that depending on their list of followed repositories, two users can see different results on their Organization overview. The Organization overview displays information for at most the last 100 updated repositories . Use the drop-down list at the top of the page to filter the information displayed on all dashboard areas based on the repositories that you select. For example, you can use the filter to monitor the quality of the repositories maintained by specific teams or that include certain programming languages, or to ignore legacy repositories that are no longer maintained. The selected repositories are stored in your browser so that the same filter is applied between your visits to the Organization overview page. You can use the language filter to help you narrow down the list of repositories in the drop-down list: On the Organization overview you have the following areas to help you monitor your repositories: Overall quality chart Open pull requests Last updated repositories On this page, you can also see the Organization setup area, which provides you with a checklist of items that you should complete to ensure that your organization is set up correctly and that you're getting the most out of Codacy. The following sections provide a detailed description of the repository-related dashboard areas. Note You can use the Codacy API to generate reports or obtain information about the code quality of your repositories in a more flexible way. For more information see the list of available API endpoints and the following examples: Obtaining current issues in repositories Obtaining code quality metrics for files Overall quality chart # The Overall quality chart compares the repositories that you follow regarding grade , issues , complex files , duplication , and code coverage . Each tab displays the average value for the corresponding metric across your repositories. Hover the mouse pointer over the bars to see the metrics for the corresponding repositories. Click the bars to navigate directly to the corresponding repository. If you have over 8 repositories, the chart displays your repositories grouped by grade or percentage intervals. Click the bars to see and navigate directly to the corresponding repositories. Tip If you don't have coverage set up for any of your repositories yet, the coverage tab provides you with instructions on how to add coverage for your repositories . Open pull requests # The Most problematic tab displays a short list of the open pull requests that aren't up to standards and have the most potential to negatively affect your code quality. The Last updated tab displays open pull requests sorted by the date of update with one of the following status: Not up to standards Up to standards Analysis failed (something went wrong during the analysis) Analyzing (intermediate status while Codacy is analyzing the pull request) Click a pull request to see the details of that pull request . Last updated repositories # The Last updated repositories list displays the last updated repositories, sorted by reverse date of the last update. Each item displays the date of the last update and the current grade of the repository. Click See all to see all the repositories that you follow on Codacy. Note The exact value of the last updated date of the repositories depends on your Git provider: GitHub: date of the last commit to any branch of the repository (value of pushed_at from the GitHub Repositories API ). GitLab: date when the project was last updated (value of last_activity_at from the GitLab Groups API ). Note that this value is only updated at most once per hour ). Bitbucket: date when the repository was last updated (value of updated_on from the Bitbucket Repositories API ). On Bitbucket Server Codacy can't obtain this information and the list displays the repositories in alphabetical order. See also # Which metrics does Codacy calculate? Using the Codacy API to obtain current issues in repositories Using the Codacy API to obtain code quality metrics for files", "title": "Organization overview"}, {"location": "organizations/organization-overview/#organization-overview", "text": "The Organization overview provides an overview of the repositories belonging to your Git provider organization that you follow on Codacy . Here you can compare their statuses and check for items that require your attention. To access your Organization overview, select an organization from the top navigation bar and select Overview on the left navigation sidebar. Important The Organization overview calculates metrics and displays data only for the repositories that you follow on Codacy. This means that depending on their list of followed repositories, two users can see different results on their Organization overview. The Organization overview displays information for at most the last 100 updated repositories . Use the drop-down list at the top of the page to filter the information displayed on all dashboard areas based on the repositories that you select. For example, you can use the filter to monitor the quality of the repositories maintained by specific teams or that include certain programming languages, or to ignore legacy repositories that are no longer maintained. The selected repositories are stored in your browser so that the same filter is applied between your visits to the Organization overview page. You can use the language filter to help you narrow down the list of repositories in the drop-down list: On the Organization overview you have the following areas to help you monitor your repositories: Overall quality chart Open pull requests Last updated repositories On this page, you can also see the Organization setup area, which provides you with a checklist of items that you should complete to ensure that your organization is set up correctly and that you're getting the most out of Codacy. The following sections provide a detailed description of the repository-related dashboard areas. Note You can use the Codacy API to generate reports or obtain information about the code quality of your repositories in a more flexible way. For more information see the list of available API endpoints and the following examples: Obtaining current issues in repositories Obtaining code quality metrics for files", "title": "Organization overview"}, {"location": "organizations/organization-overview/#overall-quality-chart", "text": "The Overall quality chart compares the repositories that you follow regarding grade , issues , complex files , duplication , and code coverage . Each tab displays the average value for the corresponding metric across your repositories. Hover the mouse pointer over the bars to see the metrics for the corresponding repositories. Click the bars to navigate directly to the corresponding repository. If you have over 8 repositories, the chart displays your repositories grouped by grade or percentage intervals. Click the bars to see and navigate directly to the corresponding repositories. Tip If you don't have coverage set up for any of your repositories yet, the coverage tab provides you with instructions on how to add coverage for your repositories .", "title": "Overall quality chart"}, {"location": "organizations/organization-overview/#open-pull-requests", "text": "The Most problematic tab displays a short list of the open pull requests that aren't up to standards and have the most potential to negatively affect your code quality. The Last updated tab displays open pull requests sorted by the date of update with one of the following status: Not up to standards Up to standards Analysis failed (something went wrong during the analysis) Analyzing (intermediate status while Codacy is analyzing the pull request) Click a pull request to see the details of that pull request .", "title": "Open pull requests"}, {"location": "organizations/organization-overview/#last-updated-repositories", "text": "The Last updated repositories list displays the last updated repositories, sorted by reverse date of the last update. Each item displays the date of the last update and the current grade of the repository. Click See all to see all the repositories that you follow on Codacy. Note The exact value of the last updated date of the repositories depends on your Git provider: GitHub: date of the last commit to any branch of the repository (value of pushed_at from the GitHub Repositories API ). GitLab: date when the project was last updated (value of last_activity_at from the GitLab Groups API ). Note that this value is only updated at most once per hour ). Bitbucket: date when the repository was last updated (value of updated_on from the Bitbucket Repositories API ). On Bitbucket Server Codacy can't obtain this information and the list displays the repositories in alphabetical order.", "title": "Last updated repositories"}, {"location": "organizations/organization-overview/#see-also", "text": "Which metrics does Codacy calculate? Using the Codacy API to obtain current issues in repositories Using the Codacy API to obtain code quality metrics for files", "title": "See also"}, {"location": "organizations/roles-and-permissions-for-organizations/", "text": "Roles and permissions for organizations # By default, Codacy assigns each organization member a role corresponding to that member's role on your Git provider. Each Codacy role, from most restrictive (repository read) to most capable (organization admin), corresponds to a set of permissions that determine what each member can do on Codacy. To update a member's role on Codacy, update that member's role on your Git provider. When next logging in to Codacy, the member is assigned the new role. Organization admins can also grant additional permissions: To roles, by configuring repository management permissions To individual members, by assigning the organization manager role To review the permissions granted by each role, see the tables for each Git provider: Permissions for GitHub Permissions for GitLab Permissions for Bitbucket To list and manage the members of your Codacy organization, see the Managing people page. Configuring repository management permissions # Only organization admins can update this setting By default, only users with the Codacy role repository write can change analysis configurations. To change this, open your organization Settings , page Roles and permissions , and choose the Codacy roles that can perform the following operations on the repositories of your organization: Ignore issues Ignore files Configure code patterns Configure languages Manage branches Reanalyze branches and pull requests Managing the organization manager role # Only organization admins can update this setting To grant an organization member additional permissions, you can assign that member the organization manager role. This role isn't influenced by a member's Git provider role. To review the additional permissions granted by the organization manager role, see the tables for each Git provider ( GitHub , GitLab , Bitbucket ). Note Organization managers can access the Policies and Integrations settings sections of your organization and can therefore impact some repository settings for all repositories of your organization, even repositories that they can't access on the Git provider. However, they can't access the repositories themselves and can only see the repository names. Assigning the organization manager role # To assign the organization manager role: Open your organization Settings , page Roles and permissions . In the Organization managers area, use the search field to find the relevant organization member and click the member's name. Note You can only assign the organization manager role to members of your organization . Revoking the organization manager role # To revoke the organization manager role: Open your organization Settings , page Roles and permissions . In the Organization managers area, scroll the list to find the relevant user. Click the Revoke role icon to the right of the user's name and confirm. Permissions for GitHub # The table below maps the GitHub Cloud and GitHub Enterprise roles to the corresponding Codacy roles and the operations that they're allowed to perform: GitHub role Outside collaborator 1 Repository read Repository triage Repository write Repository maintain Repository admin - Organization Owner Codacy role - Repository read Repository write Repository admin Organization manager Organization admin Join organization No Yes 2 Yes 2 Yes 2 Yes Yes 2 View and follow private repository No Yes Yes Yes Yes Yes Access Security and risk management No Yes 3 Yes 3 Yes 3 Yes Yes Ignore issues and files, configure code patterns and languages, manage branches, reanalyze branches and pull requests No Configurable Configurable Yes Inherits original permission Yes Upload coverage using an account API token, see the coverage report logs No No Yes Yes Inherits original permission Yes Configure repository Git provider integration settings No No No Yes Inherits original permission Yes Configure repository quality gates and goals No No No Yes Inherits original permission Yes Enable repository analysis to run on a local build server, manage repository API tokens No No No Yes Inherits original permission Yes Add and remove repository No No No Yes 4 Inherits original permission Yes Manage organization gate policies and coding standards No No No No Yes Yes Configure organization default settings for Git provider integration No No No No Yes Yes Obtain audit logs for organization events 5 No No No No Yes Yes Invite and accept members, modify billing No No No No No Yes Assign and revoke the organization manager role No No No No No Yes 1 : Outside collaborators aren't supported as members of organizations on Codacy. You can still add outside collaborators to Codacy so that Codacy analyzes their commits to private repositories, but they won't be able to join your Codacy organization. 2 : Joining an organization may need an approval depending on your setting for accepting new people . 3 : These users can only see security items originating from Codacy repositories that they follow. 4 : Requires that an organization owner has given the Codacy GitHub App access to the repositories to add or remove. 5 : Audit logs are available only on Business plan . Permissions for GitLab # The table below maps the GitLab Cloud and GitLab Enterprise roles to the corresponding Codacy roles and the operations that they're allowed to perform: GitLab role External user 1 Project guest Project reporter Project developer Project maintainer Project owner - Group owner Administrator Codacy role - Repository read Repository write Repository admin Organization manager Organization admin Join organization No Yes 2 Yes 2 Yes 2 Yes Yes 2 View and follow private repository No Yes Yes Yes Yes Yes Access Security and risk management No Yes 3 Yes 3 Yes 3 Yes Yes Ignore issues and files, configure code patterns and languages, manage branches, reanalyze branches and pull requests No Configurable Configurable Yes Inherits original permission Yes Upload coverage using an account API token, see the coverage report logs No No Yes Yes Inherits original permission Yes Configure repository Git provider integration settings No No No Yes Inherits original permission Yes Configure repository quality gates and goals No No No Yes Inherits original permission Yes Configure repository to run analysis on local build server, manage repository API tokens No No No Yes Inherits original permission Yes Add and remove repository No No No Yes Inherits original permission Yes Manage organization gate policies and coding standards No No No No Yes Yes Configure organization default settings for Git provider integration No No No No Yes Yes Obtain audit logs for organization events 4 No No No No Yes Yes Invite and accept members, modify billing No No No No No Yes Assign and revoke the organization manager role No No No No No Yes 1 : External users aren't supported as members of organizations on Codacy. You can still add external users to Codacy so that Codacy analyzes their commits to private repositories, but they won't be able to join your Codacy organization. 2 : Joining an organization may need an approval depending on your setting for accepting new people . 3 : These users can only see security items originating from Codacy repositories that they follow. 4 : Audit logs are available only on Business plan . Permissions for Bitbucket # The table below maps the Bitbucket Cloud and Bitbucket Server roles to the corresponding Codacy roles and the operations that they're allowed to perform: Bitbucket role Read Write 1 - Admin Codacy role Repository read Organization manager Organization admin Join organization Yes 2 Yes Yes 2 View and follow private repository Yes Yes Yes Access Security and risk management Yes 3 Yes Yes Ignore issues and files, configure code patterns and languages, manage branches, reanalyze branches and pull requests Configurable Inherits original permission Yes Upload coverage using an account API token, see the coverage report logs No Inherits original permission Yes Configure repository Git provider integration settings No Inherits original permission Yes Configure repository quality gates and goals No Inherits original permission Yes Configure repository to run analysis on local build server, manage repository API tokens No Inherits original permission Yes Add and remove repository No Inherits original permission Yes Manage organization gate policies and coding standards No Yes Yes Configure organization default settings for Git provider integration No Yes Yes Obtain audit logs for organization events 4 No Yes Yes Invite and accept members, modify billing No No Yes Assign and revoke the organization manager role No No Yes 1 : Codacy can't distinguish the Bitbucket roles Read and Write because of a limitation on the Bitbucket API. 2 : Joining an organization may need an approval depending on your setting for accepting new people . 3 : These users can only see security items originating from Codacy repositories that they follow. 4 : Audit logs are available only on Business plan . See also # Managing people Accepting new people to your organization /*Center text in all cells except the first column*/ td:not(:first-child), th:not(:first-child) { text-align: center !important; } /*Background color for row containing the Codacy permission levels*/ table:not(data-exclude) tr:nth-child(1) td { background-color: #EBF1FF; } /*Add vertical borders and disable horizontal borders*/ td { border-left: 1px solid var(--md-default-fg-color--lightest); border-top: 1px solid var(--md-default-fg-color--lightest); } td:nth-child(1) { border-left: 0; } /*Background for cells marking various operations*/ .yes { background-color: #E6F4EA; } .no { background-color: #FFF1EB; } .maybe { background-color: #F2F9FC; }", "title": "Roles and permissions for organizations"}, {"location": "organizations/roles-and-permissions-for-organizations/#roles-and-permissions-for-organizations", "text": "By default, Codacy assigns each organization member a role corresponding to that member's role on your Git provider. Each Codacy role, from most restrictive (repository read) to most capable (organization admin), corresponds to a set of permissions that determine what each member can do on Codacy. To update a member's role on Codacy, update that member's role on your Git provider. When next logging in to Codacy, the member is assigned the new role. Organization admins can also grant additional permissions: To roles, by configuring repository management permissions To individual members, by assigning the organization manager role To review the permissions granted by each role, see the tables for each Git provider: Permissions for GitHub Permissions for GitLab Permissions for Bitbucket To list and manage the members of your Codacy organization, see the Managing people page.", "title": "Roles and permissions for organizations"}, {"location": "organizations/roles-and-permissions-for-organizations/#change-analysis-configuration", "text": "Only organization admins can update this setting By default, only users with the Codacy role repository write can change analysis configurations. To change this, open your organization Settings , page Roles and permissions , and choose the Codacy roles that can perform the following operations on the repositories of your organization: Ignore issues Ignore files Configure code patterns Configure languages Manage branches Reanalyze branches and pull requests", "title": "Configuring repository management permissions"}, {"location": "organizations/roles-and-permissions-for-organizations/#managing-the-organization-manager-role", "text": "Only organization admins can update this setting To grant an organization member additional permissions, you can assign that member the organization manager role. This role isn't influenced by a member's Git provider role. To review the additional permissions granted by the organization manager role, see the tables for each Git provider ( GitHub , GitLab , Bitbucket ). Note Organization managers can access the Policies and Integrations settings sections of your organization and can therefore impact some repository settings for all repositories of your organization, even repositories that they can't access on the Git provider. However, they can't access the repositories themselves and can only see the repository names.", "title": "Managing the organization manager role"}, {"location": "organizations/roles-and-permissions-for-organizations/#permissions-for-github", "text": "The table below maps the GitHub Cloud and GitHub Enterprise roles to the corresponding Codacy roles and the operations that they're allowed to perform: GitHub role Outside collaborator 1 Repository read Repository triage Repository write Repository maintain Repository admin - Organization Owner Codacy role - Repository read Repository write Repository admin Organization manager Organization admin Join organization No Yes 2 Yes 2 Yes 2 Yes Yes 2 View and follow private repository No Yes Yes Yes Yes Yes Access Security and risk management No Yes 3 Yes 3 Yes 3 Yes Yes Ignore issues and files, configure code patterns and languages, manage branches, reanalyze branches and pull requests No Configurable Configurable Yes Inherits original permission Yes Upload coverage using an account API token, see the coverage report logs No No Yes Yes Inherits original permission Yes Configure repository Git provider integration settings No No No Yes Inherits original permission Yes Configure repository quality gates and goals No No No Yes Inherits original permission Yes Enable repository analysis to run on a local build server, manage repository API tokens No No No Yes Inherits original permission Yes Add and remove repository No No No Yes 4 Inherits original permission Yes Manage organization gate policies and coding standards No No No No Yes Yes Configure organization default settings for Git provider integration No No No No Yes Yes Obtain audit logs for organization events 5 No No No No Yes Yes Invite and accept members, modify billing No No No No No Yes Assign and revoke the organization manager role No No No No No Yes 1 : Outside collaborators aren't supported as members of organizations on Codacy. You can still add outside collaborators to Codacy so that Codacy analyzes their commits to private repositories, but they won't be able to join your Codacy organization. 2 : Joining an organization may need an approval depending on your setting for accepting new people . 3 : These users can only see security items originating from Codacy repositories that they follow. 4 : Requires that an organization owner has given the Codacy GitHub App access to the repositories to add or remove. 5 : Audit logs are available only on Business plan .", "title": "Permissions for GitHub"}, {"location": "organizations/roles-and-permissions-for-organizations/#permissions-for-gitlab", "text": "The table below maps the GitLab Cloud and GitLab Enterprise roles to the corresponding Codacy roles and the operations that they're allowed to perform: GitLab role External user 1 Project guest Project reporter Project developer Project maintainer Project owner - Group owner Administrator Codacy role - Repository read Repository write Repository admin Organization manager Organization admin Join organization No Yes 2 Yes 2 Yes 2 Yes Yes 2 View and follow private repository No Yes Yes Yes Yes Yes Access Security and risk management No Yes 3 Yes 3 Yes 3 Yes Yes Ignore issues and files, configure code patterns and languages, manage branches, reanalyze branches and pull requests No Configurable Configurable Yes Inherits original permission Yes Upload coverage using an account API token, see the coverage report logs No No Yes Yes Inherits original permission Yes Configure repository Git provider integration settings No No No Yes Inherits original permission Yes Configure repository quality gates and goals No No No Yes Inherits original permission Yes Configure repository to run analysis on local build server, manage repository API tokens No No No Yes Inherits original permission Yes Add and remove repository No No No Yes Inherits original permission Yes Manage organization gate policies and coding standards No No No No Yes Yes Configure organization default settings for Git provider integration No No No No Yes Yes Obtain audit logs for organization events 4 No No No No Yes Yes Invite and accept members, modify billing No No No No No Yes Assign and revoke the organization manager role No No No No No Yes 1 : External users aren't supported as members of organizations on Codacy. You can still add external users to Codacy so that Codacy analyzes their commits to private repositories, but they won't be able to join your Codacy organization. 2 : Joining an organization may need an approval depending on your setting for accepting new people . 3 : These users can only see security items originating from Codacy repositories that they follow. 4 : Audit logs are available only on Business plan .", "title": "Permissions for GitLab"}, {"location": "organizations/roles-and-permissions-for-organizations/#permissions-for-bitbucket", "text": "The table below maps the Bitbucket Cloud and Bitbucket Server roles to the corresponding Codacy roles and the operations that they're allowed to perform: Bitbucket role Read Write 1 - Admin Codacy role Repository read Organization manager Organization admin Join organization Yes 2 Yes Yes 2 View and follow private repository Yes Yes Yes Access Security and risk management Yes 3 Yes Yes Ignore issues and files, configure code patterns and languages, manage branches, reanalyze branches and pull requests Configurable Inherits original permission Yes Upload coverage using an account API token, see the coverage report logs No Inherits original permission Yes Configure repository Git provider integration settings No Inherits original permission Yes Configure repository quality gates and goals No Inherits original permission Yes Configure repository to run analysis on local build server, manage repository API tokens No Inherits original permission Yes Add and remove repository No Inherits original permission Yes Manage organization gate policies and coding standards No Yes Yes Configure organization default settings for Git provider integration No Yes Yes Obtain audit logs for organization events 4 No Yes Yes Invite and accept members, modify billing No No Yes Assign and revoke the organization manager role No No Yes 1 : Codacy can't distinguish the Bitbucket roles Read and Write because of a limitation on the Bitbucket API. 2 : Joining an organization may need an approval depending on your setting for accepting new people . 3 : These users can only see security items originating from Codacy repositories that they follow. 4 : Audit logs are available only on Business plan .", "title": "Permissions for Bitbucket"}, {"location": "organizations/roles-and-permissions-for-organizations/#see-also", "text": "Managing people Accepting new people to your organization /*Center text in all cells except the first column*/ td:not(:first-child), th:not(:first-child) { text-align: center !important; } /*Background color for row containing the Codacy permission levels*/ table:not(data-exclude) tr:nth-child(1) td { background-color: #EBF1FF; } /*Add vertical borders and disable horizontal borders*/ td { border-left: 1px solid var(--md-default-fg-color--lightest); border-top: 1px solid var(--md-default-fg-color--lightest); } td:nth-child(1) { border-left: 0; } /*Background for cells marking various operations*/ .yes { background-color: #E6F4EA; } .no { background-color: #FFF1EB; } .maybe { background-color: #F2F9FC; }", "title": "See also"}, {"location": "organizations/using-coding-standards/", "text": "Using coding standards # Coding standards enable the analysis of multiple repositories with the same tool and code pattern configurations, ensuring consistent code quality across your organization. Multiple coding standards can be applied to the same repository. For example, you can use coding standards to ensure that a group of repositories follow the same security rules or coding conventions. This page covers the following topics: Creating a coding standard Configuring a coding standard (guided setup) Configuring a coding standard (advanced setup) Defining default coding standards Editing a coding standard Deleting a coding standard Using a coding standard alongside tool configuration files Using multiple coding standards Creating a coding standard # Note Codacy currently supports up to 10 coding standards per organization. To create a coding standard for your organization: Open your organization Policies page, tab Coding standards . Click the button Create new standard at the top right-hand corner of the page. This opens the coding standard creation form. Enter a unique name for the new coding standard. Optionally, check Apply to new repositories to set the new coding standard as one of your organization's default coding standards , so it applies automatically to new repositories. Choose whether to create the coding standard using a guided or advanced setup: The guided setup lets you choose preset sensitivity levels for each issue type, turning on relevant patterns in bulk. It's ideal for quickly setting up a coding standard with minimal effort. You can always fine-tune the coding standard by editing it later using the advanced setup. The advanced setup lets you choose individual languages and code patterns to activate. It's ideal for fine-tuning the coding standard to your organization's specific needs, offering more control over the tools and code patterns used. With the advanced setup, you can optionally select a repository as the baseline for the new coding standard. This is useful if you already have a well-configured repository that you wish to use as a template. Click Create coding standard to proceed to the guided setup or advanced setup , depending on your choice. Configuring a coding standard (guided setup) # If you selected Guided setup when creating a new coding standard , follow these steps: Adjust the sensitivity of the coding standard from Essential to Comprehensive for each issue category group: Essential : Focuses on the most important issues by including the most critical code patterns. Ideal for initial integration, to prevent overwhelming developers, and to speed up analysis times. Comprehensive : Detects all issues by including all code patterns, capturing the complete severity spectrum. Ideal for detailed code quality reviews, while reducing emphasis on critical issues. It may increase analysis times. Tip Initially, set the sensitivity to Essential for most category groups to focus on critical code patterns. It helps streamline the integration process with Codacy without overwhelming developers with too many reported issues. You can gradually include more patterns as needed. Click Next: Select and apply to repositories . Select existing repositories that should follow the new coding standard and click Save and apply coding standard . Codacy will start using the new coding standard on the next analysis of each selected repository. Configuring a coding standard (advanced setup) # If you selected Advanced setup when creating a new coding standard or are editing an existing coding standard, follow these steps: Select the programming languages that the new coding standard should include. Important The coding standard will only control tools that can analyze one or more of the languages selected in this step. If a language is omitted in this step, Codacy uses repository-level tool configurations if present or global Codacy defaults otherwise, and may analyze the omitted language. To prevent this: In this step select all languages, so that the coding standard controls all tools. In the next step, explicitly disable the tools that you don't want to use. Click Next: Tools and patterns . Configure the tools and patterns of the coding standard: Toggle the tools to run when Codacy analyzes your code. For each enabled tool, configure the code patterns to use. Tip Use the filters to find the relevant tools and code patterns. The recommended configurations are manually curated by Codacy or based on tool defaults and are marked with the icon . To toggle multiple code patterns at once, click the checkbox of the first pattern and Shift+click the checkbox of the last pattern in a range. To toggle all the code patterns visible on the list, click the checkbox on the header of the code patterns list. If there are more code patterns to load on the list, you can click the link Enable/Disable all patterns to toggle all patterns matching the current filters. Proceed with the remaining wizard steps to finish creating or editing your coding standard. Defining default coding standards # For ease of management, you can define multiple default coding standards that automatically apply to new repositories. In the absence of default coding standards, Codacy applies global defaults to all new repositories. Note When Codacy introduces new tools, those are automatically added to the global Codacy defaults but need to be manually added to a default coding standard. You can mark a new coding standard as default when creating one. To mark an existing coding standard as default: Open your organization Policies page, tab Coding standards . Toggle Apply to new repositoriet on the relevant coding standard card. Editing a coding standard # Note Any edits to the configurations of a coding standard are automatically applied on the next analysis of each associated repository. To edit an existing coding standard or change the repositories that follow that coding standard: Open your organization Policies page, tab Coding standards . Click the edit icon on the coding standard card. Edit the current coding standard configurations and click the button Next to advance to the following configuration pages : Note When editing an existing coding standard, the advanced setup is the default view. Select languages : the programming languages that the coding standard applies to. On this page, you can rename the coding standard by clicking the edit icon next to the name of the coding standard. Choose tools and patterns : the tool and code pattern configurations of the coding standard. Select and apply to repositories : the repositories that follow the coding standard. Click the button Save and apply coding standard on the repository selection page to save your changes to the coding standard. Codacy will start using the updated coding standard on the next analysis of each selected repository. Deleting a coding standard # To delete a coding standard: Open your organization Policies page, tab Coding standards . Click the trash can icon on the coding standard card and confirm. Using a coding standard alongside tool configuration files # When using a tool configuration file alongside a coding standard, the configuration file controls the code patterns, while the coding standard controls whether the tool is enabled or disabled. Using multiple coding standards # When Codacy analyzes your code using multiple coding standards, it merges the tools and patterns from each standard. Enabled tools and patterns in any applied standard will be enforced. Important If the same pattern appears in multiple standards, the version from the most recently applied standard (with its parameters) takes precedence. See also # Configuring code patterns on each repository How to implement Google JavaScript style guide with Codacy", "title": "Using coding standards"}, {"location": "organizations/using-coding-standards/#using-coding-standards", "text": "Coding standards enable the analysis of multiple repositories with the same tool and code pattern configurations, ensuring consistent code quality across your organization. Multiple coding standards can be applied to the same repository. For example, you can use coding standards to ensure that a group of repositories follow the same security rules or coding conventions. This page covers the following topics: Creating a coding standard Configuring a coding standard (guided setup) Configuring a coding standard (advanced setup) Defining default coding standards Editing a coding standard Deleting a coding standard Using a coding standard alongside tool configuration files Using multiple coding standards", "title": "Using coding standards"}, {"location": "organizations/using-coding-standards/#creating", "text": "Note Codacy currently supports up to 10 coding standards per organization. To create a coding standard for your organization: Open your organization Policies page, tab Coding standards . Click the button Create new standard at the top right-hand corner of the page. This opens the coding standard creation form. Enter a unique name for the new coding standard. Optionally, check Apply to new repositories to set the new coding standard as one of your organization's default coding standards , so it applies automatically to new repositories. Choose whether to create the coding standard using a guided or advanced setup: The guided setup lets you choose preset sensitivity levels for each issue type, turning on relevant patterns in bulk. It's ideal for quickly setting up a coding standard with minimal effort. You can always fine-tune the coding standard by editing it later using the advanced setup. The advanced setup lets you choose individual languages and code patterns to activate. It's ideal for fine-tuning the coding standard to your organization's specific needs, offering more control over the tools and code patterns used. With the advanced setup, you can optionally select a repository as the baseline for the new coding standard. This is useful if you already have a well-configured repository that you wish to use as a template. Click Create coding standard to proceed to the guided setup or advanced setup , depending on your choice.", "title": "Creating a coding standard"}, {"location": "organizations/using-coding-standards/#guided-setup", "text": "If you selected Guided setup when creating a new coding standard , follow these steps: Adjust the sensitivity of the coding standard from Essential to Comprehensive for each issue category group: Essential : Focuses on the most important issues by including the most critical code patterns. Ideal for initial integration, to prevent overwhelming developers, and to speed up analysis times. Comprehensive : Detects all issues by including all code patterns, capturing the complete severity spectrum. Ideal for detailed code quality reviews, while reducing emphasis on critical issues. It may increase analysis times. Tip Initially, set the sensitivity to Essential for most category groups to focus on critical code patterns. It helps streamline the integration process with Codacy without overwhelming developers with too many reported issues. You can gradually include more patterns as needed. Click Next: Select and apply to repositories . Select existing repositories that should follow the new coding standard and click Save and apply coding standard . Codacy will start using the new coding standard on the next analysis of each selected repository.", "title": "Configuring a coding standard (guided setup)"}, {"location": "organizations/using-coding-standards/#advanced-settings", "text": "If you selected Advanced setup when creating a new coding standard or are editing an existing coding standard, follow these steps: Select the programming languages that the new coding standard should include. Important The coding standard will only control tools that can analyze one or more of the languages selected in this step. If a language is omitted in this step, Codacy uses repository-level tool configurations if present or global Codacy defaults otherwise, and may analyze the omitted language. To prevent this: In this step select all languages, so that the coding standard controls all tools. In the next step, explicitly disable the tools that you don't want to use. Click Next: Tools and patterns . Configure the tools and patterns of the coding standard: Toggle the tools to run when Codacy analyzes your code. For each enabled tool, configure the code patterns to use. Tip Use the filters to find the relevant tools and code patterns. The recommended configurations are manually curated by Codacy or based on tool defaults and are marked with the icon . To toggle multiple code patterns at once, click the checkbox of the first pattern and Shift+click the checkbox of the last pattern in a range. To toggle all the code patterns visible on the list, click the checkbox on the header of the code patterns list. If there are more code patterns to load on the list, you can click the link Enable/Disable all patterns to toggle all patterns matching the current filters. Proceed with the remaining wizard steps to finish creating or editing your coding standard.", "title": "Configuring a coding standard (advanced setup)"}, {"location": "organizations/using-coding-standards/#set-default", "text": "For ease of management, you can define multiple default coding standards that automatically apply to new repositories. In the absence of default coding standards, Codacy applies global defaults to all new repositories. Note When Codacy introduces new tools, those are automatically added to the global Codacy defaults but need to be manually added to a default coding standard. You can mark a new coding standard as default when creating one. To mark an existing coding standard as default: Open your organization Policies page, tab Coding standards . Toggle Apply to new repositoriet on the relevant coding standard card.", "title": "Defining default coding standards"}, {"location": "organizations/using-coding-standards/#editing", "text": "Note Any edits to the configurations of a coding standard are automatically applied on the next analysis of each associated repository. To edit an existing coding standard or change the repositories that follow that coding standard: Open your organization Policies page, tab Coding standards . Click the edit icon on the coding standard card. Edit the current coding standard configurations and click the button Next to advance to the following configuration pages : Note When editing an existing coding standard, the advanced setup is the default view. Select languages : the programming languages that the coding standard applies to. On this page, you can rename the coding standard by clicking the edit icon next to the name of the coding standard. Choose tools and patterns : the tool and code pattern configurations of the coding standard. Select and apply to repositories : the repositories that follow the coding standard. Click the button Save and apply coding standard on the repository selection page to save your changes to the coding standard. Codacy will start using the updated coding standard on the next analysis of each selected repository.", "title": "Editing a coding standard"}, {"location": "organizations/using-coding-standards/#deleting", "text": "To delete a coding standard: Open your organization Policies page, tab Coding standards . Click the trash can icon on the coding standard card and confirm.", "title": "Deleting a coding standard"}, {"location": "organizations/using-coding-standards/#using-with-tool-configuration", "text": "When using a tool configuration file alongside a coding standard, the configuration file controls the code patterns, while the coding standard controls whether the tool is enabled or disabled.", "title": "Using a coding standard alongside tool configuration files"}, {"location": "organizations/using-coding-standards/#using-multiple", "text": "When Codacy analyzes your code using multiple coding standards, it merges the tools and patterns from each standard. Enabled tools and patterns in any applied standard will be enforced. Important If the same pattern appears in multiple standards, the version from the most recently applied standard (with its parameters) takes precedence.", "title": "Using multiple coding standards"}, {"location": "organizations/using-coding-standards/#see-also", "text": "Configuring code patterns on each repository How to implement Google JavaScript style guide with Codacy", "title": "See also"}, {"location": "organizations/using-gate-policies/", "text": "Using gate policies # Gate policies help you ensure that Codacy uses the same quality gates across your organization repositories. Codacy provides a built-in gate policy, Codacy Gate Policy , which sets minimum quality levels for pull requests and commits. The following screenshot displays the default configuration values: By default, Codacy applies the Codacy Gate Policy automatically to newly added repositories. You can then create new gate policies with different quality gates and make them the default for your organization. Creating a new gate policy # To create a new gate policy for your organization: Open your organization Policies page, tab Gate policies . Click the button Create new gate policy at the top right-hand corner of the page. This opens a window with the gate policy creation form. Enter a unique name and click Create gate policy . Set the values for the quality gates and click Next: Select and apply to repositories . Select existing repositories that should follow the gate policy and click Save and apply gate policy . Codacy will start using the new gate policy on the next analysis of each selected repository. Setting a gate policy as default # To set a gate policy as default: Open your organization Policies page, tab Gate policies . Toggle Make default on the relevant gate policy card. Note Only one gate policy at a time can be the default gate policy. Codacy will start applying the default gate policy to newly added repositories. Editing a gate policy # To edit the quality gates of an existing gate policy or change the repositories that follow that gate policy: Open your organization Policies page, tab Gate policies . Click the edit icon on the gate policy card. Edit the current quality gate values and click the button Next: Select and apply to repositories . Note You can't change the quality gate values of the built-in Codacy Gate Policy . Edit the list of repositories that follow the gate policy. Click the button Save and apply gate policy to save your changes to the gate policy. Codacy will start using the updated gate policy on the next analysis of each selected repository. If you stop applying a gate policy to a repository, Codacy restores the previous quality gates of that repository. Deleting a gate policy # Note You can't delete the built-in Codacy Gate Policy . To delete an organization gate policy: Open your organization Policies page, tab Gate policies . Click the trash can icon on the gate policy card and confirm. When you delete a gate policy: Codacy restores the previous quality gates of each repository following that gate policy. If the deleted gate policy was the default for your organization, Codacy makes the built-in Codacy Gate Policy the default.", "title": "Using gate policies"}, {"location": "organizations/using-gate-policies/#using-gate-policies", "text": "Gate policies help you ensure that Codacy uses the same quality gates across your organization repositories. Codacy provides a built-in gate policy, Codacy Gate Policy , which sets minimum quality levels for pull requests and commits. The following screenshot displays the default configuration values: By default, Codacy applies the Codacy Gate Policy automatically to newly added repositories. You can then create new gate policies with different quality gates and make them the default for your organization.", "title": "Using gate policies"}, {"location": "organizations/using-gate-policies/#creating", "text": "To create a new gate policy for your organization: Open your organization Policies page, tab Gate policies . Click the button Create new gate policy at the top right-hand corner of the page. This opens a window with the gate policy creation form. Enter a unique name and click Create gate policy . Set the values for the quality gates and click Next: Select and apply to repositories . Select existing repositories that should follow the gate policy and click Save and apply gate policy . Codacy will start using the new gate policy on the next analysis of each selected repository.", "title": "Creating a new gate policy"}, {"location": "organizations/using-gate-policies/#set-default", "text": "To set a gate policy as default: Open your organization Policies page, tab Gate policies . Toggle Make default on the relevant gate policy card. Note Only one gate policy at a time can be the default gate policy. Codacy will start applying the default gate policy to newly added repositories.", "title": "Setting a gate policy as default"}, {"location": "organizations/using-gate-policies/#editing", "text": "To edit the quality gates of an existing gate policy or change the repositories that follow that gate policy: Open your organization Policies page, tab Gate policies . Click the edit icon on the gate policy card. Edit the current quality gate values and click the button Next: Select and apply to repositories . Note You can't change the quality gate values of the built-in Codacy Gate Policy . Edit the list of repositories that follow the gate policy. Click the button Save and apply gate policy to save your changes to the gate policy. Codacy will start using the updated gate policy on the next analysis of each selected repository. If you stop applying a gate policy to a repository, Codacy restores the previous quality gates of that repository.", "title": "Editing a gate policy"}, {"location": "organizations/using-gate-policies/#deleting", "text": "Note You can't delete the built-in Codacy Gate Policy . To delete an organization gate policy: Open your organization Policies page, tab Gate policies . Click the trash can icon on the gate policy card and confirm. When you delete a gate policy: Codacy restores the previous quality gates of each repository following that gate policy. If the deleted gate policy was the default for your organization, Codacy makes the built-in Codacy Gate Policy the default.", "title": "Deleting a gate policy"}, {"location": "organizations/what-are-organizations/", "text": "What are organizations # Codacy organizations let you automatically import your Git provider organizations, repositories (including your personal repositories that don't belong to a Git provider organization), and team members into Codacy with a few clicks. Changes to the organizations, repositories, and team members are synchronized with Codacy in real-time, avoiding the manual management of repositories and teams. Adding an organization # To add a new organization to Codacy, select Add organization on the navigation menu. This opens the list of organizations on your Git providers. The organization with the same name as your Git provider username contains your personal repositories. To add a new organization to Codacy, click the link Add for that organization. To join an organization that's already on Codacy, click the link Join for that organization. To add organizations from a Git provider not yet listed on this page, click Add provider and give the necessary permissions for Codacy to sync with the new Git provider and display your organizations. Note If you can't see the organization you're looking for, follow these troubleshooting instructions . Updates on the Git provider # If you update your organization or repository information on your Git provider, some changes are automatically reflected on Codacy, as described in the table below. Note If an update to your organization name isn't automatically reflected on Codacy, navigate to the organization Settings page, tab Profile , and click the Synchronize button. Git provider Rename repository Change repository visibility Delete repository Rename organization or group Remove member from organization or group Delete organization or group GitHub Cloud Yes Yes Yes Yes Yes Yes GitHub Enterprise Yes Yes Yes Yes Yes Yes GitLab Cloud No No No No No No GitLab Enterprise Yes Yes Yes Yes Yes Yes Bitbucket Cloud Yes Yes No No No No Bitbucket Server Yes Yes No No No No Check out the roles and permission mapping from the Git providers . Deleting an organization # Deleting an organization on Codacy completely removes the configurations and all data related to the organization and its repositories from Codacy. This operation doesn't make any changes on your Git provider. To delete an organization, open the Profile page and click the button Delete organization . Note If you're using Codacy Cloud we'll ask for your feedback on why you're deleting your organization. See also # How does Codacy support GitLab Cloud? How does Codacy support GitLab Enterprise? How does Codacy support Bitbucket Cloud? How does Codacy support Bitbucket Server?", "title": "What are organizations"}, {"location": "organizations/what-are-organizations/#what-are-organizations", "text": "Codacy organizations let you automatically import your Git provider organizations, repositories (including your personal repositories that don't belong to a Git provider organization), and team members into Codacy with a few clicks. Changes to the organizations, repositories, and team members are synchronized with Codacy in real-time, avoiding the manual management of repositories and teams.", "title": "What are organizations"}, {"location": "organizations/what-are-organizations/#adding-an-organization", "text": "To add a new organization to Codacy, select Add organization on the navigation menu. This opens the list of organizations on your Git providers. The organization with the same name as your Git provider username contains your personal repositories. To add a new organization to Codacy, click the link Add for that organization. To join an organization that's already on Codacy, click the link Join for that organization. To add organizations from a Git provider not yet listed on this page, click Add provider and give the necessary permissions for Codacy to sync with the new Git provider and display your organizations. Note If you can't see the organization you're looking for, follow these troubleshooting instructions .", "title": "Adding an organization"}, {"location": "organizations/what-are-organizations/#updates-on-the-git-provider", "text": "If you update your organization or repository information on your Git provider, some changes are automatically reflected on Codacy, as described in the table below. Note If an update to your organization name isn't automatically reflected on Codacy, navigate to the organization Settings page, tab Profile , and click the Synchronize button. Git provider Rename repository Change repository visibility Delete repository Rename organization or group Remove member from organization or group Delete organization or group GitHub Cloud Yes Yes Yes Yes Yes Yes GitHub Enterprise Yes Yes Yes Yes Yes Yes GitLab Cloud No No No No No No GitLab Enterprise Yes Yes Yes Yes Yes Yes Bitbucket Cloud Yes Yes No No No No Bitbucket Server Yes Yes No No No No Check out the roles and permission mapping from the Git providers .", "title": "Updates on the Git provider"}, {"location": "organizations/what-are-organizations/#deleting-an-organization", "text": "Deleting an organization on Codacy completely removes the configurations and all data related to the organization and its repositories from Codacy. This operation doesn't make any changes on your Git provider. To delete an organization, open the Profile page and click the button Delete organization . Note If you're using Codacy Cloud we'll ask for your feedback on why you're deleting your organization.", "title": "Deleting an organization"}, {"location": "organizations/what-are-organizations/#see-also", "text": "How does Codacy support GitLab Cloud? How does Codacy support GitLab Enterprise? How does Codacy support Bitbucket Cloud? How does Codacy support Bitbucket Server?", "title": "See also"}, {"location": "organizations/integrations/default-git-provider-integration-settings/", "text": "Default Git provider integration settings # You can configure the default settings that Codacy uses to integrate with your Git provider when you add a new repository to Codacy. This enables you to apply the same settings across your organization repositories. To configure these default settings, open your organization Integrations page and select your Git provider. The organization-level Git provider integration settings define the defaults that Codacy applies to new repositories. You can then customize the settings for each individual repository, which depend on your Git provider, GitHub , GitLab or Bitbucket . Applying default settings to all repositories # To ensure that all your repositories are configured with the default Git provider integration settings defined for your organization, click the button Apply default to all repositories . See also # Integrating Codacy with your Git workflow", "title": "Default Git provider integration settings"}, {"location": "organizations/integrations/default-git-provider-integration-settings/#default-git-provider-integration-settings", "text": "You can configure the default settings that Codacy uses to integrate with your Git provider when you add a new repository to Codacy. This enables you to apply the same settings across your organization repositories. To configure these default settings, open your organization Integrations page and select your Git provider. The organization-level Git provider integration settings define the defaults that Codacy applies to new repositories. You can then customize the settings for each individual repository, which depend on your Git provider, GitHub , GitLab or Bitbucket .", "title": "Default Git provider integration settings"}, {"location": "organizations/integrations/default-git-provider-integration-settings/#apply-all", "text": "To ensure that all your repositories are configured with the default Git provider integration settings defined for your organization, click the button Apply default to all repositories .", "title": "Applying default settings to all repositories"}, {"location": "organizations/integrations/default-git-provider-integration-settings/#see-also", "text": "Integrating Codacy with your Git workflow", "title": "See also"}, {"location": "organizations/integrations/jira-integration/", "text": "Organization Jira integration for Security and risk management # This integration is only available for Jira Cloud Integrate Jira with Security and risk management to import your Jira issues and manage them all in one place as security items. Installing the Jira integration # To install the Jira integration: On Jira, add the label security (case-insensitive) to the issues you wish to import and confirm that they use the right Jira priorities to correctly map to item severities . Tip Add the security label as a default to all new Jira issues that track security-related work in your organization. Open your organization Integrations , page Jira , and click Install Jira to proceed to Atlassian's website. Note Use a Jira account with admin permissions when installing this integration. This lets Codacy access all issues, since the integration inherits the permissions of the account that installs it. On Atlassian's website, authorize Codacy. Once successful, you're redirected back to Codacy. After installing, Codacy imports all open Jira issues labeled security and created up to 90 days before the integration and then retrieves updates from Jira once a day. For more information on how this integration works, see how Codacy manages security items and how Codacy assigns security item severities . Uninstalling the Jira integration # To uninstall the Jira integration, open your organization Integrations , page Jira , then click Uninstall Jira and confirm. Important Uninstalling the Jira integration as described above deletes all associated open items. You can alternatively uninstall the Jira integration on the Jira website: this doesn't delete anything, but it prevents Codacy from opening new Jira-related items.", "title": "Jira integration for Security and risk management"}, {"location": "organizations/integrations/jira-integration/#organization-jira-integration-for-security-and-risk-management", "text": "This integration is only available for Jira Cloud Integrate Jira with Security and risk management to import your Jira issues and manage them all in one place as security items.", "title": "Organization Jira integration for Security and risk management"}, {"location": "organizations/integrations/jira-integration/#installing-the-jira-integration", "text": "To install the Jira integration: On Jira, add the label security (case-insensitive) to the issues you wish to import and confirm that they use the right Jira priorities to correctly map to item severities . Tip Add the security label as a default to all new Jira issues that track security-related work in your organization. Open your organization Integrations , page Jira , and click Install Jira to proceed to Atlassian's website. Note Use a Jira account with admin permissions when installing this integration. This lets Codacy access all issues, since the integration inherits the permissions of the account that installs it. On Atlassian's website, authorize Codacy. Once successful, you're redirected back to Codacy. After installing, Codacy imports all open Jira issues labeled security and created up to 90 days before the integration and then retrieves updates from Jira once a day. For more information on how this integration works, see how Codacy manages security items and how Codacy assigns security item severities .", "title": "Installing the Jira integration"}, {"location": "organizations/integrations/jira-integration/#uninstalling-the-jira-integration", "text": "To uninstall the Jira integration, open your organization Integrations , page Jira , then click Uninstall Jira and confirm. Important Uninstalling the Jira integration as described above deletes all associated open items. You can alternatively uninstall the Jira integration on the Jira website: this doesn't delete anything, but it prevents Codacy from opening new Jira-related items.", "title": "Uninstalling the Jira integration"}, {"location": "organizations/integrations/slack-integration/", "text": "Organization Slack integration for Security issues # The organization Slack integration for Security issues sends notifications to a Slack channel of your choice whenever Codacy detects new critical Security issues in the default branch of any repository in your organization. Installing the Slack integration # To install the Slack integration: On Slack : Access the Incoming WebHooks page on the App Directory of your Slack account. Select the channel where you want to receive notifications and click Add Incoming WebHooks Integration . Copy the Incoming WebHook URL (it starts with https://hooks.slack.com/services/ ). On Codacy : Open your organization Integrations , page Slack . Paste the Incoming WebHook URL in the field and click Install Slack . Once the Slack integration is installed, Codacy sends a confirmation message to the Slack channel you configured when creating the Incoming WebHook. From there on, Codacy notifies you on the same channel whenever a new critical Security issue is detected in the default branch of any repository in your organization. Uninstalling the Slack integration # To uninstall the Slack integration, open your organization Integrations , page Slack , then click Uninstall Slack and confirm.", "title": "Slack integration for Security issues"}, {"location": "organizations/integrations/slack-integration/#organization-slack-integration-for-security-issues", "text": "The organization Slack integration for Security issues sends notifications to a Slack channel of your choice whenever Codacy detects new critical Security issues in the default branch of any repository in your organization.", "title": "Organization Slack integration for Security issues"}, {"location": "organizations/integrations/slack-integration/#installing-the-slack-integration", "text": "To install the Slack integration: On Slack : Access the Incoming WebHooks page on the App Directory of your Slack account. Select the channel where you want to receive notifications and click Add Incoming WebHooks Integration . Copy the Incoming WebHook URL (it starts with https://hooks.slack.com/services/ ). On Codacy : Open your organization Integrations , page Slack . Paste the Incoming WebHook URL in the field and click Install Slack . Once the Slack integration is installed, Codacy sends a confirmation message to the Slack channel you configured when creating the Incoming WebHook. From there on, Codacy notifies you on the same channel whenever a new critical Security issue is detected in the default branch of any repository in your organization.", "title": "Installing the Slack integration"}, {"location": "organizations/integrations/slack-integration/#uninstalling-the-slack-integration", "text": "To uninstall the Slack integration, open your organization Integrations , page Slack , then click Uninstall Slack and confirm.", "title": "Uninstalling the Slack integration"}, {"location": "release-notes/", "text": "Codacy release notes # This section contains the release notes for Codacy Cloud and Codacy Self-hosted. For product updates that are in progress or planned visit the Codacy public roadmap instead . Tip Subscribe to this RSS feed using your favorite news aggregator to receive notifications when there are new Codacy release notes. Codacy Cloud release notes # 2024 Cloud July 2024 Cloud June 2024 Cloud May 2024 Cloud April 2024 Cloud March 2024 Cloud February 2024 Cloud January 2024 Discontinuation of SSH keys for GitHub repositories January 15, 2024 2023 Cloud December 2023 Cloud November 2023 Rollout of new Coverage engine November 23, 2023 Removal of Jira, Slack, and Webhooks repository integrations November 13, 2023 Cloud October 2023 Deprecation of CSSLint, JSHint, Faux Pas, Tailor, TSLint October 25, 2023 Deprecation of bundler-audit October 13, 2023 Cloud September 2023 Cloud August 2023 Cloud July 2023 Cloud June 2023 Cloud May 2023 Cloud April 2023 Cloud March 2023 Cloud February 2023 Cloud January 2023 2022 Cloud December 2022 Cloud November 2022 Cloud October 2022 Cloud September 2022 Cloud August 2022 Cloud July 2022 Cloud June 2022 Cloud May 2022 Cloud April 2022 Cloud March 2022 Adding ESLint 8 as a supported tool March 31, 2022 Cloud February 2022 Removal of PMD (Legacy) February 16, 2022 Cloud January 2022 2021 Cloud December 2021 Cloud November 2021 Cloud October 2021 Cloud September 2021 End of support for legacy manual organizations November 2, 2021 Cloud August 2021 Performing scheduled database maintenance July 3, 2021 2020 Deprecating HTTP headers for API tokens April 1, 2020 Removal of NodeSecurity, GoLint, and SCSS Lint March 9, 2020 Codacy now supports GitHub Apps February 2, 2020 2019 Cloud November 15, 2019 Cloud October 30, 2019 Cloud September 5, 2019 Cloud August 7, 2019 Cloud June 18, 2019 Cloud May 20, 2019 Cloud May 5, 2019 Cloud April 8, 2019 Cloud March 29, 2019 Bitbucket changes February 18, 2019 Cloud January 2, 2019 2018 Cloud November 16, 2018 Cloud November 2, 2018 Cloud October 19, 2018 Cloud July 23, 2018 Codacy Self-hosted release notes # v14 v14.0.0 (June 26, 2024) v13 v13.0.0 (November 23, 2023) v12 v12.0.0 (July 20, 2023) v11 v11.0.0 (April 20, 2023) v10 v10.0.0 (February 3, 2023) v9 v9.0.0 (September 23, 2022) v8 v8.1.0 (June 17, 2022) v8.0.0 (May 12, 2022) v7 v7.0.0 (April 4, 2022) v6 v6.0.0 (March 2, 2022) v5 v5.1.0 (January 6, 2022) v5.0.0 (December 17, 2021) v4 v4.4.0 (October 12, 2021) v4.3.0 (September 16, 2021) v4.2.0 (August 31, 2021) v4.1.0 (July 6, 2021) v4.0.1 (June 2, 2021) v4.0.0 (May 18, 2021) v3 v3.5.1 (June 1, 2021) v3.5.0 (March 31, 2021) v3.4.0 (March 12, 2021) v3.3.0 (February 12, 2021) v3.2.0 (December 17, 2020) v3.1.0 (December 10, 2020) v3.0.0 (November 2, 2020) v2 v2.2.1 (October 22, 2020) v2.2.0 (October 8, 2020) v2.1.1 (September 24, 2020) v2.1.0 (September 16, 2020) v2.0.0 (August 18, 2020) v1 v1.5.0 (July 20, 2020) v1.4.0 (June 23, 2020) v1.3.0 (June 12, 2020) v1.2.0 (June 4, 2020) v1.1.0 (May 26, 2020) v1.0.1 (May 21, 2020) v1.0.0 (May 18, 2020)", "title": "Codacy release notes"}, {"location": "release-notes/#codacy-release-notes", "text": "This section contains the release notes for Codacy Cloud and Codacy Self-hosted. For product updates that are in progress or planned visit the Codacy public roadmap instead . Tip Subscribe to this RSS feed using your favorite news aggregator to receive notifications when there are new Codacy release notes.", "title": "Codacy release notes"}, {"location": "release-notes/#cloud", "text": "2024 Cloud July 2024 Cloud June 2024 Cloud May 2024 Cloud April 2024 Cloud March 2024 Cloud February 2024 Cloud January 2024 Discontinuation of SSH keys for GitHub repositories January 15, 2024 2023 Cloud December 2023 Cloud November 2023 Rollout of new Coverage engine November 23, 2023 Removal of Jira, Slack, and Webhooks repository integrations November 13, 2023 Cloud October 2023 Deprecation of CSSLint, JSHint, Faux Pas, Tailor, TSLint October 25, 2023 Deprecation of bundler-audit October 13, 2023 Cloud September 2023 Cloud August 2023 Cloud July 2023 Cloud June 2023 Cloud May 2023 Cloud April 2023 Cloud March 2023 Cloud February 2023 Cloud January 2023 2022 Cloud December 2022 Cloud November 2022 Cloud October 2022 Cloud September 2022 Cloud August 2022 Cloud July 2022 Cloud June 2022 Cloud May 2022 Cloud April 2022 Cloud March 2022 Adding ESLint 8 as a supported tool March 31, 2022 Cloud February 2022 Removal of PMD (Legacy) February 16, 2022 Cloud January 2022 2021 Cloud December 2021 Cloud November 2021 Cloud October 2021 Cloud September 2021 End of support for legacy manual organizations November 2, 2021 Cloud August 2021 Performing scheduled database maintenance July 3, 2021 2020 Deprecating HTTP headers for API tokens April 1, 2020 Removal of NodeSecurity, GoLint, and SCSS Lint March 9, 2020 Codacy now supports GitHub Apps February 2, 2020 2019 Cloud November 15, 2019 Cloud October 30, 2019 Cloud September 5, 2019 Cloud August 7, 2019 Cloud June 18, 2019 Cloud May 20, 2019 Cloud May 5, 2019 Cloud April 8, 2019 Cloud March 29, 2019 Bitbucket changes February 18, 2019 Cloud January 2, 2019 2018 Cloud November 16, 2018 Cloud November 2, 2018 Cloud October 19, 2018 Cloud July 23, 2018", "title": "Codacy Cloud release notes"}, {"location": "release-notes/#self-hosted", "text": "v14 v14.0.0 (June 26, 2024) v13 v13.0.0 (November 23, 2023) v12 v12.0.0 (July 20, 2023) v11 v11.0.0 (April 20, 2023) v10 v10.0.0 (February 3, 2023) v9 v9.0.0 (September 23, 2022) v8 v8.1.0 (June 17, 2022) v8.0.0 (May 12, 2022) v7 v7.0.0 (April 4, 2022) v6 v6.0.0 (March 2, 2022) v5 v5.1.0 (January 6, 2022) v5.0.0 (December 17, 2021) v4 v4.4.0 (October 12, 2021) v4.3.0 (September 16, 2021) v4.2.0 (August 31, 2021) v4.1.0 (July 6, 2021) v4.0.1 (June 2, 2021) v4.0.0 (May 18, 2021) v3 v3.5.1 (June 1, 2021) v3.5.0 (March 31, 2021) v3.4.0 (March 12, 2021) v3.3.0 (February 12, 2021) v3.2.0 (December 17, 2020) v3.1.0 (December 10, 2020) v3.0.0 (November 2, 2020) v2 v2.2.1 (October 22, 2020) v2.2.0 (October 8, 2020) v2.1.1 (September 24, 2020) v2.1.0 (September 16, 2020) v2.0.0 (August 18, 2020) v1 v1.5.0 (July 20, 2020) v1.4.0 (June 23, 2020) v1.3.0 (June 12, 2020) v1.2.0 (June 4, 2020) v1.1.0 (May 26, 2020) v1.0.1 (May 21, 2020) v1.0.0 (May 18, 2020)", "title": "Codacy Self-hosted release notes"}, {"location": "repositories/commits/", "text": "Quality Commits page # The Quality Commits page displays an overview of the commits in your repository, such as the analysis status and the code quality metrics for each commit. This allows you to monitor the evolution of the code quality per commit in your repository. By default, the page lists the commits on the main branch of your repository, but if you have more than one branch enabled you can use the drop-down list at the top of the page to display commits on other branches. Click a specific commit to see detailed information about the code quality changes introduced by that commit. The next sections describe each area of the commit detail page. Commit status # This area displays the information that identifies the commit (commit message, committer, SHA hash, and last updated date), as well as: A link to the commit on your Git provider A link to reanalyze the commit , present when the committer is part of your organization A link to view analysis logs Commit quality overview # This area displays the quality gate status for the commit and the code quality metrics with a gate set up : The quality gate status is either Up to quality standards or Not up to quality standards depending on the quality gate rules for your repository. If there are no gate rules enabled for commits, the status is always Up to quality standards . The variation introduced by the commit is displayed either as a positive or negative variation , or no variation (represented by = ) for code quality metrics with a gate set up : Issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Coverage variation: Changes in code coverage percentage compared with the parent commit Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ). Note Learn how Codacy calculates the code quality metrics in more detail: Which code quality metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the quality gate rules for your repository: Green: The metric passes the quality gate Red: The metric fails the quality gate Gray: The metric has no value Note If you change the quality gate rules you must reanalyze the commit to update the metrics and optionally re-upload the Coverage report if you also changed the coverage gate rules. Issues tab # The Issues tab displays the lists of issues that the commit creates or fixes. Use the sidebar filters to filter the list by new issues (including issues of specific severity or category), issues within a specific file, fixed issues, potential new issues, or potential fixed issues . Click the title of an issue card to expand it and see the following information: The committer and date of the commit that introduced the issue, if available The estimated time to fix the issue What the issue is and how to solve it The tool that reported the issue and the related code pattern To ignore or manage an issue , click the associated options in the menu. Potential issues # Codacy may label some issues as potential , which means that the code analysis detected these issues in lines of code that weren't changed by the analyzed commit. This highlights potential consequences in other parts of your codebase. The following are example situations that can lead to potential issues: The issue was either created or fixed in the current commit, but the static code analysis tools reported the issue on a line that didn't change in the commit. For example, if you remove the line containing the declaration of a variable you may get an \"undeclared variable\" issue in other lines that use that variable. If a file had more than 50 issues reported by the same tool and you push a new commit that fixes some of these issues, Codacy will report more issues until the limit of 50 issues. These issues will be potential issues if they're outside the lines of code changed in the new commit. Note If you're using GitHub you may see annotations for potential issues reported under Unchanged files with check annotations on the Files changed tab of your pull requests. This happens when Codacy reports potential issues in files that weren't changed in your pull request. Read more about this GitHub feature . Duplication tab # The Duplication tab displays the lists of clones (duplicated code blocks) that the commit adds or fixes. You can click a clone to expand it and inspect the code. Complexity tab # The Complexity tab displays the complexity changes introduced by the commit. Use the sidebar filters to filter the list by high increase (4 or more), low increase (1 to 3), or improvement (less than 0). Note When calculating the complexity variation introduced by a commit, Codacy only considers files with a high increase in complexity. For more information, see how Codacy calculates cyclomatic complexity . Coverage tab # The Coverage tab displays a line-by-line view of the coverage variation introduced by the commit. It includes the following areas: A list of files modified by the commit, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the commit The coverage variation introduced by the commit (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line Diff tab # The Diff tab displays the code changes and issues introduced by the commit. It includes the following areas: A list of files modified by the commit, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the commit The number of new issues introduced by the commit A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. Lines with issues are highlighted according to issue severity and include a pill label with the issue type and count. Hover over the pill label to view more details or navigate to the issues. Files tab # The Files tab displays the variation of the following code quality metrics that the commit introduces to the files in your repository, displayed either as a positive or negative variation , or no variation (represented by = ): New issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Coverage variation: Changes in code coverage percentage compared with the parent commit Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ). Viewing analysis logs # Analysis logs can help you identify the duration of each analysis phase and any potential issues. To access the analysis logs, click the View logs link in the commit status area. This opens a modal displaying execution times and outcomes for the tools used to analyze the commit. See also # Which metrics does Codacy calculate?", "title": "Quality Commits page"}, {"location": "repositories/commits/#quality-commits-page", "text": "The Quality Commits page displays an overview of the commits in your repository, such as the analysis status and the code quality metrics for each commit. This allows you to monitor the evolution of the code quality per commit in your repository. By default, the page lists the commits on the main branch of your repository, but if you have more than one branch enabled you can use the drop-down list at the top of the page to display commits on other branches. Click a specific commit to see detailed information about the code quality changes introduced by that commit. The next sections describe each area of the commit detail page.", "title": "Quality Commits page"}, {"location": "repositories/commits/#status", "text": "This area displays the information that identifies the commit (commit message, committer, SHA hash, and last updated date), as well as: A link to the commit on your Git provider A link to reanalyze the commit , present when the committer is part of your organization A link to view analysis logs", "title": "Commit status"}, {"location": "repositories/commits/#quality-overview", "text": "This area displays the quality gate status for the commit and the code quality metrics with a gate set up : The quality gate status is either Up to quality standards or Not up to quality standards depending on the quality gate rules for your repository. If there are no gate rules enabled for commits, the status is always Up to quality standards . The variation introduced by the commit is displayed either as a positive or negative variation , or no variation (represented by = ) for code quality metrics with a gate set up : Issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Coverage variation: Changes in code coverage percentage compared with the parent commit Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ). Note Learn how Codacy calculates the code quality metrics in more detail: Which code quality metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the quality gate rules for your repository: Green: The metric passes the quality gate Red: The metric fails the quality gate Gray: The metric has no value Note If you change the quality gate rules you must reanalyze the commit to update the metrics and optionally re-upload the Coverage report if you also changed the coverage gate rules.", "title": "Commit quality overview"}, {"location": "repositories/commits/#issues-tabs", "text": "The Issues tab displays the lists of issues that the commit creates or fixes. Use the sidebar filters to filter the list by new issues (including issues of specific severity or category), issues within a specific file, fixed issues, potential new issues, or potential fixed issues . Click the title of an issue card to expand it and see the following information: The committer and date of the commit that introduced the issue, if available The estimated time to fix the issue What the issue is and how to solve it The tool that reported the issue and the related code pattern To ignore or manage an issue , click the associated options in the menu.", "title": "Issues tab"}, {"location": "repositories/commits/#duplication-tabs", "text": "The Duplication tab displays the lists of clones (duplicated code blocks) that the commit adds or fixes. You can click a clone to expand it and inspect the code.", "title": "Duplication tab"}, {"location": "repositories/commits/#complexity-tab", "text": "The Complexity tab displays the complexity changes introduced by the commit. Use the sidebar filters to filter the list by high increase (4 or more), low increase (1 to 3), or improvement (less than 0). Note When calculating the complexity variation introduced by a commit, Codacy only considers files with a high increase in complexity. For more information, see how Codacy calculates cyclomatic complexity .", "title": "Complexity tab"}, {"location": "repositories/commits/#coverage-tab", "text": "The Coverage tab displays a line-by-line view of the coverage variation introduced by the commit. It includes the following areas: A list of files modified by the commit, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the commit The coverage variation introduced by the commit (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line", "title": "Coverage tab"}, {"location": "repositories/commits/#diff-tab", "text": "The Diff tab displays the code changes and issues introduced by the commit. It includes the following areas: A list of files modified by the commit, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the commit The number of new issues introduced by the commit A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. Lines with issues are highlighted according to issue severity and include a pill label with the issue type and count. Hover over the pill label to view more details or navigate to the issues.", "title": "Diff tab"}, {"location": "repositories/commits/#files-tab", "text": "The Files tab displays the variation of the following code quality metrics that the commit introduces to the files in your repository, displayed either as a positive or negative variation , or no variation (represented by = ): New issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Coverage variation: Changes in code coverage percentage compared with the parent commit Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ).", "title": "Files tab"}, {"location": "repositories/commits/#viewing-analysis-logs", "text": "Analysis logs can help you identify the duration of each analysis phase and any potential issues. To access the analysis logs, click the View logs link in the commit status area. This opens a modal displaying execution times and outcomes for the tools used to analyze the commit.", "title": "Viewing analysis logs"}, {"location": "repositories/commits/#see-also", "text": "Which metrics does Codacy calculate?", "title": "See also"}, {"location": "repositories/files/", "text": "Quality Files page # The Quality Files page displays the current code quality information for each analyzed file in your enabled repository branches . By default, the page lists the files on the main branch of your repository. However, if you have more than one branch enabled , you can select other branches using the drop-down list at the top of the page. Codacy displays the following code quality metrics for each file, if available: Grade: Overall grade of the file Issues: Number of issues in the file Complexity: Cyclomatic complexity of the file Duplication: Number of duplicated code blocks in the file Coverage: Percentage of coverable source lines of code that are covered by tests Codacy displays the files in alphabetical order by default, but you can sort the list by each column to help you identify which files you should improve or refactor next. Note You can use the Codacy API to generate reports or obtain code quality metrics for the files in your repositories in a more flexible way. Use the search box to filter the list and find specific files: File details # Click a specific file to see more detailed analysis information for that file. The header of the file detail page displays the same code quality metrics as the Files page, as well as: An Ignore file link to ignore the selected file on future Codacy analysis A link to view the file on your Git provider Depending on the available analysis information for the file, Codacy displays one or more of the following tabs: Issues: Shows the annotated source code on the left-hand side and the matching list of issues and issue distribution by severity on the right-hand side. Each listed issue includes the same information and options available on the Quality Issues page . Duplication: Shows the annotated source code on the left-hand side and the matching list of duplicated code blocks and counts on the right-hand side. Each listed duplicate includes the number of clones and their locations. Coverage: Shows which lines of code are covered by tests (green background labeled with test hit count) or not covered (red background), along with the counts of coverable and covered lines and the file status with respect to the coverage goal . Why are some files missing? # The Files page only displays files in your repository that were analyzed by Codacy. This means that some of your files may be missing from the list, for example: You're viewing the incorrect branch Not all files may exist in all branches of your repositories. Make sure that you're displaying files for the correct branch. The file might be ignored The Files page doesn't display ignored files that aren't meant to be analyzed, including the files that Codacy ignores by default . The file has an extension that is not on the list of supported extensions Codacy supports a list of file extensions associated with each language. Codacy doesn't analyze or display files with extensions that aren't associated with a language. The file might be too big Codacy doesn't analyze or display files that are over a certain size. Read more details for information on how to overcome this limit. See also # Which metrics does Codacy calculate? Using the Codacy API to obtain code quality metrics for files", "title": "Quality Files page"}, {"location": "repositories/files/#quality-files-page", "text": "The Quality Files page displays the current code quality information for each analyzed file in your enabled repository branches . By default, the page lists the files on the main branch of your repository. However, if you have more than one branch enabled , you can select other branches using the drop-down list at the top of the page. Codacy displays the following code quality metrics for each file, if available: Grade: Overall grade of the file Issues: Number of issues in the file Complexity: Cyclomatic complexity of the file Duplication: Number of duplicated code blocks in the file Coverage: Percentage of coverable source lines of code that are covered by tests Codacy displays the files in alphabetical order by default, but you can sort the list by each column to help you identify which files you should improve or refactor next. Note You can use the Codacy API to generate reports or obtain code quality metrics for the files in your repositories in a more flexible way. Use the search box to filter the list and find specific files:", "title": "Quality Files page"}, {"location": "repositories/files/#file-details", "text": "Click a specific file to see more detailed analysis information for that file. The header of the file detail page displays the same code quality metrics as the Files page, as well as: An Ignore file link to ignore the selected file on future Codacy analysis A link to view the file on your Git provider Depending on the available analysis information for the file, Codacy displays one or more of the following tabs: Issues: Shows the annotated source code on the left-hand side and the matching list of issues and issue distribution by severity on the right-hand side. Each listed issue includes the same information and options available on the Quality Issues page . Duplication: Shows the annotated source code on the left-hand side and the matching list of duplicated code blocks and counts on the right-hand side. Each listed duplicate includes the number of clones and their locations. Coverage: Shows which lines of code are covered by tests (green background labeled with test hit count) or not covered (red background), along with the counts of coverable and covered lines and the file status with respect to the coverage goal .", "title": "File details"}, {"location": "repositories/files/#missing-files", "text": "The Files page only displays files in your repository that were analyzed by Codacy. This means that some of your files may be missing from the list, for example: You're viewing the incorrect branch Not all files may exist in all branches of your repositories. Make sure that you're displaying files for the correct branch. The file might be ignored The Files page doesn't display ignored files that aren't meant to be analyzed, including the files that Codacy ignores by default . The file has an extension that is not on the list of supported extensions Codacy supports a list of file extensions associated with each language. Codacy doesn't analyze or display files with extensions that aren't associated with a language. The file might be too big Codacy doesn't analyze or display files that are over a certain size. Read more details for information on how to overcome this limit.", "title": "Why are some files missing?"}, {"location": "repositories/files/#see-also", "text": "Which metrics does Codacy calculate? Using the Codacy API to obtain code quality metrics for files", "title": "See also"}, {"location": "repositories/issues/", "text": "Quality Issues page # The Quality Issues page lists all the issues that Codacy detected in your repository, including the severity level and category of each issue. By default, the page lists the issues on the main branch of your repository but if you have more than one branch enabled you can use the drop-down list at the top of the page to display issues on other branches. Note You can use the Codacy API to generate reports or obtain information about the current issues in your repositories in a more flexible way. Click the title of an issue card to expand it and see the following information: The committer and date of the commit that introduced the issue, if available The estimated time to fix the issue What the issue is and how to solve it The tool that reported the issue and the related code pattern Filtering issues # Filter the list of issues to find specific issues, such as the issues with the highest severity or security issues. The list of code patterns with issues is always visible on the left side of the page. Click a code pattern to filter the list of issues by that pattern. You can moreover define one or more of the following filters: Language: Programming language of the file where the issues were detected Severity level: Potential impact of the issues: Critical (red): The most dangerous issues that you should prioritize fixing since they identify code that's susceptible to serious problems regarding security and compatibility Medium (yellow): You should check out these issues, as they're based on coding standards and conventions Minor (blue): The least critical issues, such as most code style issues Issue category: One of the following types of issue: Code style: Code formatting and syntax problems, such as variable names style and enforcing the use of brackets and quotation marks Error prone: Code that may hide bugs and language keywords that should be used with caution, such as the operator == in JavaScript or Option.get in Scala Code complexity: High complexity methods and classes that should be refactored Performance: Code that can have performance problems Compatibility: Mainly for frontend code, compatibility problems across different browser versions Unused code: Unused variables and methods, code that can't be reached Security: Potential security vulnerabilities, including hard-coded passwords and keys (secret scanning), vulnerable dependencies (software composition analysis or SCA), and insecure code patterns (static application security testing or SAST). For more information, see the complete list of security issue categories Documentation: Methods and classes that don't have the correct comment annotations Best practice: Code that doesn't follow the recommended coding standards and best practices Comprehensibility: Code that can be difficult to understand and modify Author: Commit author that introduced the issue on the code Note Each code pattern has a pre-defined severity level and at the moment Codacy doesn't support customizing that information. Ignoring and managing issues # Organization admins can manage access to this feature Use the options in the menu of each issue to: Ignore the issue and hide it from the list. Codacy will no longer report the issue after the next analysis of your repository. For example, you can ignore issues that you disagree with because: Your team won't tackle the issues in the immediate future The issue isn't relevant in the specific context of your code The issue is a false positive See how to restore ignored issues . Tip Organization admins can configure who is allowed to ignore issues . Disable the code pattern that detected the issue. Codacy will stop using that pattern after the next analysis of your repository, so be sure that you're no longer interested in identifying similar issues. To re-enable patterns use the Code patterns page . Note If you're using a custom configuration file , you must manage patterns manually on your configuration file. If your repository is following an organization coding standard , disabling the code pattern causes the repository to stop following the coding standard. In this case, Codacy asks for your confirmation before accepting the changes and then copies the coding standard configurations to your repository, so you can customize them. View the file where the issue was detected. Ignore the file where the issue was detected. Codacy will no longer analyze that file on your repository, so be sure that you're no longer interested in identifying any type of issues on that file. To remove an ignored file use the Ignored Files tab in your repository settings. Restoring ignored issues # To see the list of ignored issues, click the Ignored tab. To restore an ignored issue, select Unignore issue from the options menu: Fixing issues automatically # This section applies to GitHub repositories only If Codacy detects code patterns with suggested fixes, a Fix issues button appears above the issue list. In this case, Codacy generates a patch that enables you to solve all resolvable issues. To apply this patch to the default branch, do the following: Click the button Fix issues to open a modal with a patch that addresses all resolvable issues. Copy the patch content to the clipboard. Create a new branch from the default branch. Apply the patch from the repository's root directory, for example with the pbpaste | patch command. Note These changes are automatically generated. Review them to make sure they're correct. Push the new branch to the repository. On GitHub, create a pull request from the new branch to the default branch. See also # Which metrics does Codacy calculate? Using the Codacy API to obtain current issues in repositories", "title": "Quality Issues page"}, {"location": "repositories/issues/#quality-issues-page", "text": "The Quality Issues page lists all the issues that Codacy detected in your repository, including the severity level and category of each issue. By default, the page lists the issues on the main branch of your repository but if you have more than one branch enabled you can use the drop-down list at the top of the page to display issues on other branches. Note You can use the Codacy API to generate reports or obtain information about the current issues in your repositories in a more flexible way. Click the title of an issue card to expand it and see the following information: The committer and date of the commit that introduced the issue, if available The estimated time to fix the issue What the issue is and how to solve it The tool that reported the issue and the related code pattern", "title": "Quality Issues page"}, {"location": "repositories/issues/#filtering-issues", "text": "Filter the list of issues to find specific issues, such as the issues with the highest severity or security issues. The list of code patterns with issues is always visible on the left side of the page. Click a code pattern to filter the list of issues by that pattern. You can moreover define one or more of the following filters: Language: Programming language of the file where the issues were detected Severity level: Potential impact of the issues: Critical (red): The most dangerous issues that you should prioritize fixing since they identify code that's susceptible to serious problems regarding security and compatibility Medium (yellow): You should check out these issues, as they're based on coding standards and conventions Minor (blue): The least critical issues, such as most code style issues Issue category: One of the following types of issue: Code style: Code formatting and syntax problems, such as variable names style and enforcing the use of brackets and quotation marks Error prone: Code that may hide bugs and language keywords that should be used with caution, such as the operator == in JavaScript or Option.get in Scala Code complexity: High complexity methods and classes that should be refactored Performance: Code that can have performance problems Compatibility: Mainly for frontend code, compatibility problems across different browser versions Unused code: Unused variables and methods, code that can't be reached Security: Potential security vulnerabilities, including hard-coded passwords and keys (secret scanning), vulnerable dependencies (software composition analysis or SCA), and insecure code patterns (static application security testing or SAST). For more information, see the complete list of security issue categories Documentation: Methods and classes that don't have the correct comment annotations Best practice: Code that doesn't follow the recommended coding standards and best practices Comprehensibility: Code that can be difficult to understand and modify Author: Commit author that introduced the issue on the code Note Each code pattern has a pre-defined severity level and at the moment Codacy doesn't support customizing that information.", "title": "Filtering issues"}, {"location": "repositories/issues/#ignoring-and-managing-issues", "text": "Organization admins can manage access to this feature Use the options in the menu of each issue to: Ignore the issue and hide it from the list. Codacy will no longer report the issue after the next analysis of your repository. For example, you can ignore issues that you disagree with because: Your team won't tackle the issues in the immediate future The issue isn't relevant in the specific context of your code The issue is a false positive See how to restore ignored issues . Tip Organization admins can configure who is allowed to ignore issues . Disable the code pattern that detected the issue. Codacy will stop using that pattern after the next analysis of your repository, so be sure that you're no longer interested in identifying similar issues. To re-enable patterns use the Code patterns page . Note If you're using a custom configuration file , you must manage patterns manually on your configuration file. If your repository is following an organization coding standard , disabling the code pattern causes the repository to stop following the coding standard. In this case, Codacy asks for your confirmation before accepting the changes and then copies the coding standard configurations to your repository, so you can customize them. View the file where the issue was detected. Ignore the file where the issue was detected. Codacy will no longer analyze that file on your repository, so be sure that you're no longer interested in identifying any type of issues on that file. To remove an ignored file use the Ignored Files tab in your repository settings.", "title": "Ignoring and managing issues"}, {"location": "repositories/issues/#restoring-ignored-issues", "text": "To see the list of ignored issues, click the Ignored tab. To restore an ignored issue, select Unignore issue from the options menu:", "title": "Restoring ignored issues"}, {"location": "repositories/issues/#fixing-issues-automatically", "text": "This section applies to GitHub repositories only If Codacy detects code patterns with suggested fixes, a Fix issues button appears above the issue list. In this case, Codacy generates a patch that enables you to solve all resolvable issues. To apply this patch to the default branch, do the following: Click the button Fix issues to open a modal with a patch that addresses all resolvable issues. Copy the patch content to the clipboard. Create a new branch from the default branch. Apply the patch from the repository's root directory, for example with the pbpaste | patch command. Note These changes are automatically generated. Review them to make sure they're correct. Push the new branch to the repository. On GitHub, create a pull request from the new branch to the default branch.", "title": "Fixing issues automatically"}, {"location": "repositories/issues/#see-also", "text": "Which metrics does Codacy calculate? Using the Codacy API to obtain current issues in repositories", "title": "See also"}, {"location": "repositories/pull-requests/", "text": "Quality Pull Requests page # The Quality Pull Requests page displays an overview of the pull requests in your repository, such as the analysis status and the code quality metrics for each pull request. This allows you to monitor the code quality of the work in progress in your repository. By default, the page lists open pull requests, but you can click the Closed tab at the top of the list to display the closed pull requests. Click a specific pull request to see detailed information about the code quality changes introduced by that pull request. The next sections describe each area of the pull request detail page. Pull request status # This area displays the information that identifies the pull request (name, author, head and base branches, and last updated date), as well as: A link to the pull request on your Git provider A link to reanalyze the latest pull request commit , present when the committer is part of your organization A link to view analysis logs Pull request quality overview # This area displays the quality gate status for the pull request and the code quality metrics with a gate set up : The quality gate status is either Up to quality standards or Not up to quality standards depending on the quality gate rules for your repository. If there are no gate rules enabled for pull requests, the status is always Up to quality standards . The variation introduced by the pull request is displayed either as a positive or negative variation , no variation (represented by = ), or not applicable (represented by \u2205 ) for code quality metrics with a gate set up : Issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Diff coverage: Code coverage of the coverable lines affected by the pull request, or \u2205 (not applicable) if there are no coverable lines Coverage variation: Changes in code coverage percentage compared with the target branch Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ). Note Learn how Codacy calculates the code quality metrics in more detail: Which code quality metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the quality gate rules for your repository: Green: The metric passes the quality gate Red: The metric fails the quality gate Gray: The metric has no value Note If you change the quality gate rules you must reanalyze the pull request to update the metrics and optionally re-upload the Coverage report if you also changed the coverage gate rules. Issues tab # The Issues tab displays the lists of issues that the pull request creates or fixes. Use the sidebar filters to filter the list by new issues (including issues of specific severity or category), issues within a specific file, fixed issues, potential new issues, or potential fixed issues . Click the title of an issue card to expand it and see the following information: The committer and date of the commit that introduced the issue, if available The estimated time to fix the issue What the issue is and how to solve it The tool that reported the issue and the related code pattern To ignore or manage an issue , click the associated options in the menu. Potential issues # Codacy may label some issues as potential , which means that the code analysis detected these issues in lines of code that weren't changed by the analyzed pull request. This highlights potential consequences in other parts of your codebase. The following are example situations that can lead to potential issues: The issue was either created or fixed in the current pull request, but the static code analysis tools reported the issue on a line that didn't change in the pull request. For example, if you remove the line containing the declaration of a variable you may get an \"undeclared variable\" issue in other lines that use that variable. If a file had more than 50 issues reported by the same tool and you push a new commit that fixes some of these issues, Codacy will report more issues until the limit of 50 issues. These issues will be potential issues if they're outside the lines of code changed in the new commit. Note If you're using GitHub you may see annotations for potential issues reported under Unchanged files with check annotations on the Files changed tab of your pull requests. This happens when Codacy reports potential issues in files that weren't changed in your pull request. Read more about this GitHub feature . Duplication tab # The Duplication tab displays the lists of clones (duplicated code blocks) that the pull request adds or fixes. You can click a clone to expand it and inspect the code. Complexity tab # The Complexity tab displays the complexity changes introduced by the pull request. Use the sidebar filters to filter the list by high increase (4 or more), low increase (1 to 3), or improvement (less than 0). Note When calculating the complexity variation introduced by a pull request, Codacy only considers files with a high increase in complexity. For more information, see how Codacy calculates cyclomatic complexity . Coverage tab # The Coverage tab displays a line-by-line view of the coverage variation introduced by the pull request. It includes the following areas: A list of files modified by the pull request, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the pull request The coverage variation introduced by the pull request (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line Diff tab # The Diff tab displays the code changes and issues introduced by the pull request. It includes the following areas: A list of files modified by the pull request, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the pull request The number of new issues introduced by the pull request A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. Lines with issues are highlighted according to issue severity and include a pill label with the issue type and count. Hover over the pill label to view more details or navigate to the issues. Files tab # The Files tab displays the variation of the following code quality metrics that the pull request introduces to the files in your repository, displayed either as a positive or negative variation , or no variation (represented by = ): New issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Coverage variation: Changes in code coverage percentage compared with the target branch Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ). Commits tab # The Commits tab displays an overview of each commit included in the pull request, such as the analysis status and the number of issues introduced. Click a specific commit to see detailed information about that commit . Viewing analysis logs # Analysis logs can help you track and understand the performance of the tools and the timing of analyses on your pull requests. To access these logs, click the View logs link in the pull request status area. This opens a modal with two tabs: The Quality tab displays execution times and outcomes for the tools used to analyze the latest commit of the pull request. It helps identify the duration of each analysis phase and any potential issues. The Coverage tab lists reports received for the common ancestor commit and the head commit of the pull request. It helps you spot any issues with the coverage analysis, such as missing coverage reports. Fixing issues automatically # This section applies to GitHub repositories only If Codacy detects code patterns with suggested fixes, a Fix issues button appears above the issue list. In this case, Codacy generates a patch that enables you to solve all resolvable issues. To apply this patch to the pull request, do the following: Click the button Fix issues to open a modal with a patch that addresses all resolvable issues. Copy the patch content to the clipboard. Check out the relevant branch in the local repository. Apply the patch from the repository's root directory, for example with the pbpaste | patch command. Note These changes are automatically generated. Review them to make sure they're correct. Push the changes to the repository. See also # Which metrics does Codacy calculate?", "title": "Quality Pull Requests page"}, {"location": "repositories/pull-requests/#quality-pull-requests-page", "text": "The Quality Pull Requests page displays an overview of the pull requests in your repository, such as the analysis status and the code quality metrics for each pull request. This allows you to monitor the code quality of the work in progress in your repository. By default, the page lists open pull requests, but you can click the Closed tab at the top of the list to display the closed pull requests. Click a specific pull request to see detailed information about the code quality changes introduced by that pull request. The next sections describe each area of the pull request detail page.", "title": "Quality Pull Requests page"}, {"location": "repositories/pull-requests/#status", "text": "This area displays the information that identifies the pull request (name, author, head and base branches, and last updated date), as well as: A link to the pull request on your Git provider A link to reanalyze the latest pull request commit , present when the committer is part of your organization A link to view analysis logs", "title": "Pull request status"}, {"location": "repositories/pull-requests/#quality-overview", "text": "This area displays the quality gate status for the pull request and the code quality metrics with a gate set up : The quality gate status is either Up to quality standards or Not up to quality standards depending on the quality gate rules for your repository. If there are no gate rules enabled for pull requests, the status is always Up to quality standards . The variation introduced by the pull request is displayed either as a positive or negative variation , no variation (represented by = ), or not applicable (represented by \u2205 ) for code quality metrics with a gate set up : Issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Diff coverage: Code coverage of the coverable lines affected by the pull request, or \u2205 (not applicable) if there are no coverable lines Coverage variation: Changes in code coverage percentage compared with the target branch Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ). Note Learn how Codacy calculates the code quality metrics in more detail: Which code quality metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the quality gate rules for your repository: Green: The metric passes the quality gate Red: The metric fails the quality gate Gray: The metric has no value Note If you change the quality gate rules you must reanalyze the pull request to update the metrics and optionally re-upload the Coverage report if you also changed the coverage gate rules.", "title": "Pull request quality overview"}, {"location": "repositories/pull-requests/#issues-tabs", "text": "The Issues tab displays the lists of issues that the pull request creates or fixes. Use the sidebar filters to filter the list by new issues (including issues of specific severity or category), issues within a specific file, fixed issues, potential new issues, or potential fixed issues . Click the title of an issue card to expand it and see the following information: The committer and date of the commit that introduced the issue, if available The estimated time to fix the issue What the issue is and how to solve it The tool that reported the issue and the related code pattern To ignore or manage an issue , click the associated options in the menu.", "title": "Issues tab"}, {"location": "repositories/pull-requests/#duplication-tabs", "text": "The Duplication tab displays the lists of clones (duplicated code blocks) that the pull request adds or fixes. You can click a clone to expand it and inspect the code.", "title": "Duplication tab"}, {"location": "repositories/pull-requests/#complexity-tab", "text": "The Complexity tab displays the complexity changes introduced by the pull request. Use the sidebar filters to filter the list by high increase (4 or more), low increase (1 to 3), or improvement (less than 0). Note When calculating the complexity variation introduced by a pull request, Codacy only considers files with a high increase in complexity. For more information, see how Codacy calculates cyclomatic complexity .", "title": "Complexity tab"}, {"location": "repositories/pull-requests/#coverage-tab", "text": "The Coverage tab displays a line-by-line view of the coverage variation introduced by the pull request. It includes the following areas: A list of files modified by the pull request, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the pull request The coverage variation introduced by the pull request (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line", "title": "Coverage tab"}, {"location": "repositories/pull-requests/#diff-tab", "text": "The Diff tab displays the code changes and issues introduced by the pull request. It includes the following areas: A list of files modified by the pull request, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the pull request The number of new issues introduced by the pull request A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. Lines with issues are highlighted according to issue severity and include a pill label with the issue type and count. Hover over the pill label to view more details or navigate to the issues.", "title": "Diff tab"}, {"location": "repositories/pull-requests/#files-tab", "text": "The Files tab displays the variation of the following code quality metrics that the pull request introduces to the files in your repository, displayed either as a positive or negative variation , or no variation (represented by = ): New issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Coverage variation: Changes in code coverage percentage compared with the target branch Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ).", "title": "Files tab"}, {"location": "repositories/pull-requests/#commits-tab", "text": "The Commits tab displays an overview of each commit included in the pull request, such as the analysis status and the number of issues introduced. Click a specific commit to see detailed information about that commit .", "title": "Commits tab"}, {"location": "repositories/pull-requests/#viewing-analysis-logs", "text": "Analysis logs can help you track and understand the performance of the tools and the timing of analyses on your pull requests. To access these logs, click the View logs link in the pull request status area. This opens a modal with two tabs: The Quality tab displays execution times and outcomes for the tools used to analyze the latest commit of the pull request. It helps identify the duration of each analysis phase and any potential issues. The Coverage tab lists reports received for the common ancestor commit and the head commit of the pull request. It helps you spot any issues with the coverage analysis, such as missing coverage reports.", "title": "Viewing analysis logs"}, {"location": "repositories/pull-requests/#fixing-issues-automatically", "text": "This section applies to GitHub repositories only If Codacy detects code patterns with suggested fixes, a Fix issues button appears above the issue list. In this case, Codacy generates a patch that enables you to solve all resolvable issues. To apply this patch to the pull request, do the following: Click the button Fix issues to open a modal with a patch that addresses all resolvable issues. Copy the patch content to the clipboard. Check out the relevant branch in the local repository. Apply the patch from the repository's root directory, for example with the pbpaste | patch command. Note These changes are automatically generated. Review them to make sure they're correct. Push the changes to the repository.", "title": "Fixing issues automatically"}, {"location": "repositories/pull-requests/#see-also", "text": "Which metrics does Codacy calculate?", "title": "See also"}, {"location": "repositories/repository-dashboard/", "text": "Quality Repository Dashboard # The Quality Repository Dashboard provides an overview of the repository code quality and items that require your attention. To access your Repository Dashboard, select a repository from the Repositories list and select Dashboard on the left navigation sidebar. Tip You can share the URL of the Repository Dashboard for your public repositories to allow other people to see your repository code quality metrics, even if they aren't registered on Codacy. The top of the Repository Dashboard displays: The name and code quality grade of the repository A drop-down list that selects which branch of your repository to display on the dashboard On the Repository Dashboard you have the following areas to help you monitor your repository: Quality evolution chart Issues breakdown Coverage Open pull requests The following sections provide a detailed overview of each dashboard area. Note You can use the Codacy API to generate reports or obtain information about the code quality of your repositories in a more flexible way. For more information see the list of available API endpoints and the following examples: Obtaining current issues in repositories Obtaining code quality metrics for files Quality evolution chart # The Quality evolution chart displays the evolution of the repository code quality regarding issues , complex files , duplication , and code coverage . Click on Last 3 months , Last 31 days , or Last 7 days to select the time interval of the historical data to display on the chart. Each tab displays the following information for the corresponding metric: A green or red indicator depending if the metric is within the acceptable quality level or not The current value The variation of the value introduced by the last commit Note The coverage tab only displays a value if Codacy received coverage data for the most recent commit. This is because one commit can easily change the size or number of files on the repository, or even remove some files that had coverage information. The chart also displays the trendline based on the past behavior and the quality goals defined for the repository. Issues breakdown # The Issues breakdown area displays the total number of issues found on the selected branch, as well as the distribution of issues across each code quality issue category. Click See all issues to see the full list of issues found, or click a category to see the issues in that category. If Codacy detects code patterns that have suggested fixes, a Fix issues button appears below the total issue count. Click this button to open a modal with a patch that addresses all resolvable issues, and follow the same procedure outlined on the Quality Issues page . Coverage # The Coverage area displays the percentage of lines of code on the selected branch that are covered by tests versus the coverage goal defined in the quality settings of the repository, as well as the number of files: Without coverage With coverage not up to standards (based on the coverage goal) With coverage up to standards (based on the coverage goal) Click See all files to open the list of files in the repository. Tip If you don't have coverage set up for your repository yet, the Coverage area provides you with instructions on how to add coverage for your repository . Open pull requests # The Open pull requests area displays the last updated pull requests and the split between the status of all open pull requests in your repository: Up to standards: Pull requests that meet the minimum quality levels Not up to standards: Pull requests that failed to meet at least one of the quality gate rules defined for the repository Analyzing: Pull requests currently being analyzed by Codacy Click a bar segment to display only pull requests with the corresponding status. To see the details of pull requests, click a pull request from the list or click See all pull requests to open the list of pull requests in the repository. See also # Which metrics does Codacy calculate? Using the Codacy API to obtain current issues in repositories Using the Codacy API to obtain code quality metrics for files", "title": "Quality Repository Dashboard"}, {"location": "repositories/repository-dashboard/#quality-repository-dashboard", "text": "The Quality Repository Dashboard provides an overview of the repository code quality and items that require your attention. To access your Repository Dashboard, select a repository from the Repositories list and select Dashboard on the left navigation sidebar. Tip You can share the URL of the Repository Dashboard for your public repositories to allow other people to see your repository code quality metrics, even if they aren't registered on Codacy. The top of the Repository Dashboard displays: The name and code quality grade of the repository A drop-down list that selects which branch of your repository to display on the dashboard On the Repository Dashboard you have the following areas to help you monitor your repository: Quality evolution chart Issues breakdown Coverage Open pull requests The following sections provide a detailed overview of each dashboard area. Note You can use the Codacy API to generate reports or obtain information about the code quality of your repositories in a more flexible way. For more information see the list of available API endpoints and the following examples: Obtaining current issues in repositories Obtaining code quality metrics for files", "title": "Quality Repository Dashboard"}, {"location": "repositories/repository-dashboard/#quality-evolution-chart", "text": "The Quality evolution chart displays the evolution of the repository code quality regarding issues , complex files , duplication , and code coverage . Click on Last 3 months , Last 31 days , or Last 7 days to select the time interval of the historical data to display on the chart. Each tab displays the following information for the corresponding metric: A green or red indicator depending if the metric is within the acceptable quality level or not The current value The variation of the value introduced by the last commit Note The coverage tab only displays a value if Codacy received coverage data for the most recent commit. This is because one commit can easily change the size or number of files on the repository, or even remove some files that had coverage information. The chart also displays the trendline based on the past behavior and the quality goals defined for the repository.", "title": "Quality evolution chart"}, {"location": "repositories/repository-dashboard/#issues-breakdown", "text": "The Issues breakdown area displays the total number of issues found on the selected branch, as well as the distribution of issues across each code quality issue category. Click See all issues to see the full list of issues found, or click a category to see the issues in that category. If Codacy detects code patterns that have suggested fixes, a Fix issues button appears below the total issue count. Click this button to open a modal with a patch that addresses all resolvable issues, and follow the same procedure outlined on the Quality Issues page .", "title": "Issues breakdown"}, {"location": "repositories/repository-dashboard/#coverage", "text": "The Coverage area displays the percentage of lines of code on the selected branch that are covered by tests versus the coverage goal defined in the quality settings of the repository, as well as the number of files: Without coverage With coverage not up to standards (based on the coverage goal) With coverage up to standards (based on the coverage goal) Click See all files to open the list of files in the repository. Tip If you don't have coverage set up for your repository yet, the Coverage area provides you with instructions on how to add coverage for your repository .", "title": "Coverage"}, {"location": "repositories/repository-dashboard/#open-pull-requests", "text": "The Open pull requests area displays the last updated pull requests and the split between the status of all open pull requests in your repository: Up to standards: Pull requests that meet the minimum quality levels Not up to standards: Pull requests that failed to meet at least one of the quality gate rules defined for the repository Analyzing: Pull requests currently being analyzed by Codacy Click a bar segment to display only pull requests with the corresponding status. To see the details of pull requests, click a pull request from the list or click See all pull requests to open the list of pull requests in the repository.", "title": "Open pull requests"}, {"location": "repositories/repository-dashboard/#see-also", "text": "Which metrics does Codacy calculate? Using the Codacy API to obtain current issues in repositories Using the Codacy API to obtain code quality metrics for files", "title": "See also"}, {"location": "repositories-configure/adjusting-quality-gates/", "text": "Adjusting quality gates # The quality gates of your repository configure when Codacy reports your pull requests and commits as not up to standards. When you add your repository to Codacy, it automatically follows the default gate policy for your organization . If you want to set different quality gates for the repository, create a new organization gate policy to apply to the repository. Note Although you can define custom quality gate settings for specific repositories, we recommend that you always use a gate policy defined by your organization to enforce consistent rules across multiple repositories. Depending on the result of applying the quality gate rules, Codacy updates the color of the metrics on the pull request or commit quality overview and reports the corresponding pull request status on your Git provider, if enabled. Tip Integrate Codacy with your Git workflow to report the pull request status to your Git provider and optionally block merging pull requests that aren't up to standards. To access the quality gates, open your repository Settings , tab Gates . New issues are over: Pull requests or commits are marked not up to standards if the number of issues introduced that have at least the specified severity level is higher than the set value. New security issues are over: Pull requests or commits are marked not up to standards if the number of security issues introduced is higher than the set value. Complexity is over: Pull requests or commits are marked not up to standards if the introduced complexity is higher than the set value. Duplication is over: Pull requests or commits are marked not up to standards if the number of clones introduced is higher than the set value. Coverage variation is under: Pull requests or commits are marked not up to standards if they introduce a variation to coverage lower than the set value. Tip Set this gate to -0.10% or lower. This will ensure that developers have a coverage drop margin so they aren't blocked while performing some types of code refactors To ensure that the changes in each pull request have a minimum level of coverage, use the gate Diff coverage is under instead. Diff coverage is under: Pull requests are marked not up to standards if the diff coverage of the pull request is lower than the set value or \u2205 ( not applicable ). This rule is only available for pull requests. See also # Which metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? Integrating Codacy with your Git workflow", "title": "Adjusting quality gates"}, {"location": "repositories-configure/adjusting-quality-gates/#adjusting-quality-gates", "text": "The quality gates of your repository configure when Codacy reports your pull requests and commits as not up to standards. When you add your repository to Codacy, it automatically follows the default gate policy for your organization . If you want to set different quality gates for the repository, create a new organization gate policy to apply to the repository. Note Although you can define custom quality gate settings for specific repositories, we recommend that you always use a gate policy defined by your organization to enforce consistent rules across multiple repositories. Depending on the result of applying the quality gate rules, Codacy updates the color of the metrics on the pull request or commit quality overview and reports the corresponding pull request status on your Git provider, if enabled. Tip Integrate Codacy with your Git workflow to report the pull request status to your Git provider and optionally block merging pull requests that aren't up to standards. To access the quality gates, open your repository Settings , tab Gates . New issues are over: Pull requests or commits are marked not up to standards if the number of issues introduced that have at least the specified severity level is higher than the set value. New security issues are over: Pull requests or commits are marked not up to standards if the number of security issues introduced is higher than the set value. Complexity is over: Pull requests or commits are marked not up to standards if the introduced complexity is higher than the set value. Duplication is over: Pull requests or commits are marked not up to standards if the number of clones introduced is higher than the set value. Coverage variation is under: Pull requests or commits are marked not up to standards if they introduce a variation to coverage lower than the set value. Tip Set this gate to -0.10% or lower. This will ensure that developers have a coverage drop margin so they aren't blocked while performing some types of code refactors To ensure that the changes in each pull request have a minimum level of coverage, use the gate Diff coverage is under instead. Diff coverage is under: Pull requests are marked not up to standards if the diff coverage of the pull request is lower than the set value or \u2205 ( not applicable ). This rule is only available for pull requests.", "title": "Adjusting quality gates"}, {"location": "repositories-configure/adjusting-quality-gates/#see-also", "text": "Which metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? Integrating Codacy with your Git workflow", "title": "See also"}, {"location": "repositories-configure/adjusting-quality-goals/", "text": "Adjusting quality goals # Adjust the quality goals to help you monitor the progress of the code quality in your repository dashboard, and configure which files Codacy considers complex or duplicated. Codacy displays the quality goals as dashed lines on the quality evolution chart to help you monitor the progress and overall quality status of your repository. To access the quality goals, open your repository Settings , tab Goals . The following screenshot displays the default configuration values: Issues are over: Defines the threshold displayed on the tab Issues of the quality evolution chart. Complexity is over: Defines the threshold displayed on the tab Complexity of the quality evolution chart. File is complex when over: A file is considered complex when its complexity is over this value. Duplication is over: Defines the threshold displayed on the tab Duplication of the quality evolution chart. File is duplicate when over: A file is considered duplicated when it has more clones than this value. Coverage is under: Defines the threshold displayed on the tab Coverage of the quality evolution chart. See also # Which metrics does Codacy calculate?", "title": "Adjusting quality goals"}, {"location": "repositories-configure/adjusting-quality-goals/#adjusting-quality-goals", "text": "Adjust the quality goals to help you monitor the progress of the code quality in your repository dashboard, and configure which files Codacy considers complex or duplicated. Codacy displays the quality goals as dashed lines on the quality evolution chart to help you monitor the progress and overall quality status of your repository. To access the quality goals, open your repository Settings , tab Goals . The following screenshot displays the default configuration values: Issues are over: Defines the threshold displayed on the tab Issues of the quality evolution chart. Complexity is over: Defines the threshold displayed on the tab Complexity of the quality evolution chart. File is complex when over: A file is considered complex when its complexity is over this value. Duplication is over: Defines the threshold displayed on the tab Duplication of the quality evolution chart. File is duplicate when over: A file is considered duplicated when it has more clones than this value. Coverage is under: Defines the threshold displayed on the tab Coverage of the quality evolution chart.", "title": "Adjusting quality goals"}, {"location": "repositories-configure/adjusting-quality-goals/#see-also", "text": "Which metrics does Codacy calculate?", "title": "See also"}, {"location": "repositories-configure/codacy-configuration-file/", "text": "Codacy configuration file # Codacy supports configuring certain advanced features through a configuration file, such as: Ignoring files globally, for duplication, or a specific tool Including specific ignored files in the analysis Adjusting tool-specific configurations Configuring a specific repository directory on which to start the analysis Configuring the languages that Codacy analyzes in your repository: Adding custom file extensions to languages Disabling the analysis of a specific language Using a Codacy configuration file # Important If your repository has a Codacy configuration file, the Ignored files settings defined on the Codacy UI don't apply and you must ignore files using the configuration file instead. Codacy always uses the configuration file in the default branch . New settings added to the Codacy configuration file by a pull request are also considered for the pull request analysis, but the existing configuration in the default branch takes precedence. For example, if a pull request removes an ignored path from the Codacy configuration file, any matching files will stay ignored until that pull request is merged into the default branch. To use a Codacy configuration file: Create a text file with the name .codacy.yml or .codacy.yaml on the root of your repository. The file must start with a line containing a triple dash ( --- ). Add your settings to the configuration file based on the example template below. If you defined any Ignored files settings for the repository, make sure you add those settings to the Codacy configuration file. --- engines : rubocop : exclude_paths : - \"config/test.yml\" base_sub_dir : \"test/baseDir\" duplication : exclude_paths : - \"config/test.yml\" config : languages : - \"ruby\" languages : css : extensions : - \".scss\" python : enabled : false exclude_paths : - \".bundle/**\" - \"spec/**/*\" - \"benchmarks/**/*\" - \"**.min.js\" - \"**/tests/**\" include_paths : - \"**/tests/integration/**\" Optionally, validate the syntax of your configuration file with the Codacy Analysis CLI by running the following command in the same folder as the Codacy configuration file: codacy-analysis-cli validate-configuration --directory ` pwd ` Ignoring files using a Codacy configuration file # The Codacy configuration file gives you more flexibility in ignoring or excluding files from the Codacy analysis. Note To exclude files from coverage analysis only, you must ignore them directly in the tool you're using to generate coverage reports and ensure that the reports you upload to Codacy don't include coverage information for those files. Syntax for ignoring files # To ignore files using a Codacy configuration file, you must define one or more patterns under exclude_paths using the Java glob syntax : Example pattern Ignored files test/README.md The file test/README.md test/* All files in the root of test test/** All files and directories inside test test/**/* All files inside sub-directories of test **.resource All .resource files across all your repository **/*.resource All .resource files in all directories and sub-directories For example: --- exclude_paths : - \"test/README.md\" - \"**/*.resource\" Including specific files using a Codacy configuration file # The Codacy configuration file allows you to explicitly specify files or directories to include in the analysis. This is particularly useful for bypassing files or directories that are ignored by default or specified in exclude_paths . Note If both exclude_paths and include_paths are defined, include_paths will specify exceptions to the exclusions defined in exclude_paths . Syntax for including files # To include specific files using a Codacy configuration file, you must define one or more patterns under include_paths using the same syntax as exclude_paths . For example: --- exclude_paths : - \"lib*/**\" include_paths : - \"lib-a/**\" - \"libs/**\" In this example, while all directories matching lib* are excluded, lib-a is specifically included for analysis, as well as any files within libs . Adjusting tool configurations # Note The Codacy configuration file lets you configure tools , but you can't enable or disable them. A tool can only be enabled or disabled on the Code patterns page by users with the necessary permissions . Which tools can be configured and which name should I use? # You can use the Codacy configuration file to configure all tools supported by Codacy except the client-side tools . The following are the tool names that must be used in the Codacy configuration file: ameba bandit brakeman checkov checkstyle codacy-scalameta-pro codenarc coffeelint cppcheck credo dartanalyzer detekt eslint-8 flawfinder hadolint jacksonlinter markdownlint phpcs phpmd pmd prospector psscriptanalyzer pylintpython3 remark-lint revive rubocop scalastyle semgrep shellcheck sonarcsharp sonarvb spectral SQLint stylelint swiftlint trivy tsqllint The following names are deprecated and shouldn't be used, although they're still accepted in the Codacy configuration file: bundleraudit - The tool bundler-audit is deprecated . If you are using Semprep or Trivy instead, use the names trivy or semgrep . csslint - The tool CSSLint is deprecated . If you are using Stylelint instead, use the name stylelint . eslint - Use the name eslint-8 for ESLint . jshint , tslint - The tools JSHint and TSLint are deprecated . If you are using ESLint instead, use the name eslint-8 . pylint - Use the name pylintpython3 for Pylint . tailor - The tool Tailor is deprecated . If you are using SwiftLint instead, use the name swiftlint . Tool-specific configurations # By default, Codacy tries to detect which language is used on each source code file, and uses a set of default options for identifying duplicate blocks of code. However, some false positives may occur. The tools below support specifying the language or language version used in the source code files that you're analyzing, or tuning the duplication detection. Cppcheck # If you're using Cppcheck to analyze C or C++ source code files, add the following configuration to your Codacy configuration file to define the programming language you're using. The supported languages are c and c++ : --- engines : cppcheck : language : c++ PHP_CodeSniffer # If you're using the PHP Compatibility coding standard for PHP_CodeSniffer, add the following configuration to your Codacy configuration file to define the PHP version you're using: --- engines : phpcs : php_version : 5.5 Legacy Pylint 1.9.* # If you're using the legacy Pylint 1.9.* to analyze Python source code files, add the following configuration to your Codacy configuration file to define the Python language version you're using. The supported versions are 2 and 3 : --- engines : pylint : python_version : 2 Tip If you're using Python 3.4.* or later as your programming language, disable the tool Pylint (legacy) and enable the tool Pylint on your repository Code patterns page instead. For more information, see What's New in Pylint 2.0 . PMD CPD (Duplication) # Codacy uses PMD's Copy/Paste Detector (CPD) to identify duplicated blocks of code on the supported languages . By default, Codacy only reports duplicate code blocks that have the following minimum token length, depending on the language: Language Default minimum token length C# 50 C/C++ 50 Go 40 Java 100 JavaScript 40 Python 50 Ruby 50 SQL 100 Scala 50 Swift 50 Besides this, Codacy runs PMD CPD with the following options enabled by default: Skip lexical errors: Skip files which can't be tokenized due to invalid characters instead of aborting CPD Ignore literals: Ignore number values and string contents when comparing text Ignore annotations: Ignore language annotations when comparing text Ignore usings : Ignore using directives in C# when comparing text To use a different minimum token length or change any of the default options, add your settings to the Codacy configuration file based on the example template below. Important If you configure minTokenMatch on the Codacy configuration file, Codacy will use that value for all languages. --- engines : duplication : minTokenMatch : 20 skipLexicalErrors : false ignoreLiterals : false ignoreIdentifiers : true ignoreAnnotations : false ignoreUsings : false Configuring languages using a Codacy configuration file # You can use a Codacy configuration file to manage the languages that Codacy analyzes in your repository. Note Codacy applies the language settings from the Codacy configuration file as well as any settings defined in the Codacy UI . Adding custom file extensions # To add custom file extensions to languages using a Codacy configuration file, you must define one or more extensions under languages..extensions . Keep in mind that some tools might not work out of the box with those extensions. For example: --- languages : css : extensions : - \".scss\" Disabling analysis of a language # To disable the analysis of a specific language using a Codacy configuration file, set languages..enabled to false . The analysis is enabled by default for all languages. For example: --- languages : css : enabled : false", "title": "Codacy configuration file"}, {"location": "repositories-configure/codacy-configuration-file/#codacy-configuration-file", "text": "Codacy supports configuring certain advanced features through a configuration file, such as: Ignoring files globally, for duplication, or a specific tool Including specific ignored files in the analysis Adjusting tool-specific configurations Configuring a specific repository directory on which to start the analysis Configuring the languages that Codacy analyzes in your repository: Adding custom file extensions to languages Disabling the analysis of a specific language", "title": "Codacy configuration file"}, {"location": "repositories-configure/codacy-configuration-file/#using-a-codacy-configuration-file", "text": "Important If your repository has a Codacy configuration file, the Ignored files settings defined on the Codacy UI don't apply and you must ignore files using the configuration file instead. Codacy always uses the configuration file in the default branch . New settings added to the Codacy configuration file by a pull request are also considered for the pull request analysis, but the existing configuration in the default branch takes precedence. For example, if a pull request removes an ignored path from the Codacy configuration file, any matching files will stay ignored until that pull request is merged into the default branch. To use a Codacy configuration file: Create a text file with the name .codacy.yml or .codacy.yaml on the root of your repository. The file must start with a line containing a triple dash ( --- ). Add your settings to the configuration file based on the example template below. If you defined any Ignored files settings for the repository, make sure you add those settings to the Codacy configuration file. --- engines : rubocop : exclude_paths : - \"config/test.yml\" base_sub_dir : \"test/baseDir\" duplication : exclude_paths : - \"config/test.yml\" config : languages : - \"ruby\" languages : css : extensions : - \".scss\" python : enabled : false exclude_paths : - \".bundle/**\" - \"spec/**/*\" - \"benchmarks/**/*\" - \"**.min.js\" - \"**/tests/**\" include_paths : - \"**/tests/integration/**\" Optionally, validate the syntax of your configuration file with the Codacy Analysis CLI by running the following command in the same folder as the Codacy configuration file: codacy-analysis-cli validate-configuration --directory ` pwd `", "title": "Using a Codacy configuration file"}, {"location": "repositories-configure/codacy-configuration-file/#ignore-files", "text": "The Codacy configuration file gives you more flexibility in ignoring or excluding files from the Codacy analysis. Note To exclude files from coverage analysis only, you must ignore them directly in the tool you're using to generate coverage reports and ensure that the reports you upload to Codacy don't include coverage information for those files.", "title": "Ignoring files using a Codacy configuration file"}, {"location": "repositories-configure/codacy-configuration-file/#include-files", "text": "The Codacy configuration file allows you to explicitly specify files or directories to include in the analysis. This is particularly useful for bypassing files or directories that are ignored by default or specified in exclude_paths . Note If both exclude_paths and include_paths are defined, include_paths will specify exceptions to the exclusions defined in exclude_paths .", "title": "Including specific files using a Codacy configuration file"}, {"location": "repositories-configure/codacy-configuration-file/#tool-conf", "text": "Note The Codacy configuration file lets you configure tools , but you can't enable or disable them. A tool can only be enabled or disabled on the Code patterns page by users with the necessary permissions .", "title": "Adjusting tool configurations"}, {"location": "repositories-configure/codacy-configuration-file/#languages", "text": "You can use a Codacy configuration file to manage the languages that Codacy analyzes in your repository. Note Codacy applies the language settings from the Codacy configuration file as well as any settings defined in the Codacy UI .", "title": "Configuring languages using a Codacy configuration file"}, {"location": "repositories-configure/configuring-code-patterns/", "text": "Configuring code patterns # Organization admins can manage access to this feature By default, Codacy analyzes your repositories using a subset of the supported analysis tools and code patterns. These defaults are based on current best practices and community feedback, and you can adapt them to your needs as follows: Configuring tools and code patterns using the Codacy UI Using tool configuration files Configuring tools and code patterns using the Codacy UI # To configure the tools and code patterns for a repository using the Codacy UI: Open your repository Code patterns page. Enable or disable the tools that Codacy will use to analyze the repository. Select a tool to enable or disable its code patterns. To make it easier to find relevant patterns, use the filters above the pattern list. You can filter by issue category , status, severity level, or display only recommended code patterns. To see an explanation of the issues that a pattern detects and how to fix them, click the respective dropdown arrow. Tip To enable a group of code patterns, use the filter to select the relevant group of patterns and click the checkbox in the header of the patterns list. Codacy displays the tag New for one month next to the name of newly added code patterns. Optionally, to take the changes into account immediately, reanalyze the repository manually . Otherwise, Codacy will use the updated configuration when analyzing new commits and pull requests. Detaching a coding standard from a repository # If the repository is following a coding standard, a notice is displayed. To detach the coding standard from the repository, click Detach repository and confirm. Using tool configuration files # Note After activating a configuration file for a tool, Codacy uses that configuration file even if you exclude it from Codacy analysis . When using a tool configuration file alongside a coding standard , the configuration file controls the code patterns, while the coding standard controls whether the tool is enabled or disabled. Codacy supports configuration files for several static analysis tools to help you streamline your setup. To use a configuration file for a static analysis tool: Push the configuration file to the root of the default Codacy branch . Open the repository Code patterns page, select the tool of interest, and activate the toggle to use a configuration file. Note Codacy uses the version of the configuration file in the branch being analyzed . For example, if you open a pull request that includes changes to the configuration file, the analysis results take those changes into account. If Codacy analyzes a branch that doesn't include the configuration file, Codacy reverts to using the code patterns configured for the tool before you selected the option Configuration file on the Code patterns page. For performance reasons, when you update pattern settings using a configuration file, Codacy may display outdated messages for issues identified previously by those patterns. The table below lists the configuration file names that Codacy detects and supports for each tool: Tool name Languages Files detected Other info Ameba Crystal .ameba.yml Bandit Python bandit.yml , bandit.yaml , .bandit , bandit.toml , bandit.ini To solve flagged valid Python \"assert\" statements, create a bandit.yml on the root of the repository containing: skips: \\['B101'\\] Brakeman Ruby config/brakeman.yml Checkstyle Java checkstyle.xml Supports configuration file in directories other than root and can search up to 5 directories into the repository. CodeNarc Groovy .codenarcrc Credo Elixir .credo.exs , config/.credo.exs dartanalyzer Dart analysis_options.yml Customizing static analysis detekt Kotlin default-detekt-config.yml , detekt.yml Supports configuration file in directories other than root and can search up to 5 directories into the repository. ESLint JavaScript, TypeScript .eslintrc.js , .eslintrc.cjs , .eslintrc.yaml , .eslintrc.yml , .eslintrc.json Plugins configurable on the Codacy UI Other supported plugins If you're using module-level ESLint configuration files , you must also include a ESLint configuration file on the root of your repository for Codacy to detect that you're using configuration files. For example, add the following minimal .eslintrc.json configuration file: { \"root\": true } Hadolint Dockerfile .hadolint.yaml markdownlint Markdown .markdownlint.json PHP_CodeSniffer PHP phpcs.xml , phpcs.xml.dist PHP Mess Detector PHP codesize.xml , phpmd.xml , phpmd.xml.dist PMD Apex, Java, JavaScript, JSP, PL/SQL, XML, Velocity and Visualforce ruleset.xml , apex-ruleset.xml Supports configuration file in directories other than root and can search up to 5 directories into the repository. Prospector Python .prospector.yml , .prospector.yaml , prospector.yml , prospector.yaml , .landscape.yml , .landscape.yaml , landscape.yml , landscape.yaml Pylint Python pylintrc , .pylintrc Plugins remark-lint Markdown .remarkrc , .remarkrc.json , .remarkrc.yaml , .remarkrc.yml , .remarkrc.js Revive Go revive.toml RuboCop Ruby .rubocop.yml , .rubocop-codacy.yml Supports alternative configuration file .rubocop-codacy.yml for Codacy analysis, allowing exclusion of private gems. This prevents analysis issues caused by private gem references, ensuring proper validation by Codacy. Scalastyle Scala scalastyle-config.xml , scalastyle_config.xml Semgrep Apex, C++, C#, Dockerfile, Elixir, GitHub Actions, Go, Java, JavaScript, Kotlin, PHP, Python, Ruby, Rust, Scala, Shell, Swift, Terraform, TypeScript .semgrep.yaml SonarC# C# SonarLint.xml SonarVB Visual Basic SonarLint.xml Spectral AsyncAPI, OpenAPI .spectral.yaml , .spectral.yml , .spectral.json SpotBugs Java, Scala findbugs.xml , findbugs-includes.xml , findbugs-excludes.xml , spotbugs.xml , spotbugs-includes.xml , spotbugs-excludes.xml Supports configuration file in directories other than root and can search up to 5 directories into the repository. Stylelint CSS, LESS, SASS .stylelintrc , stylelint.config.js , .stylelintrc.json , .stylelintrc.yaml , .stylelintrc.yml , .stylelintrc.js Supports configuration file in directories other than root and can search up to 5 directories into the repository. SwiftLint Swift .swiftlint.yml TSQLLint Transact-SQL .tsqllintrc Note Codacy doesn't support configuration files for the following tools: aligncheck Checkov Clang-Tidy Codacy Scalameta Pro CoffeeLint Cppcheck deadcode Flawfinder Gosec Jackson Linter PSScriptAnalyzer ShellCheck SQLint Staticcheck Trivy Unity Roslyn Analyzers See also # Applying a coding standard across multiple repositories How to implement Google JavaScript style guide with Codacy", "title": "Configuring code patterns"}, {"location": "repositories-configure/configuring-code-patterns/#configuring-code-patterns", "text": "Organization admins can manage access to this feature By default, Codacy analyzes your repositories using a subset of the supported analysis tools and code patterns. These defaults are based on current best practices and community feedback, and you can adapt them to your needs as follows: Configuring tools and code patterns using the Codacy UI Using tool configuration files", "title": "Configuring code patterns"}, {"location": "repositories-configure/configuring-code-patterns/#configuring-tools-and-code-patterns-using-the-codacy-ui", "text": "To configure the tools and code patterns for a repository using the Codacy UI: Open your repository Code patterns page. Enable or disable the tools that Codacy will use to analyze the repository. Select a tool to enable or disable its code patterns. To make it easier to find relevant patterns, use the filters above the pattern list. You can filter by issue category , status, severity level, or display only recommended code patterns. To see an explanation of the issues that a pattern detects and how to fix them, click the respective dropdown arrow. Tip To enable a group of code patterns, use the filter to select the relevant group of patterns and click the checkbox in the header of the patterns list. Codacy displays the tag New for one month next to the name of newly added code patterns. Optionally, to take the changes into account immediately, reanalyze the repository manually . Otherwise, Codacy will use the updated configuration when analyzing new commits and pull requests.", "title": "Configuring tools and code patterns using the Codacy UI"}, {"location": "repositories-configure/configuring-code-patterns/#detaching", "text": "If the repository is following a coding standard, a notice is displayed. To detach the coding standard from the repository, click Detach repository and confirm.", "title": "Detaching a coding standard from a repository"}, {"location": "repositories-configure/configuring-code-patterns/#using-your-own-tool-configuration-files", "text": "Note After activating a configuration file for a tool, Codacy uses that configuration file even if you exclude it from Codacy analysis . When using a tool configuration file alongside a coding standard , the configuration file controls the code patterns, while the coding standard controls whether the tool is enabled or disabled. Codacy supports configuration files for several static analysis tools to help you streamline your setup. To use a configuration file for a static analysis tool: Push the configuration file to the root of the default Codacy branch . Open the repository Code patterns page, select the tool of interest, and activate the toggle to use a configuration file. Note Codacy uses the version of the configuration file in the branch being analyzed . For example, if you open a pull request that includes changes to the configuration file, the analysis results take those changes into account. If Codacy analyzes a branch that doesn't include the configuration file, Codacy reverts to using the code patterns configured for the tool before you selected the option Configuration file on the Code patterns page. For performance reasons, when you update pattern settings using a configuration file, Codacy may display outdated messages for issues identified previously by those patterns. The table below lists the configuration file names that Codacy detects and supports for each tool: Tool name Languages Files detected Other info Ameba Crystal .ameba.yml Bandit Python bandit.yml , bandit.yaml , .bandit , bandit.toml , bandit.ini To solve flagged valid Python \"assert\" statements, create a bandit.yml on the root of the repository containing: skips: \\['B101'\\] Brakeman Ruby config/brakeman.yml Checkstyle Java checkstyle.xml Supports configuration file in directories other than root and can search up to 5 directories into the repository. CodeNarc Groovy .codenarcrc Credo Elixir .credo.exs , config/.credo.exs dartanalyzer Dart analysis_options.yml Customizing static analysis detekt Kotlin default-detekt-config.yml , detekt.yml Supports configuration file in directories other than root and can search up to 5 directories into the repository. ESLint JavaScript, TypeScript .eslintrc.js , .eslintrc.cjs , .eslintrc.yaml , .eslintrc.yml , .eslintrc.json Plugins configurable on the Codacy UI Other supported plugins If you're using module-level ESLint configuration files , you must also include a ESLint configuration file on the root of your repository for Codacy to detect that you're using configuration files. For example, add the following minimal .eslintrc.json configuration file: { \"root\": true } Hadolint Dockerfile .hadolint.yaml markdownlint Markdown .markdownlint.json PHP_CodeSniffer PHP phpcs.xml , phpcs.xml.dist PHP Mess Detector PHP codesize.xml , phpmd.xml , phpmd.xml.dist PMD Apex, Java, JavaScript, JSP, PL/SQL, XML, Velocity and Visualforce ruleset.xml , apex-ruleset.xml Supports configuration file in directories other than root and can search up to 5 directories into the repository. Prospector Python .prospector.yml , .prospector.yaml , prospector.yml , prospector.yaml , .landscape.yml , .landscape.yaml , landscape.yml , landscape.yaml Pylint Python pylintrc , .pylintrc Plugins remark-lint Markdown .remarkrc , .remarkrc.json , .remarkrc.yaml , .remarkrc.yml , .remarkrc.js Revive Go revive.toml RuboCop Ruby .rubocop.yml , .rubocop-codacy.yml Supports alternative configuration file .rubocop-codacy.yml for Codacy analysis, allowing exclusion of private gems. This prevents analysis issues caused by private gem references, ensuring proper validation by Codacy. Scalastyle Scala scalastyle-config.xml , scalastyle_config.xml Semgrep Apex, C++, C#, Dockerfile, Elixir, GitHub Actions, Go, Java, JavaScript, Kotlin, PHP, Python, Ruby, Rust, Scala, Shell, Swift, Terraform, TypeScript .semgrep.yaml SonarC# C# SonarLint.xml SonarVB Visual Basic SonarLint.xml Spectral AsyncAPI, OpenAPI .spectral.yaml , .spectral.yml , .spectral.json SpotBugs Java, Scala findbugs.xml , findbugs-includes.xml , findbugs-excludes.xml , spotbugs.xml , spotbugs-includes.xml , spotbugs-excludes.xml Supports configuration file in directories other than root and can search up to 5 directories into the repository. Stylelint CSS, LESS, SASS .stylelintrc , stylelint.config.js , .stylelintrc.json , .stylelintrc.yaml , .stylelintrc.yml , .stylelintrc.js Supports configuration file in directories other than root and can search up to 5 directories into the repository. SwiftLint Swift .swiftlint.yml TSQLLint Transact-SQL .tsqllintrc Note Codacy doesn't support configuration files for the following tools: aligncheck Checkov Clang-Tidy Codacy Scalameta Pro CoffeeLint Cppcheck deadcode Flawfinder Gosec Jackson Linter PSScriptAnalyzer ShellCheck SQLint Staticcheck Trivy Unity Roslyn Analyzers", "title": "Using tool configuration files"}, {"location": "repositories-configure/configuring-code-patterns/#see-also", "text": "Applying a coding standard across multiple repositories How to implement Google JavaScript style guide with Codacy", "title": "See also"}, {"location": "repositories-configure/ignoring-files/", "text": "Ignoring files # Organization admins can manage access to this feature In some situations, you may want to ignore or exclude files from the Codacy analysis. To exclude files from your repository analysis open your repository Settings , tab Ignored Files , and select the files you want to ignore. This view only shows the files on your main branch. Note See below the files that Codacy ignores by default . You can also ignore files using your own tool configuration files , although this depends on the option being supported by each tool. To exclude files from coverage analysis only, you must ignore them directly in the tool you're using to generate coverage reports and ensure that the reports you upload to Codacy don't include coverage information for those files. If you need more flexibility in ignoring files, use a Codacy configuration file to define a custom list of file paths to exclude . Important If your repository has a Codacy configuration file , the Ignored files settings defined on the Codacy UI don't apply and you must ignore files using the configuration file instead. Default ignored files # By default, Codacy ignores all the files that match the regular expressions below. If you need to analyze files that match these regular expressions, use a Codacy configuration file to define a custom list of file paths to include . .*[\\.-]min\\.css .*[\\.-]min\\.js .*node_modules/.* .*bower_components/.* .*vendor/.* .*third[_-]?[Pp]arty/.* .*samples?/.* .*releases?/.* .*builds?/.* .*dist/.* .*external/.* .*libs/.* .*d3\\.js .*angular(-resource|)?\\.js .*select2(-resource|)?\\.js .*-ace\\.js .*typeahead\\.js .*jquery-ui\\.js .*reveal\\.js .*three\\.js .*chart\\.js .*jquery\\.js .*underscore\\.js .*lodash\\.js .*bootstrap\\.js .*bootstrap\\.css .*font-awesome\\.css .*\\.[Dd]esigner\\.cs", "title": "Ignoring files"}, {"location": "repositories-configure/ignoring-files/#ignoring-files", "text": "Organization admins can manage access to this feature In some situations, you may want to ignore or exclude files from the Codacy analysis. To exclude files from your repository analysis open your repository Settings , tab Ignored Files , and select the files you want to ignore. This view only shows the files on your main branch. Note See below the files that Codacy ignores by default . You can also ignore files using your own tool configuration files , although this depends on the option being supported by each tool. To exclude files from coverage analysis only, you must ignore them directly in the tool you're using to generate coverage reports and ensure that the reports you upload to Codacy don't include coverage information for those files. If you need more flexibility in ignoring files, use a Codacy configuration file to define a custom list of file paths to exclude . Important If your repository has a Codacy configuration file , the Ignored files settings defined on the Codacy UI don't apply and you must ignore files using the configuration file instead.", "title": "Ignoring files"}, {"location": "repositories-configure/ignoring-files/#default-ignored-files", "text": "By default, Codacy ignores all the files that match the regular expressions below. If you need to analyze files that match these regular expressions, use a Codacy configuration file to define a custom list of file paths to include . .*[\\.-]min\\.css .*[\\.-]min\\.js .*node_modules/.* .*bower_components/.* .*vendor/.* .*third[_-]?[Pp]arty/.* .*samples?/.* .*releases?/.* .*builds?/.* .*dist/.* .*external/.* .*libs/.* .*d3\\.js .*angular(-resource|)?\\.js .*select2(-resource|)?\\.js .*-ace\\.js .*typeahead\\.js .*jquery-ui\\.js .*reveal\\.js .*three\\.js .*chart\\.js .*jquery\\.js .*underscore\\.js .*lodash\\.js .*bootstrap\\.js .*bootstrap\\.css .*font-awesome\\.css .*\\.[Dd]esigner\\.cs", "title": "Default ignored files"}, {"location": "repositories-configure/languages/", "text": "Configuring languages # Organization admins can manage access to this feature Codacy automatically detects and analyzes languages in your repository based on a list of supported file extensions. On the repository Settings , tab Languages , you can see the list of languages that Codacy detected and will include in the next analysis. By default, the analysis is enabled for all languages that Codacy detects in you repository. You can adapt this configuration to your needs as follows: Configure Codacy to include unrecognized extensions Disable the analysis of specific languages Note Codacy applies the language settings defined in the Codacy UI as well as any settings defined using a Codacy configuration file . Configuring file extensions # If your repository contains source files with extensions not supported by Codacy, associate these extensions with their respective languages to ensure Codacy analyzes them in the next analysis: Go to your repository's Settings , Languages . Add the extensions you want to be recognized for each language. Click Save changes to update your file extension settings. The updated settings will be used on the next analysis, but you can click reanalyze the latest commit of your branches now on the notification that appears at the bottom of the page to trigger an analysis immediately. Note Currently, the Semgrep static analysis tool doesn't support custom file extensions. Disabling analysis of a language # By default, Codacy analyzes all languages detected in your repository. To disable the analysis of a specific language, do the following: Go to your repository's Settings , Languages . Use the toggle next to the language to disable its analysis. Click Save changes to update your settings. The updated settings will be used on the next analysis, but you can click reanalyze the latest commit of your branches now on the notification that appears at the bottom of the page to trigger an analysis immediately.", "title": "Configuring languages"}, {"location": "repositories-configure/languages/#configuring-languages", "text": "Organization admins can manage access to this feature Codacy automatically detects and analyzes languages in your repository based on a list of supported file extensions. On the repository Settings , tab Languages , you can see the list of languages that Codacy detected and will include in the next analysis. By default, the analysis is enabled for all languages that Codacy detects in you repository. You can adapt this configuration to your needs as follows: Configure Codacy to include unrecognized extensions Disable the analysis of specific languages Note Codacy applies the language settings defined in the Codacy UI as well as any settings defined using a Codacy configuration file .", "title": "Configuring languages"}, {"location": "repositories-configure/languages/#configuring-file-extensions", "text": "If your repository contains source files with extensions not supported by Codacy, associate these extensions with their respective languages to ensure Codacy analyzes them in the next analysis: Go to your repository's Settings , Languages . Add the extensions you want to be recognized for each language. Click Save changes to update your file extension settings. The updated settings will be used on the next analysis, but you can click reanalyze the latest commit of your branches now on the notification that appears at the bottom of the page to trigger an analysis immediately. Note Currently, the Semgrep static analysis tool doesn't support custom file extensions.", "title": "Configuring file extensions"}, {"location": "repositories-configure/languages/#disable-language", "text": "By default, Codacy analyzes all languages detected in your repository. To disable the analysis of a specific language, do the following: Go to your repository's Settings , Languages . Use the toggle next to the language to disable its analysis. Click Save changes to update your settings. The updated settings will be used on the next analysis, but you can click reanalyze the latest commit of your branches now on the notification that appears at the bottom of the page to trigger an analysis immediately.", "title": "Disabling analysis of a language"}, {"location": "repositories-configure/managing-branches/", "text": "Managing branches # Organization admins can manage access to this feature Codacy automatically analyzes the default branch of your repository (typically master or main as configured on your Git provider) and loads its data first on dashboards. Codacy also supports analyzing multiple branches. Note Codacy doesn't support and skips the analysis of branches named HEAD or matching the pattern refs/heads/* , as these are Git reserved terms. To change the default branch of your repository or start analyzing other branches: Open your repository Settings , tab Branches . To enable analysis for a new branch, toggle the corresponding switch in the column Analyze . Enabling a new branch triggers an initial analysis of that branch and the analysis results and information for that branch will become available after the analysis is complete. To change the default branch on Codacy, click the corresponding Make default link that appears when you hover the column Default . Changing the default branch on Codacy doesn't change the default branch on your Git provider. Likewise, changing the default branch on your Git provider doesn't change the default branch on Codacy. Note You can only set as default branch an already enabled branch. Codacy manages pull request branches and inactive branches as follows: Pull request branches Codacy automatically analyzes branches corresponding to new pull requests and also enables the target branches if they're disabled. Inactive branches Codacy automatically disables analysis for branches that don't have any commits for more than 2 weeks, except for the main branch and pull request branches that are analyzed automatically.", "title": "Managing branches"}, {"location": "repositories-configure/managing-branches/#managing-branches", "text": "Organization admins can manage access to this feature Codacy automatically analyzes the default branch of your repository (typically master or main as configured on your Git provider) and loads its data first on dashboards. Codacy also supports analyzing multiple branches. Note Codacy doesn't support and skips the analysis of branches named HEAD or matching the pattern refs/heads/* , as these are Git reserved terms. To change the default branch of your repository or start analyzing other branches: Open your repository Settings , tab Branches . To enable analysis for a new branch, toggle the corresponding switch in the column Analyze . Enabling a new branch triggers an initial analysis of that branch and the analysis results and information for that branch will become available after the analysis is complete. To change the default branch on Codacy, click the corresponding Make default link that appears when you hover the column Default . Changing the default branch on Codacy doesn't change the default branch on your Git provider. Likewise, changing the default branch on your Git provider doesn't change the default branch on Codacy. Note You can only set as default branch an already enabled branch. Codacy manages pull request branches and inactive branches as follows: Pull request branches Codacy automatically analyzes branches corresponding to new pull requests and also enables the target branches if they're disabled. Inactive branches Codacy automatically disables analysis for branches that don't have any commits for more than 2 weeks, except for the main branch and pull request branches that are analyzed automatically.", "title": "Managing branches"}, {"location": "repositories-configure/removing-your-repository/", "text": "Removing your repository # To stop Codacy from analyzing your repository, you must remove the repository from Codacy. Removing a repository from Codacy completely removes the configurations and all data related to your repository from Codacy. This operation doesn't make any changes on your Git provider. Important To remove a repository from Codacy you must have administrator permissions for that repository on your Git provider. To delete your repository from Codacy: Open your repository Settings , tab General . Click the button Remove repository and confirm that you want to remove the repository. Note For added security, after you remove the repository from Codacy you can delete from your Git provider the Codacy resources related to that repository to prevent their reuse: Webhooks SSH keys (GitLab and Bitbucket only)", "title": "Removing your repository"}, {"location": "repositories-configure/removing-your-repository/#removing-your-repository", "text": "To stop Codacy from analyzing your repository, you must remove the repository from Codacy. Removing a repository from Codacy completely removes the configurations and all data related to your repository from Codacy. This operation doesn't make any changes on your Git provider. Important To remove a repository from Codacy you must have administrator permissions for that repository on your Git provider. To delete your repository from Codacy: Open your repository Settings , tab General . Click the button Remove repository and confirm that you want to remove the repository. Note For added security, after you remove the repository from Codacy you can delete from your Git provider the Codacy resources related to that repository to prevent their reuse: Webhooks SSH keys (GitLab and Bitbucket only)", "title": "Removing your repository"}, {"location": "repositories-configure/using-submodules/", "text": "Using submodules # Git submodules allow you to keep a Git repository as a subdirectory within another Git repository. Git submodules are helpful in maintaining a shared configuration file for your team, and then applying it to multiple Git repositories. By default, Codacy does normal Git clones that don't include submodules to ensure that we only clone necessary repositories. If your organization needs to use submodules, you can request Codacy to enable this feature for you. Important GitHub only: Your repository and the repositories that you add as submodules must belong to the same GitHub organization. Prerequisites for using submodules # Contact us at support@codacy.com asking to enable submodules on Codacy. If you're using Codacy Self-hosted , update your license . Make sure that your Git URL uses the correct protocol: GitHub: HTTPS protocol GitLab and Bitbucket: HTTPS protocol, if your submodules are public repositories SSH protocol, if your submodules are private repositories Enabling submodules on a repository # When using submodules, you must do the following for all your existing and new repositories: GitLab and Bitbucket only: Update the public SSH key that Codacy uses to access your repository. If you're using submodules to share an analysis tool configuration file across your repositories, check if your tool recursively searches the subdirectories of your repositories for configuration files. If your tool doesn't detect the configuration files in the submodule directories, you must include a configuration file directly in the root of your repositories referencing the configuration files in the submodule directories. Updating the public SSH key to access the repository # This section applies only to GitLab and Bitbucket On GitLab and Bitbucket organizations, Codacy generates a repository key when you add a repository to Codacy and uses it to clone that repository. When you're using submodules, Codacy needs to clone additional repositories it may not have access to. To overcome this, Codacy must use an SSH key of your user account to have access to the same repositories as your user. To update your GitLab or Bitbucket public SSH key that Codacy uses to access your repository, do the following: Open the repository Settings , tab General . In the Danger zone area, you have the SSH Key generated by Codacy to access your repository. Depending on your Git provider, do the following to update the key: For GitLab, click the button Generate New User Key . Codacy removes the existing repository key and creates the new SSH key on your user account automatically. For Bitbucket: Remove the existing Codacy key from the repository settings on your Git provider. Click the link Add new user key . This takes you to the Git provider page where you can manage your user account SSH keys. Add a new SSH key to your Git provider account. Automating user keys for new repositories # This section applies only to Codacy Self-hosted You can set Codacy to automatically add the new SSH key to your Git provider account for all new repositories by enabling Add project key to the user, by default on the Administration console, page Settings . Important If you're using Bitbucket Cloud this setting must be turned off since automatically adding the user keys isn't supported. See also # Configure repository settings in Bitbucket Add an SSH key to your Bitbucket account", "title": "Using submodules"}, {"location": "repositories-configure/using-submodules/#using-submodules", "text": "Git submodules allow you to keep a Git repository as a subdirectory within another Git repository. Git submodules are helpful in maintaining a shared configuration file for your team, and then applying it to multiple Git repositories. By default, Codacy does normal Git clones that don't include submodules to ensure that we only clone necessary repositories. If your organization needs to use submodules, you can request Codacy to enable this feature for you. Important GitHub only: Your repository and the repositories that you add as submodules must belong to the same GitHub organization.", "title": "Using submodules"}, {"location": "repositories-configure/using-submodules/#prerequisites-for-using-submodules", "text": "Contact us at support@codacy.com asking to enable submodules on Codacy. If you're using Codacy Self-hosted , update your license . Make sure that your Git URL uses the correct protocol: GitHub: HTTPS protocol GitLab and Bitbucket: HTTPS protocol, if your submodules are public repositories SSH protocol, if your submodules are private repositories", "title": "Prerequisites for using submodules"}, {"location": "repositories-configure/using-submodules/#enabling-submodules-on-a-repository", "text": "When using submodules, you must do the following for all your existing and new repositories: GitLab and Bitbucket only: Update the public SSH key that Codacy uses to access your repository. If you're using submodules to share an analysis tool configuration file across your repositories, check if your tool recursively searches the subdirectories of your repositories for configuration files. If your tool doesn't detect the configuration files in the submodule directories, you must include a configuration file directly in the root of your repositories referencing the configuration files in the submodule directories.", "title": "Enabling submodules on a repository"}, {"location": "repositories-configure/using-submodules/#update-key", "text": "This section applies only to GitLab and Bitbucket On GitLab and Bitbucket organizations, Codacy generates a repository key when you add a repository to Codacy and uses it to clone that repository. When you're using submodules, Codacy needs to clone additional repositories it may not have access to. To overcome this, Codacy must use an SSH key of your user account to have access to the same repositories as your user. To update your GitLab or Bitbucket public SSH key that Codacy uses to access your repository, do the following: Open the repository Settings , tab General . In the Danger zone area, you have the SSH Key generated by Codacy to access your repository. Depending on your Git provider, do the following to update the key: For GitLab, click the button Generate New User Key . Codacy removes the existing repository key and creates the new SSH key on your user account automatically. For Bitbucket: Remove the existing Codacy key from the repository settings on your Git provider. Click the link Add new user key . This takes you to the Git provider page where you can manage your user account SSH keys. Add a new SSH key to your Git provider account.", "title": "Updating the public SSH key to access the repository"}, {"location": "repositories-configure/using-submodules/#automating-user-keys-for-new-repositories", "text": "This section applies only to Codacy Self-hosted You can set Codacy to automatically add the new SSH key to your Git provider account for all new repositories by enabling Add project key to the user, by default on the Administration console, page Settings . Important If you're using Bitbucket Cloud this setting must be turned off since automatically adding the user keys isn't supported.", "title": "Automating user keys for new repositories"}, {"location": "repositories-configure/using-submodules/#see-also", "text": "Configure repository settings in Bitbucket Add an SSH key to your Bitbucket account", "title": "See also"}, {"location": "repositories-configure/integrations/bitbucket-integration/", "text": "Bitbucket integration # The Bitbucket integration incorporates Codacy on your existing Git provider workflows by reporting issues and the analysis status directly on your pull requests. When you add a new repository, Codacy sets the Bitbucket integration using the default settings for your organization . You can then customize the settings for the repository. Important Codacy uses the Bitbucket user who added the repository to create comments on pull requests. If that user loses access to the repository, a repository admin must refresh the Bitbucket integration . Configuring the Bitbucket integration # To configure the Bitbucket integration, open your repository Settings , tab Integrations . Depending on the options that you enable, Codacy will automatically update pull requests on Bitbucket with extra information when accepting pull requests. Tip You can apply the default Git provider integration settings to all repositories to ensure that your repositories all share the same settings. Status checks # Adds a report to your pull requests showing whether your pull requests and coverage are up to standards or not as configured on the quality gate rules for your repository. You can then optionally block merging pull requests that aren't up to standards . Important To get a status for coverage you must also: Add coverage to your repository Enable the rule Diff coverage is under or Coverage variation is under on the pull request quality gate . Issue annotations # Adds comments on the lines of the pull request where Codacy finds new issues. Click on the links to open Codacy and see more details about the issues and how to fix them. To enable this option, you must enable Status checks first. Issue summaries # This feature isn't available for Bitbucket Server Shows an overall view of the changes in the pull request, including new issues and metrics such as complexity and duplication. To enable this option, you must enable Status checks first. AI-Enhanced Comments # Adds AI-enhanced comments with insights to help you fix identified issues. Note This feature is compatible with most programming languages and requires no additional setup. Comments are generated using the description of the static analysis issue, information about the tool that detected the issue, and a few lines of surrounding code to provide the AI with extra context and improve its accuracy. This feature leverages the OpenAI API. No information is shared with other third parties or used to train AI models. Please refer to the OpenAI API data usage policies for more information. Refreshing the Bitbucket integration # If the user who added the repository to Codacy loses access to the repository, which may happen when the user leaves the team or the organization, Codacy won't be able to create comments on pull requests. In this situation, another user with administrator access to the repository needs to refresh the Bitbucket integration: Tip Use a dedicated service account to integrate Codacy with your repositories. This prevents disruption of service if the user who originally enabled the integration loses access to the repositories, which may happen when a user leaves the team or the organization. For more information and instructions on how to set up a dedicated service account see Why did Codacy stop commenting on pull requests? Open the repository Settings , tab Integrations . On the Bitbucket integration area, click the link Refresh connection . After refreshing the integration, Codacy will use the logged in Bitbucket user to create comments on new pull requests. Generating automatic pull request summaries # This is a preview feature This is an upcoming Codacy feature. If you're interested, contact support@codacy.com for early access. Codacy can provide a clear, high-level summary of the code changes introduced by a pull request, based on the committed code. Codacy generates an overview of the changes in the pull request so that any reviewer can understand its intent and impact. Note This feature uses only AWS services within Codacy's existing infrastructure. No information is shared with any other third party or used to train AI models. Summaries are generated using the pull request title, branch name, commit messages, and changes diff. To enable this feature, add the following to the Codacy configuration file .codacy.yaml in the root of your repository: --- reviews : high_level_summary : true You can also enable this feature across your organization by creating the above file in the root of a repository named .codacy . This file will be used as the default configuration for all repositories in the organization and overridden by repository-specific configuration files. Once enabled, summaries will be created when pull requests are opened and updated at each commit to reflect any changes to the pull request. Pull requests opened by bots, such as Dependabot, are ignored. If you see duplicated comments posted by Codacy on the same pull request, please ensure that your repository only has one configured webhook for Codacy. See also # Integrating Codacy with your Git workflow", "title": "Bitbucket integration"}, {"location": "repositories-configure/integrations/bitbucket-integration/#bitbucket-integration", "text": "The Bitbucket integration incorporates Codacy on your existing Git provider workflows by reporting issues and the analysis status directly on your pull requests. When you add a new repository, Codacy sets the Bitbucket integration using the default settings for your organization . You can then customize the settings for the repository. Important Codacy uses the Bitbucket user who added the repository to create comments on pull requests. If that user loses access to the repository, a repository admin must refresh the Bitbucket integration .", "title": "Bitbucket integration"}, {"location": "repositories-configure/integrations/bitbucket-integration/#configuring", "text": "To configure the Bitbucket integration, open your repository Settings , tab Integrations . Depending on the options that you enable, Codacy will automatically update pull requests on Bitbucket with extra information when accepting pull requests. Tip You can apply the default Git provider integration settings to all repositories to ensure that your repositories all share the same settings.", "title": "Configuring the Bitbucket integration"}, {"location": "repositories-configure/integrations/bitbucket-integration/#refreshing", "text": "If the user who added the repository to Codacy loses access to the repository, which may happen when the user leaves the team or the organization, Codacy won't be able to create comments on pull requests. In this situation, another user with administrator access to the repository needs to refresh the Bitbucket integration: Tip Use a dedicated service account to integrate Codacy with your repositories. This prevents disruption of service if the user who originally enabled the integration loses access to the repositories, which may happen when a user leaves the team or the organization. For more information and instructions on how to set up a dedicated service account see Why did Codacy stop commenting on pull requests? Open the repository Settings , tab Integrations . On the Bitbucket integration area, click the link Refresh connection . After refreshing the integration, Codacy will use the logged in Bitbucket user to create comments on new pull requests.", "title": "Refreshing the Bitbucket integration"}, {"location": "repositories-configure/integrations/bitbucket-integration/#generating-automatic-pull-request-summaries", "text": "This is a preview feature This is an upcoming Codacy feature. If you're interested, contact support@codacy.com for early access. Codacy can provide a clear, high-level summary of the code changes introduced by a pull request, based on the committed code. Codacy generates an overview of the changes in the pull request so that any reviewer can understand its intent and impact. Note This feature uses only AWS services within Codacy's existing infrastructure. No information is shared with any other third party or used to train AI models. Summaries are generated using the pull request title, branch name, commit messages, and changes diff. To enable this feature, add the following to the Codacy configuration file .codacy.yaml in the root of your repository: --- reviews : high_level_summary : true You can also enable this feature across your organization by creating the above file in the root of a repository named .codacy . This file will be used as the default configuration for all repositories in the organization and overridden by repository-specific configuration files. Once enabled, summaries will be created when pull requests are opened and updated at each commit to reflect any changes to the pull request. Pull requests opened by bots, such as Dependabot, are ignored. If you see duplicated comments posted by Codacy on the same pull request, please ensure that your repository only has one configured webhook for Codacy.", "title": "Generating automatic pull request summaries"}, {"location": "repositories-configure/integrations/bitbucket-integration/#see-also", "text": "Integrating Codacy with your Git workflow", "title": "See also"}, {"location": "repositories-configure/integrations/github-integration/", "text": "GitHub integration # The GitHub integration incorporates Codacy on your existing Git provider workflows by reporting issues and the analysis status directly on your pull requests. When you add a new repository, Codacy sets the GitHub integration using the default settings for your organization . You can then customize the settings for the repository. Configuring the GitHub integration # To configure the GitHub integration, open your repository Settings , tab Integrations . Depending on the options that you enable, Codacy will automatically update pull requests on GitHub with extra information when accepting pull requests. Tip You can apply the default Git provider integration settings to all repositories to ensure that your repositories all share the same settings. Status checks # Adds a report to your pull requests showing whether your pull requests and coverage are up to standards or not as configured on the quality gate rules for your repository. You can then optionally block merging pull requests that aren't up to standards . Important To get a status for coverage you must also: Add coverage to your repository Enable the rule Diff coverage is under or Coverage variation is under on the pull request quality gate . Issue annotations # Adds annotations on the lines of the pull request where Codacy finds new issues. Codacy maps the severity of the issues reported by the tools to the severity levels of the annotations. To enable this option, you must enable Status checks first. Issue summaries # Shows an overall view of the changes in the pull request, including new issues and metrics such as complexity and duplication. To enable this option, you must enable Status checks first. Coverage summaries # Adds a pull request comment showing an overall view of the coverage metrics for the pull request, including details about the data that Codacy used to calculate the coverage variation and diff coverage metrics. When there are new coverage results, Codacy updates the last coverage summary comment if it's included in the last 5 comments of the pull request. Otherwise, Codacy creates a new comment. Important To get coverage summaries you must also add coverage to your repository . Note This feature is only supported on GitHub Cloud. Suggested fixes # This feature is only available on paid plans Adds comments on the lines of the pull request where Codacy finds new issues with suggestions on how to fix the issues. Codacy doesn't apply any changes automatically. To apply the changes, manually review and accept the suggestions . Tip Enable also AI-enhanced comments to get ready-to-commit AI-generated fixes. AI-enhanced comments # Adds AI-enhanced comments, providing insights and ready-to-commit AI-generated fixes for identified issues in cases where tool-suggested fixes are not supported. To enable this option, you must enable Suggested fixes first. Note This feature is compatible with most programming languages and requires no additional setup. Comments are generated using the description of the static analysis issue, information about the tool that detected the issue, and a few lines of surrounding code to provide the AI with extra context and improve its accuracy. This feature leverages the OpenAI API. No information is shared with other third parties or used to train AI models. Please refer to the OpenAI API data usage policies for more information. Generating automatic pull request summaries # This is a preview feature This is an upcoming Codacy feature. If you're interested, contact support@codacy.com for early access. Codacy can provide a clear, high-level summary of the code changes introduced by a pull request, based on the committed code. Codacy generates an overview of the changes in the pull request so that any reviewer can understand its intent and impact. Note This feature uses only AWS services within Codacy's existing infrastructure. No information is shared with any other third party or used to train AI models. Summaries are generated using the pull request title, branch name, commit messages, and changes diff. To enable this feature, add the following to the Codacy configuration file .codacy.yaml in the root of your repository: --- reviews : high_level_summary : true You can also enable this feature across your organization by creating the above file in the root of a repository named .codacy . This file will be used as the default configuration for all repositories in the organization and overridden by repository-specific configuration files. Once enabled, summaries will be created when pull requests are opened and updated at each commit to reflect any changes to the pull request. Pull requests opened by bots, such as Dependabot, are ignored. If you see duplicated comments posted by Codacy on the same pull request, please ensure that your repository only has one configured webhook for Codacy. See also # Integrating Codacy with your Git workflow", "title": "GitHub integration"}, {"location": "repositories-configure/integrations/github-integration/#github-integration", "text": "The GitHub integration incorporates Codacy on your existing Git provider workflows by reporting issues and the analysis status directly on your pull requests. When you add a new repository, Codacy sets the GitHub integration using the default settings for your organization . You can then customize the settings for the repository.", "title": "GitHub integration"}, {"location": "repositories-configure/integrations/github-integration/#configuring", "text": "To configure the GitHub integration, open your repository Settings , tab Integrations . Depending on the options that you enable, Codacy will automatically update pull requests on GitHub with extra information when accepting pull requests. Tip You can apply the default Git provider integration settings to all repositories to ensure that your repositories all share the same settings.", "title": "Configuring the GitHub integration"}, {"location": "repositories-configure/integrations/github-integration/#generating-automatic-pull-request-summaries", "text": "This is a preview feature This is an upcoming Codacy feature. If you're interested, contact support@codacy.com for early access. Codacy can provide a clear, high-level summary of the code changes introduced by a pull request, based on the committed code. Codacy generates an overview of the changes in the pull request so that any reviewer can understand its intent and impact. Note This feature uses only AWS services within Codacy's existing infrastructure. No information is shared with any other third party or used to train AI models. Summaries are generated using the pull request title, branch name, commit messages, and changes diff. To enable this feature, add the following to the Codacy configuration file .codacy.yaml in the root of your repository: --- reviews : high_level_summary : true You can also enable this feature across your organization by creating the above file in the root of a repository named .codacy . This file will be used as the default configuration for all repositories in the organization and overridden by repository-specific configuration files. Once enabled, summaries will be created when pull requests are opened and updated at each commit to reflect any changes to the pull request. Pull requests opened by bots, such as Dependabot, are ignored. If you see duplicated comments posted by Codacy on the same pull request, please ensure that your repository only has one configured webhook for Codacy.", "title": "Generating automatic pull request summaries"}, {"location": "repositories-configure/integrations/github-integration/#see-also", "text": "Integrating Codacy with your Git workflow", "title": "See also"}, {"location": "repositories-configure/integrations/gitlab-integration/", "text": "GitLab integration # The GitLab integration incorporates Codacy on your existing Git provider workflows by reporting issues and the analysis status directly on your merge requests. When you add a new repository, Codacy sets the GitLab integration using the default settings for your organization . You can then customize the settings for the repository. Important Codacy uses the GitLab user who added the repository to create comments on merge requests. If that user loses access to the repository, a repository admin must refresh the GitLab integration . Configuring the GitLab integration # To configure the GitLab integration, open your repository Settings , tab Integrations . Depending on the options that you enable, Codacy will automatically update merge requests on GitLab with extra information when accepting merge requests. Tip You can apply the default Git provider integration settings to all repositories to ensure that your repositories all share the same settings. Status checks # Adds a report to your merge requests showing whether your merge requests and coverage are up to standards or not as configured on the quality gate rules for your project. You can then optionally block merging merge requests that aren't up to standards . Important To get a status for coverage you must also: Add coverage to your repository Enable the rule Diff coverage is under or Coverage variation is under on the pull request quality gate . Issue annotations # Adds comments on the lines of the merge request where Codacy finds new issues. Click on the links to open Codacy and see more details about the issues and how to fix them. To enable this option, you must enable Status checks first. Issue summaries # Shows an overall view of the changes in the merge request, including new issues and metrics such as complexity and duplication. To enable this option, you must enable Status checks first. AI-Enhanced Comments # Adds AI-enhanced comments with insights to help you fix identified issues. Note This feature is compatible with most programming languages and requires no additional setup. Comments are generated using the description of the static analysis issue, information about the tool that detected the issue, and a few lines of surrounding code to provide the AI with extra context and improve its accuracy. This feature leverages the OpenAI API. No information is shared with other third parties or used to train AI models. Please refer to the OpenAI API data usage policies for more information. Refreshing the GitLab integration # If the user who added the repository to Codacy loses access to the repository, which may happen when the user leaves the team or the organization, Codacy won't be able to create comments on merge requests. In this situation, another user with administrator access to the repository needs to refresh the GitLab integration: Tip Use a dedicated service account to integrate Codacy with your repositories. This prevents disruption of service if the user who originally enabled the integration loses access to the repositories, which may happen when a user leaves the team or the organization. For more information and instructions on how to set up a dedicated service account see Why did Codacy stop commenting on pull requests? Open the repository Settings , tab Integrations . On the GitLab integration area, click the link Refresh connection . After refreshing the integration, Codacy will use the logged in GitLab user to create comments on new merge requests. See also # Integrating Codacy with your Git workflow", "title": "GitLab integration"}, {"location": "repositories-configure/integrations/gitlab-integration/#gitlab-integration", "text": "The GitLab integration incorporates Codacy on your existing Git provider workflows by reporting issues and the analysis status directly on your merge requests. When you add a new repository, Codacy sets the GitLab integration using the default settings for your organization . You can then customize the settings for the repository. Important Codacy uses the GitLab user who added the repository to create comments on merge requests. If that user loses access to the repository, a repository admin must refresh the GitLab integration .", "title": "GitLab integration"}, {"location": "repositories-configure/integrations/gitlab-integration/#configuring", "text": "To configure the GitLab integration, open your repository Settings , tab Integrations . Depending on the options that you enable, Codacy will automatically update merge requests on GitLab with extra information when accepting merge requests. Tip You can apply the default Git provider integration settings to all repositories to ensure that your repositories all share the same settings.", "title": "Configuring the GitLab integration"}, {"location": "repositories-configure/integrations/gitlab-integration/#refreshing", "text": "If the user who added the repository to Codacy loses access to the repository, which may happen when the user leaves the team or the organization, Codacy won't be able to create comments on merge requests. In this situation, another user with administrator access to the repository needs to refresh the GitLab integration: Tip Use a dedicated service account to integrate Codacy with your repositories. This prevents disruption of service if the user who originally enabled the integration loses access to the repositories, which may happen when a user leaves the team or the organization. For more information and instructions on how to set up a dedicated service account see Why did Codacy stop commenting on pull requests? Open the repository Settings , tab Integrations . On the GitLab integration area, click the link Refresh connection . After refreshing the integration, Codacy will use the logged in GitLab user to create comments on new merge requests.", "title": "Refreshing the GitLab integration"}, {"location": "repositories-configure/integrations/gitlab-integration/#see-also", "text": "Integrating Codacy with your Git workflow", "title": "See also"}, {"location": "repositories-configure/integrations/post-commit-hooks/", "text": "Post-commit hooks # When you add a new repository to Codacy, Codacy automatically creates a repository hook on your Git provider to check for new commits and pull requests. This post-commit hook enables Codacy to trigger an analysis to run immediately after you push code to your repository. Important Don't change the configuration of the hooks created by Codacy on your Git provider, as it might cause service failure. Creating a new post-commit hook # In case your repository\u2019s hook is missing from your Git provider, you can create a new one: Open your repository Settings , tab Integrations . On the Post-commit hook area, click the button Create new hook .", "title": "Post-commit hooks"}, {"location": "repositories-configure/integrations/post-commit-hooks/#post-commit-hooks", "text": "When you add a new repository to Codacy, Codacy automatically creates a repository hook on your Git provider to check for new commits and pull requests. This post-commit hook enables Codacy to trigger an analysis to run immediately after you push code to your repository. Important Don't change the configuration of the hooks created by Codacy on your Git provider, as it might cause service failure.", "title": "Post-commit hooks"}, {"location": "repositories-configure/integrations/post-commit-hooks/#creating-a-new-post-commit-hook", "text": "In case your repository\u2019s hook is missing from your Git provider, you can create a new one: Open your repository Settings , tab Integrations . On the Post-commit hook area, click the button Create new hook .", "title": "Creating a new post-commit hook"}, {"location": "repositories-configure/local-analysis/client-side-tools/", "text": "Client-side tools # Client-side tools enable you to run an analysis locally or as part of your build process and upload the results to Codacy. This way, Codacy presents the analysis information reported by your local tools on the Codacy dashboards, in addition to the default code quality information. The following diagram presents a high-level overview of the local analysis flow. Codacy supports client-side tools in two ways: Containerized tools: Codacy provides Docker images to run analysis tools locally. To fetch code pattern configurations from Codacy, run the images, print out analysis results, and upload them to Codacy, use the Codacy Analysis CLI . The Codacy Analysis CLI automatically fetches the code pattern settings that you define on the Codacy UI and applies them when running the tools. Standalone tools: Codacy provides auxiliary converters that parse the output of third-party tools and convert to a format that you then upload to Codacy. You must download, configure, and run the third-party tools yourself. You can't configure these tools on the Codacy UI, since you manage their configuration locally. The table below describes the supported client-side tools and includes links to specific instructions on how to run each tool. Tip If you're using GitHub we recommend that you use the Codacy Analysis CLI GitHub Action to run the containerized client-side tools and upload the results to Codacy. Language Client-side tool Description Usage instructions C, C++ Clang-Tidy Clang-tidy is a clang-based C++ \u201clinter\u201d tool. Its purpose is to provide an extensible framework for diagnosing and fixing typical programming errors, like style violations, interface misuse, or bugs that can be deduced via static analysis. Clang-tidy is modular and provides a convenient interface for writing new checks. Running Clang-Tidy (standalone) Go aligncheck aligncheck is a utility for finding unused struct fields in Go source files. Running aligncheck (containerized) deadcode deadcode is a very simple utility which detects unused declarations in Go packages. Running deadcode (containerized) Gosec Gosec inspects source code for security problems by scanning the Go AST. Running Gosec (standalone) Staticcheck Staticcheck is a state of the art linter for the Go programming language. Using static analysis, it finds bugs and performance issues, offers simplifications, and enforces style rules. Running Staticcheck (standalone) Java, Scala SpotBugs SpotBugs is a program which uses static analysis to look for bugs in Java code. Together with the Find Security Bugs plugin it provides security audits. It has support for Maven, sbt, and Gradle in Java projects. Running SpotBugs (containerized) Objective-C Clang-Tidy Clang-tidy is a clang-based C++ \"linter\" tool. Its purpose is to provide an extensible framework for diagnosing and fixing typical programming errors, like style violations, interface misuse, or bugs that can be deduced via static analysis. Clang-tidy is modular and provides a convenient interface for writing new checks. Running Clang-Tidy (standalone) Unity Unity Roslyn Analyzers Unity-specific diagnostics for CSharp Unity projects. Running Unity Roslyn Analyzers (standalone) See also # Supported languages and tools", "title": "Client-side tools"}, {"location": "repositories-configure/local-analysis/client-side-tools/#client-side-tools", "text": "Client-side tools enable you to run an analysis locally or as part of your build process and upload the results to Codacy. This way, Codacy presents the analysis information reported by your local tools on the Codacy dashboards, in addition to the default code quality information. The following diagram presents a high-level overview of the local analysis flow. Codacy supports client-side tools in two ways: Containerized tools: Codacy provides Docker images to run analysis tools locally. To fetch code pattern configurations from Codacy, run the images, print out analysis results, and upload them to Codacy, use the Codacy Analysis CLI . The Codacy Analysis CLI automatically fetches the code pattern settings that you define on the Codacy UI and applies them when running the tools. Standalone tools: Codacy provides auxiliary converters that parse the output of third-party tools and convert to a format that you then upload to Codacy. You must download, configure, and run the third-party tools yourself. You can't configure these tools on the Codacy UI, since you manage their configuration locally. The table below describes the supported client-side tools and includes links to specific instructions on how to run each tool. Tip If you're using GitHub we recommend that you use the Codacy Analysis CLI GitHub Action to run the containerized client-side tools and upload the results to Codacy. Language Client-side tool Description Usage instructions C, C++ Clang-Tidy Clang-tidy is a clang-based C++ \u201clinter\u201d tool. Its purpose is to provide an extensible framework for diagnosing and fixing typical programming errors, like style violations, interface misuse, or bugs that can be deduced via static analysis. Clang-tidy is modular and provides a convenient interface for writing new checks. Running Clang-Tidy (standalone) Go aligncheck aligncheck is a utility for finding unused struct fields in Go source files. Running aligncheck (containerized) deadcode deadcode is a very simple utility which detects unused declarations in Go packages. Running deadcode (containerized) Gosec Gosec inspects source code for security problems by scanning the Go AST. Running Gosec (standalone) Staticcheck Staticcheck is a state of the art linter for the Go programming language. Using static analysis, it finds bugs and performance issues, offers simplifications, and enforces style rules. Running Staticcheck (standalone) Java, Scala SpotBugs SpotBugs is a program which uses static analysis to look for bugs in Java code. Together with the Find Security Bugs plugin it provides security audits. It has support for Maven, sbt, and Gradle in Java projects. Running SpotBugs (containerized) Objective-C Clang-Tidy Clang-tidy is a clang-based C++ \"linter\" tool. Its purpose is to provide an extensible framework for diagnosing and fixing typical programming errors, like style violations, interface misuse, or bugs that can be deduced via static analysis. Clang-tidy is modular and provides a convenient interface for writing new checks. Running Clang-Tidy (standalone) Unity Unity Roslyn Analyzers Unity-specific diagnostics for CSharp Unity projects. Running Unity Roslyn Analyzers (standalone)", "title": "Client-side tools"}, {"location": "repositories-configure/local-analysis/client-side-tools/#see-also", "text": "Supported languages and tools", "title": "See also"}, {"location": "repositories-configure/local-analysis/running-aligncheck/", "text": "Running aligncheck # To run aligncheck as a client-side tool : Enable aligncheck and configure the corresponding code patterns on your repository Code patterns page. Enable Run analysis on your build server on your repository Settings , tab General , Repository analysis on your server . This setting enables Codacy to wait for the results of the local analysis before resuming the analysis of your commits. Set up an API token to authenticate on Codacy: If you're setting up one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up multiple repositories , obtain an account API Token and set the following environment variable to specify the account API token: export CODACY_API_TOKEN = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variable to specify your Codacy instance URL: export CODACY_API_BASE_URL = Download and run the Codacy Analysis CLI on the root of the repository, specifying the tool aligncheck. codacy-analysis-cli analyze --tool aligncheck \\ --allow-network \\ --upload \\ --verbose If you're using an account API token , you must also provide the flags --provider , --username , and --project . You can obtain the values for these flags from the URL of your repository dashboard on Codacy: codacy-analysis-cli analyze --provider \\ --username \\ --project \\ --tool aligncheck \\ --allow-network \\ --upload \\ --verbose The Codacy Analysis CLI runs aligncheck on your repository and uploads the results to Codacy so you can use them in your workflow. Advanced configuration # See the available Codacy Analysis CLI configuration flags to configure running aligncheck in more advanced scenarios.", "title": "Running aligncheck"}, {"location": "repositories-configure/local-analysis/running-aligncheck/#running-aligncheck", "text": "To run aligncheck as a client-side tool : Enable aligncheck and configure the corresponding code patterns on your repository Code patterns page. Enable Run analysis on your build server on your repository Settings , tab General , Repository analysis on your server . This setting enables Codacy to wait for the results of the local analysis before resuming the analysis of your commits. Set up an API token to authenticate on Codacy: If you're setting up one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up multiple repositories , obtain an account API Token and set the following environment variable to specify the account API token: export CODACY_API_TOKEN = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variable to specify your Codacy instance URL: export CODACY_API_BASE_URL = Download and run the Codacy Analysis CLI on the root of the repository, specifying the tool aligncheck. codacy-analysis-cli analyze --tool aligncheck \\ --allow-network \\ --upload \\ --verbose If you're using an account API token , you must also provide the flags --provider , --username , and --project . You can obtain the values for these flags from the URL of your repository dashboard on Codacy: codacy-analysis-cli analyze --provider \\ --username \\ --project \\ --tool aligncheck \\ --allow-network \\ --upload \\ --verbose The Codacy Analysis CLI runs aligncheck on your repository and uploads the results to Codacy so you can use them in your workflow.", "title": "Running aligncheck"}, {"location": "repositories-configure/local-analysis/running-aligncheck/#advanced-configuration", "text": "See the available Codacy Analysis CLI configuration flags to configure running aligncheck in more advanced scenarios.", "title": "Advanced configuration"}, {"location": "repositories-configure/local-analysis/running-deadcode/", "text": "Running deadcode # To run deadcode as a client-side tool : Enable deadcode and configure the corresponding code patterns on your repository Code patterns page. Enable Run analysis on your build server on your repository Settings , tab General , Repository analysis on your server . This setting enables Codacy to wait for the results of the local analysis before resuming the analysis of your commits. Set up an API token to authenticate on Codacy: If you're setting up one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up multiple repositories , obtain an account API Token and set the following environment variable to specify the account API token: export CODACY_API_TOKEN = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variable to specify your Codacy instance URL: export CODACY_API_BASE_URL = Download and run the Codacy Analysis CLI on the root of the repository, specifying the tool deadcode. codacy-analysis-cli analyze --tool deadcode \\ --allow-network \\ --upload \\ --verbose If you're using an account API token , you must also provide the flags --provider , --username , and --project . You can obtain the values for these flags from the URL of your repository dashboard on Codacy: codacy-analysis-cli analyze --provider \\ --username \\ --project \\ --tool deadcode \\ --allow-network \\ --upload \\ --verbose The Codacy Analysis CLI runs deadcode on your repository and uploads the results to Codacy so you can use them in your workflow. Advanced configuration # See the available Codacy Analysis CLI configuration flags to configure running deadcode in more advanced scenarios.", "title": "Running deadcode"}, {"location": "repositories-configure/local-analysis/running-deadcode/#running-deadcode", "text": "To run deadcode as a client-side tool : Enable deadcode and configure the corresponding code patterns on your repository Code patterns page. Enable Run analysis on your build server on your repository Settings , tab General , Repository analysis on your server . This setting enables Codacy to wait for the results of the local analysis before resuming the analysis of your commits. Set up an API token to authenticate on Codacy: If you're setting up one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up multiple repositories , obtain an account API Token and set the following environment variable to specify the account API token: export CODACY_API_TOKEN = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variable to specify your Codacy instance URL: export CODACY_API_BASE_URL = Download and run the Codacy Analysis CLI on the root of the repository, specifying the tool deadcode. codacy-analysis-cli analyze --tool deadcode \\ --allow-network \\ --upload \\ --verbose If you're using an account API token , you must also provide the flags --provider , --username , and --project . You can obtain the values for these flags from the URL of your repository dashboard on Codacy: codacy-analysis-cli analyze --provider \\ --username \\ --project \\ --tool deadcode \\ --allow-network \\ --upload \\ --verbose The Codacy Analysis CLI runs deadcode on your repository and uploads the results to Codacy so you can use them in your workflow.", "title": "Running deadcode"}, {"location": "repositories-configure/local-analysis/running-deadcode/#advanced-configuration", "text": "See the available Codacy Analysis CLI configuration flags to configure running deadcode in more advanced scenarios.", "title": "Advanced configuration"}, {"location": "repositories-configure/local-analysis/running-spotbugs/", "text": "Running SpotBugs # To run SpotBugs as a client-side tool : Enable SpotBugs and configure the corresponding code patterns on your repository Code patterns page. Enable Run analysis on your build server on your repository Settings , tab General , Repository analysis on your server . This setting enables Codacy to wait for the results of the local analysis before resuming the analysis of your commits. Set up an API token to authenticate on Codacy: If you're setting up one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up multiple repositories , obtain an account API Token and set the following environment variable to specify the account API token: export CODACY_API_TOKEN = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variable to specify your Codacy instance URL: export CODACY_API_BASE_URL = Compile your Java or Scala repository on your build server, as you would normally do. Download and run the Codacy Analysis CLI on the root of the repository, specifying the tool SpotBugs. codacy-analysis-cli analyze --tool spotbugs \\ --allow-network \\ --upload \\ --verbose If you're using an account API token , you must also provide the flags --provider , --username , and --project . You can obtain the values for these flags from the URL of your repository dashboard on Codacy: codacy-analysis-cli analyze --provider \\ --username \\ --project \\ --tool spotbugs \\ --allow-network \\ --upload \\ --verbose The Codacy Analysis CLI runs SpotBugs on the compiled classes of your repository and uploads the results to Codacy so you can use them in your workflow. Detecting sources and compiled classes # The Codacy Analysis CLI tries to find the compiled classes and map results to the source files automatically. If you use Maven, Gradle, or sbt the Codacy Analysis CLI also detects the default layouts automatically. If there is an issue with detection, you can configure these paths manually by adding a .codacy.yml Codacy configuration file to the root of the repository: --- engines: spotbugs: modules: - classesDirectories: [ \"core/target/classes\" ] sourceDirectories: [ \"core/src/main\" ] - classesDirectories: [ \"api/target/classes\" ] sourceDirectories: [ \"api/src/main\" ] Increasing the timeout to run SpotBugs # When running SpotBugs on the compiled classes of larger projects, the default execution timeout of 15 minutes may not be enough for SpotBugs to complete the analysis. To increase the timeout that SpotBugs has to execute, use the option --tool-timeout when running the Codacy Analysis CLI. For example, use --tool-timeout 1hour to set the timeout to one hour. Advanced configuration # See the available Codacy Analysis CLI configuration flags to configure running SpotBugs in more advanced scenarios.", "title": "Running SpotBugs"}, {"location": "repositories-configure/local-analysis/running-spotbugs/#running-spotbugs", "text": "To run SpotBugs as a client-side tool : Enable SpotBugs and configure the corresponding code patterns on your repository Code patterns page. Enable Run analysis on your build server on your repository Settings , tab General , Repository analysis on your server . This setting enables Codacy to wait for the results of the local analysis before resuming the analysis of your commits. Set up an API token to authenticate on Codacy: If you're setting up one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up multiple repositories , obtain an account API Token and set the following environment variable to specify the account API token: export CODACY_API_TOKEN = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variable to specify your Codacy instance URL: export CODACY_API_BASE_URL = Compile your Java or Scala repository on your build server, as you would normally do. Download and run the Codacy Analysis CLI on the root of the repository, specifying the tool SpotBugs. codacy-analysis-cli analyze --tool spotbugs \\ --allow-network \\ --upload \\ --verbose If you're using an account API token , you must also provide the flags --provider , --username , and --project . You can obtain the values for these flags from the URL of your repository dashboard on Codacy: codacy-analysis-cli analyze --provider \\ --username \\ --project \\ --tool spotbugs \\ --allow-network \\ --upload \\ --verbose The Codacy Analysis CLI runs SpotBugs on the compiled classes of your repository and uploads the results to Codacy so you can use them in your workflow.", "title": "Running SpotBugs"}, {"location": "repositories-configure/local-analysis/running-spotbugs/#detecting-sources-and-compiled-classes", "text": "The Codacy Analysis CLI tries to find the compiled classes and map results to the source files automatically. If you use Maven, Gradle, or sbt the Codacy Analysis CLI also detects the default layouts automatically. If there is an issue with detection, you can configure these paths manually by adding a .codacy.yml Codacy configuration file to the root of the repository: --- engines: spotbugs: modules: - classesDirectories: [ \"core/target/classes\" ] sourceDirectories: [ \"core/src/main\" ] - classesDirectories: [ \"api/target/classes\" ] sourceDirectories: [ \"api/src/main\" ]", "title": "Detecting sources and compiled classes"}, {"location": "repositories-configure/local-analysis/running-spotbugs/#increasing-the-timeout-to-run-spotbugs", "text": "When running SpotBugs on the compiled classes of larger projects, the default execution timeout of 15 minutes may not be enough for SpotBugs to complete the analysis. To increase the timeout that SpotBugs has to execute, use the option --tool-timeout when running the Codacy Analysis CLI. For example, use --tool-timeout 1hour to set the timeout to one hour.", "title": "Increasing the timeout to run SpotBugs"}, {"location": "repositories-configure/local-analysis/running-spotbugs/#advanced-configuration", "text": "See the available Codacy Analysis CLI configuration flags to configure running SpotBugs in more advanced scenarios.", "title": "Advanced configuration"}, {"location": "repositories-coverage/commits/", "text": "Coverage Commits page # The Coverage Commits page displays an overview of the commits in your repository, such as the analysis status and coverage for each commit. This allows you to monitor the evolution of coverage in your repository per commit. By default, the page lists the commits on the main branch of your repository but if you have more than one branch enabled you can use the drop-down list at the top of the page to display commits on other branches. Click a specific commit to see detailed information about the code coverage changes introduced by that commit. The next sections describe each area of the commit detail page. Commit information # This area displays detailed information about the commit: Commit message Committer, SHA hash, and parent commits Date Link to the commit on your Git provider Commit coverage overview # This area displays the coverage gate status and an overview of the coverage metrics for the commit: The quality gate status is either Up to coverage standards or Not up to coverage standards depending on the coverage gate rules for your repository. If you don't have any rules enabled for commits, the status is always Up to coverage standards . The following coverage metrics for the commit, displayed either as a positive or negative variation , or no variation (represented by = ): Coverage variation: Variation of code coverage percentage relative to the parent commit Total coverage: Coverage value of the repository at this commit Note Learn how Codacy calculates the code quality metrics in more detail: Which coverage metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the coverage gate rules for your repository: Green: The metric passes the coverage gate Red: The metric fails the coverage gate Gray: There aren't coverage gate rules configured for the metric or the value doesn't impact the coverage gate Diff tab # The Diff tab displays a line-by-line view of the coverage variation introduced by the commit. It includes the following areas: A list of files modified by the commit, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the commit The coverage variation introduced by the commit (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line Files tab # The Files tab displays the coverage variation that the commit introduces to the files in your repository relative to the parent commit, displayed either as a positive or negative variation , or no variation (represented by = ): The option Show also files without coverage changes allows you to list all files that the commit updates, even if their coverage doesn't change.", "title": "Coverage Commits page"}, {"location": "repositories-coverage/commits/#coverage-commits-page", "text": "The Coverage Commits page displays an overview of the commits in your repository, such as the analysis status and coverage for each commit. This allows you to monitor the evolution of coverage in your repository per commit. By default, the page lists the commits on the main branch of your repository but if you have more than one branch enabled you can use the drop-down list at the top of the page to display commits on other branches. Click a specific commit to see detailed information about the code coverage changes introduced by that commit. The next sections describe each area of the commit detail page.", "title": "Coverage Commits page"}, {"location": "repositories-coverage/commits/#info", "text": "This area displays detailed information about the commit: Commit message Committer, SHA hash, and parent commits Date Link to the commit on your Git provider", "title": "Commit information"}, {"location": "repositories-coverage/commits/#coverage-overview", "text": "This area displays the coverage gate status and an overview of the coverage metrics for the commit: The quality gate status is either Up to coverage standards or Not up to coverage standards depending on the coverage gate rules for your repository. If you don't have any rules enabled for commits, the status is always Up to coverage standards . The following coverage metrics for the commit, displayed either as a positive or negative variation , or no variation (represented by = ): Coverage variation: Variation of code coverage percentage relative to the parent commit Total coverage: Coverage value of the repository at this commit Note Learn how Codacy calculates the code quality metrics in more detail: Which coverage metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the coverage gate rules for your repository: Green: The metric passes the coverage gate Red: The metric fails the coverage gate Gray: There aren't coverage gate rules configured for the metric or the value doesn't impact the coverage gate", "title": "Commit coverage overview"}, {"location": "repositories-coverage/commits/#diff-tab", "text": "The Diff tab displays a line-by-line view of the coverage variation introduced by the commit. It includes the following areas: A list of files modified by the commit, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the commit The coverage variation introduced by the commit (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line", "title": "Diff tab"}, {"location": "repositories-coverage/commits/#files-tab", "text": "The Files tab displays the coverage variation that the commit introduces to the files in your repository relative to the parent commit, displayed either as a positive or negative variation , or no variation (represented by = ): The option Show also files without coverage changes allows you to list all files that the commit updates, even if their coverage doesn't change.", "title": "Files tab"}, {"location": "repositories-coverage/files/", "text": "Coverage Files page # The Coverage Files page displays the current code coverage information for each analyzed file in your enabled repository branches . By default, the page lists the files on the main branch of your repository but if you have more than one branch enabled you can use the drop-down list at the top of the page to display files on other branches. Codacy displays the files in alphabetical order by default, but you can sort the list by each column to help you identify which files need more test coverage. Note You can use the Codacy API to generate reports or obtain coverage metrics for the files in your repositories in a more flexible way. Use the search box to filter the list and find specific files: File details # Click a specific file to see more detailed coverage information for that file, including: Coverable lines: Source lines of code that can be covered by tests Covered lines: Source lines of code that are covered by tests Coverage: Percentage of coverable source lines of code that are covered by tests The page also shows the source code of the file and identifies which lines of code are covered by tests (green background) or not (red background). Why are some files missing? # The Files page only displays files in your repository that were analyzed by Codacy. This means that some of your files may be missing from the list, for example: You're viewing the incorrect branch Not all files may exist in all branches of your repositories. Make sure that you're displaying files for the correct branch. The file might be ignored The Files page doesn't display ignored files that aren't meant to be analyzed, including the files that Codacy ignores by default . The file has an extension that is not on the list of supported extensions Codacy supports a list of file extensions associated with each language. Codacy doesn't analyze or display files with extensions that aren't associated with a language. The file might be too big Codacy doesn't analyze or display files that are over a certain size. Read more details for information on how to overcome this limit. See also # Which metrics does Codacy calculate? Using the Codacy API to obtain code quality metrics for files", "title": "Coverage Files page"}, {"location": "repositories-coverage/files/#coverage-files-page", "text": "The Coverage Files page displays the current code coverage information for each analyzed file in your enabled repository branches . By default, the page lists the files on the main branch of your repository but if you have more than one branch enabled you can use the drop-down list at the top of the page to display files on other branches. Codacy displays the files in alphabetical order by default, but you can sort the list by each column to help you identify which files need more test coverage. Note You can use the Codacy API to generate reports or obtain coverage metrics for the files in your repositories in a more flexible way. Use the search box to filter the list and find specific files:", "title": "Coverage Files page"}, {"location": "repositories-coverage/files/#file-details", "text": "Click a specific file to see more detailed coverage information for that file, including: Coverable lines: Source lines of code that can be covered by tests Covered lines: Source lines of code that are covered by tests Coverage: Percentage of coverable source lines of code that are covered by tests The page also shows the source code of the file and identifies which lines of code are covered by tests (green background) or not (red background).", "title": "File details"}, {"location": "repositories-coverage/files/#missing-files", "text": "The Files page only displays files in your repository that were analyzed by Codacy. This means that some of your files may be missing from the list, for example: You're viewing the incorrect branch Not all files may exist in all branches of your repositories. Make sure that you're displaying files for the correct branch. The file might be ignored The Files page doesn't display ignored files that aren't meant to be analyzed, including the files that Codacy ignores by default . The file has an extension that is not on the list of supported extensions Codacy supports a list of file extensions associated with each language. Codacy doesn't analyze or display files with extensions that aren't associated with a language. The file might be too big Codacy doesn't analyze or display files that are over a certain size. Read more details for information on how to overcome this limit.", "title": "Why are some files missing?"}, {"location": "repositories-coverage/files/#see-also", "text": "Which metrics does Codacy calculate? Using the Codacy API to obtain code quality metrics for files", "title": "See also"}, {"location": "repositories-coverage/pull-requests/", "text": "Coverage Pull Requests page # The Coverage Pull Requests page displays an overview of the pull requests in your repository, such as the status and coverage metrics for each pull request. This allows you to monitor the coverage of the work in progress in your repository. By default, the page lists open pull requests but you can click the Closed tab at the top of the list to display the closed pull requests. Click a specific pull request to see detailed coverage information for that pull request. The next sections describe each area of the pull request detail page. Pull request information # This area displays detailed information about the pull request: Pull request title and pull request status Pull request author, pull request branch, target branch, and pull request identifier on the Git provider Last updated date of the pull request Link to the pull request on your Git provider Link to reanalyze the pull request Link to view analysis logs Pull request coverage overview # This area displays the coverage gate status and an overview of the coverage metrics for the pull request: The quality gate status is either Up to coverage standards or Not up to coverage standards depending on the coverage gate rules for your repository. If you don't have any rules enabled for pull requests, the status is always Up to coverage standards . The following coverage metrics for the pull request, displayed either as a positive or negative variation , no variation (represented by = ), or not applicable (represented by \u2205 ): Diff coverage: Code coverage of the coverable lines added or changed by the pull request, or \u2205 (not applicable) if there aren't any coverable lines added or changed Coverage variation: Variation of code coverage percentage relative to the target branch of the pull request Note Learn how Codacy calculates the code quality metrics in more detail: Which coverage metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the coverage gate rules for your repository: Green: The metric passes the coverage gate Red: The metric fails the coverage gate Gray: There aren't coverage gate rules configured for the metric or the value doesn't impact the coverage gate Diff tab # The Diff tab displays a line-by-line view of the coverage variation introduced by the pull request. It includes the following areas: A list of files modified by the pull request, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the pull request The coverage variation introduced by the pull request (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line Files tab # The Files tab displays the coverage variation that the pull request introduces to the files in your repository relative to the target branch, displayed either as a positive or negative variation , or no variation (represented by = ): The option Show also files without coverage changes allows you to list all files that the pull request updates, even if their coverage doesn't change. Commits tab # The Commits tab displays an overview of each commit included in the pull request, such as the status and coverage metrics for each commit. Click a specific commit to see detailed information about that commit . Viewing analysis logs # Analysis logs can help you spot any issues with the coverage analysis, such as missing coverage reports. To access the coverage analysis logs, click the View logs link in the pull request information area. This opens a modal listing coverage reports received for the common ancestor commit and the head commit of the pull request. See also # Which metrics does Codacy calculate?", "title": "Coverage Pull Requests page"}, {"location": "repositories-coverage/pull-requests/#coverage-pull-requests-page", "text": "The Coverage Pull Requests page displays an overview of the pull requests in your repository, such as the status and coverage metrics for each pull request. This allows you to monitor the coverage of the work in progress in your repository. By default, the page lists open pull requests but you can click the Closed tab at the top of the list to display the closed pull requests. Click a specific pull request to see detailed coverage information for that pull request. The next sections describe each area of the pull request detail page.", "title": "Coverage Pull Requests page"}, {"location": "repositories-coverage/pull-requests/#info", "text": "This area displays detailed information about the pull request: Pull request title and pull request status Pull request author, pull request branch, target branch, and pull request identifier on the Git provider Last updated date of the pull request Link to the pull request on your Git provider Link to reanalyze the pull request Link to view analysis logs", "title": "Pull request information"}, {"location": "repositories-coverage/pull-requests/#coverage-overview", "text": "This area displays the coverage gate status and an overview of the coverage metrics for the pull request: The quality gate status is either Up to coverage standards or Not up to coverage standards depending on the coverage gate rules for your repository. If you don't have any rules enabled for pull requests, the status is always Up to coverage standards . The following coverage metrics for the pull request, displayed either as a positive or negative variation , no variation (represented by = ), or not applicable (represented by \u2205 ): Diff coverage: Code coverage of the coverable lines added or changed by the pull request, or \u2205 (not applicable) if there aren't any coverable lines added or changed Coverage variation: Variation of code coverage percentage relative to the target branch of the pull request Note Learn how Codacy calculates the code quality metrics in more detail: Which coverage metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the coverage gate rules for your repository: Green: The metric passes the coverage gate Red: The metric fails the coverage gate Gray: There aren't coverage gate rules configured for the metric or the value doesn't impact the coverage gate", "title": "Pull request coverage overview"}, {"location": "repositories-coverage/pull-requests/#diff-tab", "text": "The Diff tab displays a line-by-line view of the coverage variation introduced by the pull request. It includes the following areas: A list of files modified by the pull request, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the pull request The coverage variation introduced by the pull request (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line", "title": "Diff tab"}, {"location": "repositories-coverage/pull-requests/#files-tab", "text": "The Files tab displays the coverage variation that the pull request introduces to the files in your repository relative to the target branch, displayed either as a positive or negative variation , or no variation (represented by = ): The option Show also files without coverage changes allows you to list all files that the pull request updates, even if their coverage doesn't change.", "title": "Files tab"}, {"location": "repositories-coverage/pull-requests/#commits-tab", "text": "The Commits tab displays an overview of each commit included in the pull request, such as the status and coverage metrics for each commit. Click a specific commit to see detailed information about that commit .", "title": "Commits tab"}, {"location": "repositories-coverage/pull-requests/#viewing-analysis-logs", "text": "Analysis logs can help you spot any issues with the coverage analysis, such as missing coverage reports. To access the coverage analysis logs, click the View logs link in the pull request information area. This opens a modal listing coverage reports received for the common ancestor commit and the head commit of the pull request.", "title": "Viewing analysis logs"}, {"location": "repositories-coverage/pull-requests/#see-also", "text": "Which metrics does Codacy calculate?", "title": "See also"}, {"location": "repositories-coverage/repository-dashboard/", "text": "Coverage Repository Dashboard # The Coverage Repository Dashboard provides an overview of the repository coverage and items that require your attention. To access your Repository Dashboard, select a repository from the Repositories list and select Dashboard on the left navigation sidebar. Tip You can share the URL of the Repository Dashboard for your public repositories to allow other people to see your repository coverage metrics, even if they aren't registered on Codacy. The top of the Repository Dashboard displays: The name of the repository A drop-down list that selects which branch of your repository to display on the dashboard On the Repository Dashboard you have the following areas to help you monitor your repository: Coverage evolution chart Coverage Open pull requests The following sections provide a detailed overview of each dashboard area. Coverage evolution chart # The Coverage evolution chart displays the evolution of the repository code coverage . Click on Last 3 months , Last 31 days , or Last 7 days to select the time interval of the historical data to display on the chart. The tab displays the following information: A green or red indicator depending if coverage is within the acceptable level or not The current coverage value The coverage variation introduced by the last commit Note The chart only displays a value if Codacy received coverage data for the most recent commit. This is because one commit can easily change the size or number of files on the repository, or even remove some files that had coverage information. The chart also displays the trendline based on the past behavior and the coverage goal defined on the repository quality settings . Coverage # The Coverage area displays the percentage of lines of code on the selected branch that are covered by tests versus the coverage goal defined in the quality settings of the repository, as well as the number of files: Without coverage With coverage not up to standards (based on the coverage goal) With coverage up to standards (based on the coverage goal) Click See all files to open the list of files in the repository. Tip If you don't have coverage set up for your repository yet, the Coverage area provides you with instructions on how to add coverage for your repository . Open pull requests # The Open pull requests area displays the last updated pull requests and the split between the status of all open pull requests in your repository: Up to coverage standards: Pull requests that meet the minimum coverage levels Not up to coverage standards: Pull requests that failed to meet at least one of the coverage gate rules defined for the repository No information: Pull requests that didn't receive the coverage reports required for Codacy to calculate the coverage metrics Click a bar segment to display only pull requests with the corresponding status. To see the details of pull requests, click a pull request from the list or click See all pull requests to open the list of pull requests in the repository. See also # Which metrics does Codacy calculate? Using the Codacy API to obtain code quality metrics for files", "title": "Coverage Repository Dashboard"}, {"location": "repositories-coverage/repository-dashboard/#coverage-repository-dashboard", "text": "The Coverage Repository Dashboard provides an overview of the repository coverage and items that require your attention. To access your Repository Dashboard, select a repository from the Repositories list and select Dashboard on the left navigation sidebar. Tip You can share the URL of the Repository Dashboard for your public repositories to allow other people to see your repository coverage metrics, even if they aren't registered on Codacy. The top of the Repository Dashboard displays: The name of the repository A drop-down list that selects which branch of your repository to display on the dashboard On the Repository Dashboard you have the following areas to help you monitor your repository: Coverage evolution chart Coverage Open pull requests The following sections provide a detailed overview of each dashboard area.", "title": "Coverage Repository Dashboard"}, {"location": "repositories-coverage/repository-dashboard/#coverage-evolution-chart", "text": "The Coverage evolution chart displays the evolution of the repository code coverage . Click on Last 3 months , Last 31 days , or Last 7 days to select the time interval of the historical data to display on the chart. The tab displays the following information: A green or red indicator depending if coverage is within the acceptable level or not The current coverage value The coverage variation introduced by the last commit Note The chart only displays a value if Codacy received coverage data for the most recent commit. This is because one commit can easily change the size or number of files on the repository, or even remove some files that had coverage information. The chart also displays the trendline based on the past behavior and the coverage goal defined on the repository quality settings .", "title": "Coverage evolution chart"}, {"location": "repositories-coverage/repository-dashboard/#coverage", "text": "The Coverage area displays the percentage of lines of code on the selected branch that are covered by tests versus the coverage goal defined in the quality settings of the repository, as well as the number of files: Without coverage With coverage not up to standards (based on the coverage goal) With coverage up to standards (based on the coverage goal) Click See all files to open the list of files in the repository. Tip If you don't have coverage set up for your repository yet, the Coverage area provides you with instructions on how to add coverage for your repository .", "title": "Coverage"}, {"location": "repositories-coverage/repository-dashboard/#open-pull-requests", "text": "The Open pull requests area displays the last updated pull requests and the split between the status of all open pull requests in your repository: Up to coverage standards: Pull requests that meet the minimum coverage levels Not up to coverage standards: Pull requests that failed to meet at least one of the coverage gate rules defined for the repository No information: Pull requests that didn't receive the coverage reports required for Codacy to calculate the coverage metrics Click a bar segment to display only pull requests with the corresponding status. To see the details of pull requests, click a pull request from the list or click See all pull requests to open the list of pull requests in the repository.", "title": "Open pull requests"}, {"location": "repositories-coverage/repository-dashboard/#see-also", "text": "Which metrics does Codacy calculate? Using the Codacy API to obtain code quality metrics for files", "title": "See also"}]} \ No newline at end of file +{"config": {"indexing": "full", "lang": ["en"], "min_search_length": 3, "prebuild_index": false, "separator": "[\\s\\-]+"}, "docs": [{"location": "", "text": "Documentation home # Getting started Adding your first repository (5 min) Sign up with your Git provider so that Codacy can have access to your Git provider organizations and members. You can then add any repository you have access to with one click. Supported languages Codacy supports over 40 programming languages and infrastructure-as-code platforms out of the box, and regularly adds support for new languages and tools. Using Codacy Creating and managing an organization Codacy automatically imports your Git provider organizations and members. Changes reflect on Codacy in real time and you can manage people who joined your organization on Codacy. Setting up integrations Configure Codacy to provide analysis feedback and status checks directly on your pull requests. Most popular topics Managing people in organizations Invite your teammates to join Codacy to analyze their commits on private repositories. Adding coverage to your repository Set up your repositories to show code coverage reports directly on Codacy. Using the Codacy API Retrieve and analyze data from Codacy and perform configuration changes programmatically", "title": "Documentation home"}, {"location": "#documentation-home", "text": "Getting started Adding your first repository (5 min) Sign up with your Git provider so that Codacy can have access to your Git provider organizations and members. You can then add any repository you have access to with one click. Supported languages Codacy supports over 40 programming languages and infrastructure-as-code platforms out of the box, and regularly adds support for new languages and tools. Using Codacy Creating and managing an organization Codacy automatically imports your Git provider organizations and members. Changes reflect on Codacy in real time and you can manage people who joined your organization on Codacy. Setting up integrations Configure Codacy to provide analysis feedback and status checks directly on your pull requests.", "title": "Documentation home"}, {"location": "special-thanks/", "text": "Special thanks # We would like to thank everyone who helped us greatly . The names on these lists contributed immensely to what Codacy is today. Open source tools # In addition to in-house built rules, we use open source tools for many of our static analysis. We want to express our gratitude to everyone who contributed to those tools. SonarC# PMD Brakeman RuboCop SimpleCov CoffeeLint Pylint SonarVB PHPMD PHP_CodeSniffer Mocha Scalastyle CSSLint radon Clone Digger PHPCPD plato sloc LessLinter Hadolint SCSSLint Credo PSScriptAnalyzer Ameba Language support contributions # These are the tools integrated on Codacy by our own users! Without them, we wouldn't have support for these languages. Language Who made it possible CoffeeScript Ryan Delaney Elixir Grant McLendon PowerShell Aditya Patwardhan Crystal Vitalii Elenhaupt Collaborators # For all the people who helped us so much, we want to give a big shout out and thanks! David Pate Adriaan Moors Iulian Dragos Jakob Pupke Mathieu Demarne Ryan Shipp Eugene Burmako", "title": "Special thanks"}, {"location": "special-thanks/#special-thanks", "text": "We would like to thank everyone who helped us greatly . The names on these lists contributed immensely to what Codacy is today.", "title": "Special thanks"}, {"location": "special-thanks/#open-source-tools", "text": "In addition to in-house built rules, we use open source tools for many of our static analysis. We want to express our gratitude to everyone who contributed to those tools. SonarC# PMD Brakeman RuboCop SimpleCov CoffeeLint Pylint SonarVB PHPMD PHP_CodeSniffer Mocha Scalastyle CSSLint radon Clone Digger PHPCPD plato sloc LessLinter Hadolint SCSSLint Credo PSScriptAnalyzer Ameba", "title": "Open source tools"}, {"location": "special-thanks/#language-support-contributions", "text": "These are the tools integrated on Codacy by our own users! Without them, we wouldn't have support for these languages. Language Who made it possible CoffeeScript Ryan Delaney Elixir Grant McLendon PowerShell Aditya Patwardhan Crystal Vitalii Elenhaupt", "title": "Language support contributions"}, {"location": "special-thanks/#collaborators", "text": "For all the people who helped us so much, we want to give a big shout out and thanks! David Pate Adriaan Moors Iulian Dragos Jakob Pupke Mathieu Demarne Ryan Shipp Eugene Burmako", "title": "Collaborators"}, {"location": "account/emails/", "text": "Emails # To manage the email addresses associated with your account and your email notifications, click on your avatar on the top right-hand corner and open Your account , page Emails . Updating your email addresses # Codacy automatically links to your Codacy account the email addresses from the Git provider associated with your current session. On the Emails page, you can verify which email addresses are linked to your Codacy account. Note For GitHub , if you have email privacy enabled on the provider, Codacy doesn't show your private emails and uses another available email address when displaying your personal details on lists, search filters, or activity. To update the email addresses associated with your Codacy account, do the following: Configure your Git email address . This ensures that commits are attributed to you. Update your email addresses on your Git provider ( GitHub , Bitbucket , or GitLab ). Log out and log back in to Codacy. Tip If the updates are still not reflected on Codacy, navigate to the access management page, revoke the relevant Git provider integration, then log out and back in to Codacy using the same provider. Note When developers commit from GitHub or Bitbucket , Codacy automatically associates all the commit email addresses from the same Git provider user with a single Codacy committer. For developers that never logged in to the Codacy app, this mechanism requires that they set their Git email address and add all their email addresses to their GitHub account or Bitbucket account . Setting your Git email address # Unless you explicitly configure your email address , Git automatically uses an email address based on the username and hostname of your workstation, and associates this email address with your commits. To check which email address your local Git installation is using, run the following command on your workstation: git config user.email If the returned email address isn't one of the email addresses associated with your Git provider account, configure Git to use one of those email addresses instead: git config --global user.email you@example.com Important Make sure that your email address doesn't include any extra characters such as quotes ( \"\" or '' ). Managing your email notifications # Codacy can send you an email whenever there are new analysis results on your repositories with the list of found issues and the changes that created them. Codacy sends all email notifications to your default email address, and you can change your default email address by clicking make default next to another email address. Configure the notifications that you wish to receive under Repository notifications : Per commit: Codacy will send you an email for each analyzed commit. Per pull request: Codacy will send you an email for each analyzed pull request. Only my activity: By default, Codacy will only send you emails about your own commits and pull requests. Turn off this setting to receive emails for commits and pull requests made by other people as well. Tip To turn off all email notifications, disable the settings Per commit and Per pull request .", "title": "Emails"}, {"location": "account/emails/#emails", "text": "To manage the email addresses associated with your account and your email notifications, click on your avatar on the top right-hand corner and open Your account , page Emails .", "title": "Emails"}, {"location": "account/emails/#updating", "text": "Codacy automatically links to your Codacy account the email addresses from the Git provider associated with your current session. On the Emails page, you can verify which email addresses are linked to your Codacy account. Note For GitHub , if you have email privacy enabled on the provider, Codacy doesn't show your private emails and uses another available email address when displaying your personal details on lists, search filters, or activity. To update the email addresses associated with your Codacy account, do the following: Configure your Git email address . This ensures that commits are attributed to you. Update your email addresses on your Git provider ( GitHub , Bitbucket , or GitLab ). Log out and log back in to Codacy. Tip If the updates are still not reflected on Codacy, navigate to the access management page, revoke the relevant Git provider integration, then log out and back in to Codacy using the same provider. Note When developers commit from GitHub or Bitbucket , Codacy automatically associates all the commit email addresses from the same Git provider user with a single Codacy committer. For developers that never logged in to the Codacy app, this mechanism requires that they set their Git email address and add all their email addresses to their GitHub account or Bitbucket account .", "title": "Updating your email addresses"}, {"location": "account/emails/#managing-your-email-notifications", "text": "Codacy can send you an email whenever there are new analysis results on your repositories with the list of found issues and the changes that created them. Codacy sends all email notifications to your default email address, and you can change your default email address by clicking make default next to another email address. Configure the notifications that you wish to receive under Repository notifications : Per commit: Codacy will send you an email for each analyzed commit. Per pull request: Codacy will send you an email for each analyzed pull request. Only my activity: By default, Codacy will only send you emails about your own commits and pull requests. Turn off this setting to receive emails for commits and pull requests made by other people as well. Tip To turn off all email notifications, disable the settings Per commit and Per pull request .", "title": "Managing your email notifications"}, {"location": "account/managing-your-profile/", "text": "Managing your profile # To manage your profile information such as your name and avatar, click on your avatar on the top right-hand corner and select Your account . Changing your name or avatar # To change your avatar, sign up or log in at Gravatar using the same email address that you used to log into Codacy. The avatar that you define there will be automatically used as your avatar on Codacy. Note Organization avatars aren't editable at the moment. To change your name, update the field Name and click the button Update profile . Deleting your account # When you delete your account on Codacy: Your profile information and all data related to your personal repositories are completely removed from Codacy Codacy will stop analyzing any repositories added to Codacy using your account This operation doesn't make any changes on your Git provider. To delete your account, click the button Delete account and confirm that you really want to proceed. Note If you're the last organization admin of any of your organizations, you must either add someone else as an owner or delete those organizations before you can delete your account.", "title": "Managing your profile"}, {"location": "account/managing-your-profile/#managing-your-profile", "text": "To manage your profile information such as your name and avatar, click on your avatar on the top right-hand corner and select Your account .", "title": "Managing your profile"}, {"location": "account/managing-your-profile/#changing-your-name-or-avatar", "text": "To change your avatar, sign up or log in at Gravatar using the same email address that you used to log into Codacy. The avatar that you define there will be automatically used as your avatar on Codacy. Note Organization avatars aren't editable at the moment. To change your name, update the field Name and click the button Update profile .", "title": "Changing your name or avatar"}, {"location": "account/managing-your-profile/#deleting-your-account", "text": "When you delete your account on Codacy: Your profile information and all data related to your personal repositories are completely removed from Codacy Codacy will stop analyzing any repositories added to Codacy using your account This operation doesn't make any changes on your Git provider. To delete your account, click the button Delete account and confirm that you really want to proceed. Note If you're the last organization admin of any of your organizations, you must either add someone else as an owner or delete those organizations before you can delete your account.", "title": "Deleting your account"}, {"location": "account/user-session-management/", "text": "User session management # To reduce the risk of unauthorized access to your account, Codacy sets automatic expiration timeouts for every session. When a session expires, Codacy invalidates the session both on the client and server side, and creates a new session. Idle session timeout # The idle session timeout on the Codacy app is 30 minutes . In the absence of user activity during this period, such as typing or using the mouse, Codacy logs out the user and invalidates the session. Absolute session timeout # The absolute session timeout on the Codacy app is 8 hours . When an active session reaches this maximum period, Codacy logs out the user and invalidates the session.", "title": "User session management"}, {"location": "account/user-session-management/#user-session-management", "text": "To reduce the risk of unauthorized access to your account, Codacy sets automatic expiration timeouts for every session. When a session expires, Codacy invalidates the session both on the client and server side, and creates a new session.", "title": "User session management"}, {"location": "account/user-session-management/#idle-session-timeout", "text": "The idle session timeout on the Codacy app is 30 minutes . In the absence of user activity during this period, such as typing or using the mouse, Codacy logs out the user and invalidates the session.", "title": "Idle session timeout"}, {"location": "account/user-session-management/#absolute-session-timeout", "text": "The absolute session timeout on the Codacy app is 8 hours . When an active session reaches this maximum period, Codacy logs out the user and invalidates the session.", "title": "Absolute session timeout"}, {"location": "chart/", "text": "Installing Codacy Self-hosted # This documentation guides you on how to install Codacy Self-hosted on Kubernetes or MicroK8s. Important If you're running the legacy Codacy Self-hosted solution running on Docker please contact support@codacy.com so that we can assist you with the migration to Codacy Self-hosted running on Kubernetes or MicroK8s. To install Codacy you must complete these main steps: Setting up the system requirements Ensure that your infrastructure meets the hardware and system requirements to run Codacy. Installing Codacy Install Codacy on the cluster using our Helm chart that includes all the necessary components and dependencies. Configuring Codacy Configure integrations with Git providers and set up monitoring. The next sections include detailed instructions on how to complete each step of the installation process. Make sure that you complete each step before advancing to the next one. 1. Setting up the system requirements # Before you start, you must prepare and provision the database server and Kubernetes or MicroK8s cluster that will host Codacy. Carefully review and set up the system requirements to run Codacy by following the instructions on the page below: System requirements Optionally, you can follow one of the guides below to quickly create a new Kubernetes or MicroK8s cluster that satisfies the characteristics described in the system requirements: Creating an Amazon EKS cluster Creating a MicroK8s cluster 2. Installing Codacy # Install Codacy on an existing cluster using our Helm chart: Make sure that you have the following tools installed on your machine: kubectl within one minor version difference of your cluster Important If you're using MicroK8s you don't need to install kubectl because you will execute all kubectl commands as microk8s.kubectl commands instead. To simplify this, check how to create an alias for kubectl . Helm version >= 3.9 Create a cluster namespace called codacy that will group all resources related to Codacy. kubectl create namespace codacy Add the Docker registry credentials provided by Codacy together with your license to a cluster Secret. This is necessary because some Codacy Docker images are currently private. Substitute and with the Docker registry username and password and run the following command: kubectl create secret docker-registry docker-credentials \\ --docker-username = \\ --docker-password = \\ --namespace codacy Download the template file values-production.yaml and use a text editor of your choice to edit the value placeholders as described in the comments. Create an address record on your DNS provider mapping the hostname you used in the previous step to the IP address of your Ingress controller. Important If you're using MicroK8s you must map the hostname to the public IP address of the machine running MicroK8s. Add Codacy's chart repository to your Helm client and install the Codacy chart using the file values-production.yaml created previously. Important If you're using MicroK8s you must download and use the file values-microk8s.yaml together with the file values-production.yaml by uncommenting the last line in the helm upgrade command below. helm repo add codacy-stable https://charts.codacy.com/stable/ helm repo update helm upgrade --install codacy codacy-stable/codacy \\ --namespace codacy \\ --version 14 .0.0 \\ --values values-production.yaml # --values values-microk8s.yaml By now all the Codacy pods should be starting in the cluster. Run the following command and wait for all the pods to have the status Running , which can take several minutes: $ kubectl get pods -n codacy NAME READY STATUS RESTARTS AGE codacy-api-f7897b965-fgn67 1 /1 Running 0 8m57s codacy-api-f7897b965-kkqsx 1 /1 Running 0 8m57s codacy-crow-7c957d45f6-b8zp2 1 /1 Running 2 8m57s codacy-crowdb-0 1 /1 Running 0 8m57s codacy-engine-549bcb69d9-cgrqf 1 /1 Running 1 8m57s codacy-engine-549bcb69d9-sh5f4 1 /1 Running 1 8m57s codacy-fluentdoperator-x5vr2 2 /2 Running 0 8m57s codacy-listener-868b784dcf-npdfh 1 /1 Running 0 8m57s codacy-listenerdb-0 1 /1 Running 0 8m57s codacy-minio-7cfdc7b4f4-254gz 1 /1 Running 0 8m57s codacy-nfsserverprovisioner-0 1 /1 Running 0 8m57s codacy-portal-774d9fc596-rwqj5 1 /1 Running 2 8m56s codacy-rabbitmq-ha-0 1 /1 Running 0 8m57s codacy-ragnaros-69459775b5-hmj4d 1 /1 Running 3 8m57s codacy-remote-provider-service-8fb8556b-rr4ws 1 /1 Running 0 8m56s codacy-worker-manager-656dbf8d6d-n4j7c 1 /1 Running 0 8m57s 3. Configuring Codacy # After successfully installing Codacy on your cluster, you're now ready to perform the post-install configuration steps: Use a browser to navigate to the Codacy hostname previously configured on the file values-production.yaml . Log in using your Git provider account. This automatically creates a Codacy administrator account with your credentials. Follow Codacy's onboarding process, which will guide you through the following steps: Configuring one or more of the following supported integrations: GitHub Cloud GitHub Enterprise GitLab Cloud GitLab Enterprise Bitbucket Cloud Bitbucket Server Email Creating an initial organization Inviting users to Codacy As a last step we recommend that you set up monitoring on your Codacy instance. If you run into any issues while configuring Codacy, be sure to check our troubleshooting guide for more help.", "title": "Installing Codacy Self-hosted"}, {"location": "chart/#installing-codacy-self-hosted", "text": "This documentation guides you on how to install Codacy Self-hosted on Kubernetes or MicroK8s. Important If you're running the legacy Codacy Self-hosted solution running on Docker please contact support@codacy.com so that we can assist you with the migration to Codacy Self-hosted running on Kubernetes or MicroK8s. To install Codacy you must complete these main steps: Setting up the system requirements Ensure that your infrastructure meets the hardware and system requirements to run Codacy. Installing Codacy Install Codacy on the cluster using our Helm chart that includes all the necessary components and dependencies. Configuring Codacy Configure integrations with Git providers and set up monitoring. The next sections include detailed instructions on how to complete each step of the installation process. Make sure that you complete each step before advancing to the next one.", "title": "Installing Codacy Self-hosted"}, {"location": "chart/#1-setting-up-the-system-requirements", "text": "Before you start, you must prepare and provision the database server and Kubernetes or MicroK8s cluster that will host Codacy. Carefully review and set up the system requirements to run Codacy by following the instructions on the page below: System requirements Optionally, you can follow one of the guides below to quickly create a new Kubernetes or MicroK8s cluster that satisfies the characteristics described in the system requirements: Creating an Amazon EKS cluster Creating a MicroK8s cluster", "title": "1. Setting up the system requirements"}, {"location": "chart/#2-installing-codacy", "text": "Install Codacy on an existing cluster using our Helm chart: Make sure that you have the following tools installed on your machine: kubectl within one minor version difference of your cluster Important If you're using MicroK8s you don't need to install kubectl because you will execute all kubectl commands as microk8s.kubectl commands instead. To simplify this, check how to create an alias for kubectl . Helm version >= 3.9 Create a cluster namespace called codacy that will group all resources related to Codacy. kubectl create namespace codacy Add the Docker registry credentials provided by Codacy together with your license to a cluster Secret. This is necessary because some Codacy Docker images are currently private. Substitute and with the Docker registry username and password and run the following command: kubectl create secret docker-registry docker-credentials \\ --docker-username = \\ --docker-password = \\ --namespace codacy Download the template file values-production.yaml and use a text editor of your choice to edit the value placeholders as described in the comments. Create an address record on your DNS provider mapping the hostname you used in the previous step to the IP address of your Ingress controller. Important If you're using MicroK8s you must map the hostname to the public IP address of the machine running MicroK8s. Add Codacy's chart repository to your Helm client and install the Codacy chart using the file values-production.yaml created previously. Important If you're using MicroK8s you must download and use the file values-microk8s.yaml together with the file values-production.yaml by uncommenting the last line in the helm upgrade command below. helm repo add codacy-stable https://charts.codacy.com/stable/ helm repo update helm upgrade --install codacy codacy-stable/codacy \\ --namespace codacy \\ --version 14 .0.0 \\ --values values-production.yaml # --values values-microk8s.yaml By now all the Codacy pods should be starting in the cluster. Run the following command and wait for all the pods to have the status Running , which can take several minutes: $ kubectl get pods -n codacy NAME READY STATUS RESTARTS AGE codacy-api-f7897b965-fgn67 1 /1 Running 0 8m57s codacy-api-f7897b965-kkqsx 1 /1 Running 0 8m57s codacy-crow-7c957d45f6-b8zp2 1 /1 Running 2 8m57s codacy-crowdb-0 1 /1 Running 0 8m57s codacy-engine-549bcb69d9-cgrqf 1 /1 Running 1 8m57s codacy-engine-549bcb69d9-sh5f4 1 /1 Running 1 8m57s codacy-fluentdoperator-x5vr2 2 /2 Running 0 8m57s codacy-listener-868b784dcf-npdfh 1 /1 Running 0 8m57s codacy-listenerdb-0 1 /1 Running 0 8m57s codacy-minio-7cfdc7b4f4-254gz 1 /1 Running 0 8m57s codacy-nfsserverprovisioner-0 1 /1 Running 0 8m57s codacy-portal-774d9fc596-rwqj5 1 /1 Running 2 8m56s codacy-rabbitmq-ha-0 1 /1 Running 0 8m57s codacy-ragnaros-69459775b5-hmj4d 1 /1 Running 3 8m57s codacy-remote-provider-service-8fb8556b-rr4ws 1 /1 Running 0 8m56s codacy-worker-manager-656dbf8d6d-n4j7c 1 /1 Running 0 8m57s", "title": "2. Installing Codacy"}, {"location": "chart/#3-configuring-codacy", "text": "After successfully installing Codacy on your cluster, you're now ready to perform the post-install configuration steps: Use a browser to navigate to the Codacy hostname previously configured on the file values-production.yaml . Log in using your Git provider account. This automatically creates a Codacy administrator account with your credentials. Follow Codacy's onboarding process, which will guide you through the following steps: Configuring one or more of the following supported integrations: GitHub Cloud GitHub Enterprise GitLab Cloud GitLab Enterprise Bitbucket Cloud Bitbucket Server Email Creating an initial organization Inviting users to Codacy As a last step we recommend that you set up monitoring on your Codacy instance. If you run into any issues while configuring Codacy, be sure to check our troubleshooting guide for more help.", "title": "3. Configuring Codacy"}, {"location": "chart/requirements/", "text": "System requirements # Before installing Codacy Self-hosted you must ensure that you have the following infrastructure correctly provisioned and configured: Git provider Kubernetes or MicroK8s cluster PostgreSQL server The next sections describe in detail how to set up these prerequisites. Git provider # To use Codacy Self-hosted, you must use one or more of our supported Git providers . In particular, if you're using a self-hosted Git provider, make sure that your version is supported by Codacy. Kubernetes or MicroK8s cluster setup # The cluster running Codacy must satisfy the following requirements: The infrastructure hosting the cluster must be provisioned with the hardware and networking requirements described below The orchestration platform managing the cluster must be one of: Kubernetes version 1.22.* to 1.27.* (1.26 recommended) MicroK8s version 1.19.* The NGINX Ingress controller must be installed and correctly set up in the cluster Cluster networking requirements # The cluster must be configured to accept and establish connections on the following ports: Service Protocol/Port Notes Inbound SSH TCP/22 MicroK8s only , to access the infrastructure remotely. Inbound HTTP TCP/80 Allow access to the Codacy website and API endpoints Inbound HTTPS TCP/443 Allow access to the Codacy website and API endpoints Outbound PostgreSQL TCP/5432 Connection to the PostgreSQL DBMS Outbound SMTP TCP/25 Connection to your SMTP server Outbound SMTPS TCP/465 Connection to your SMTP server over TLS/SSL Outbound Docker Hub * Connection to Docker Hub to download the required container images Outbound Git provider * Connection to the ports required by your remote Git provider Cluster hardware requirements # The high-level architecture described in the next section is important in understanding how Codacy uses and allocates hardware resources. Below we also provide guidance on resource provisioning for typical scenarios . For a custom hardware resource recommendation, please contact us at support@codacy.com . Codacy architecture # You can look at Codacy separately as two groups of components: The \"Platform\" contains the UI and other components important to treat and show results The \"Analysis\" is the swarm of workers that run between one and four linters simultaneously, depending on factors such as the number of files or the programming languages used in your projects Since all components are running on a cluster, you can increase the number of pod replicas in every deployment to give you more resilience and throughput, at a cost of increased resource usage. The following is a simplified overview of how to calculate resource allocation for the group of components \"Platform\" and \"Analysis\": Group of components vCPU Memory Platform (1 pod replica per component) 4 8 GB Analysis (1 Analysis Worker pod with up to 4 linters) 5 (per Analysis Worker) 10 GB (per Analysis Worker) Standard cluster provisioning # As described in the section above, Codacy's architecture allows scaling the \"Analysis\" group of components, meaning that the resources needed for Codacy depend mainly on the rate of commits done by your team that Codacy will be analyzing. The resources recommended on the following table are based on our experience and are also the defaults in the values-production.yaml file. You might need to adapt these defaults taking into account your use case. In particular, you should set the value of global.workerManager.workers.config.dedicatedMax to the maximum number of concurrent analysis depending on the available resources and number of replicas per component. Note For MicroK8s clusters we added an extra 1.5 vCPU and 1.5 GB memory to the \"Platform\" to account for the MicroK8s platform itself running on the same machine. Installation type Pod replicas per component Max. concurrent analysis Platform resources Analysis resources ~ Total resources Kubernetes Small Installation 1 2 4 vCPUs 8 GB RAM 10 vCPUs 20 GB RAM 16 vCPUs 32 GB RAM Kubernetes Medium Installation (default) 2 4 8 vCPUs 16 GB RAM 20 vCPUs 40 GB RAM 32 vCPUs 64 GB RAM Kubernetes Big Installation 2+ 10+ 8+ vCPUs 16+ GB RAM 50+ vCPUs 100+ GB RAM 60+ vCPUs 110+ GB RAM MicroK8s Minimum 1 2 5.5 vCPUs 9.5 GB RAM 10 vCPUs 20 GB RAM 16 vCPUs 32 GB RAM MicroK8s Recommended (default) 1+ 2 9.5+ vCPUs 17.5+ GB RAM 10 vCPUs 20 GB RAM 21+ vCPUs 40+ GB RAM The storage requirements recommended on the following table depend mainly on the number of repositories that Codacy will be analyzing and should be used as a guideline to determine your installation requirements. Component Bundled in the chart? Minimum recommended NFS Yes 200 GB RabbitMQ Yes 8 GB Minio Yes 20 GB PostgreSQL No (external DB recommended) 500 GB+ Note Please note that due to the way Codacy works, a small number of pods will run in privileged mode with the CAP_SYS_ADMIN capability. This is required to allow the Worker pods to serve NFS shares to be mounted by the pods running the static code analysis tools. PostgreSQL server setup # Codacy requires a database server to persist data that must satisfy the following requirements: The infrastructure hosting the database server must be provisioned with the hardware requirements described below The DBMS server must be PostgreSQL version 11.20 or version 12.* (12.* recommended) The PostgreSQL server must be configured to accept connections from the cluster The Codacy databases and a dedicated user must be created using the instructions below Important Google, the developer of Kubernetes, doesn't recommend running database servers on your cluster . As such, consider using a managed solution like Amazon RDS or Google Cloud SQL, or running the PostgreSQL server on a dedicated virtual machine. We recommend that you use a managed solution to reduce maintenance and configuration costs of the PostgreSQL server. The main cloud providers all have this service that you can use, for example: Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL-Compatible Edition Azure Database for PostgreSQL Google Cloud SQL for PostgreSQL Digital Ocean Managed Databases PostgreSQL hardware requirements # The following are the minimum specifications recommended for provisioning the PostgreSQL server: vCPUs Memory Storage Max. concurrent connections 4 8 GB 500 GB+ 300 Preparing PostgreSQL for Codacy # Before installing Codacy you must create a set of databases that will be used by Codacy to persist data. We also recommend that you create a dedicated user for Codacy, with access permissions only to the databases that are specific to Codacy: Connect to the PostgreSQL server as a database admin user. For example, using the psql command line client: psql -U postgres -h Create the dedicated user that Codacy will use to connect to PostgreSQL. Make sure that you change the username and password to suit your security needs: CREATE USER codacy WITH PASSWORD 'codacy' ; ALTER ROLE codacy WITH CREATEDB ; Take note of the username and password you define, as you will require them later to configure the connection from Codacy to the PostgreSQL server. Make sure that you can connect to the PostgreSQL database using the newly created user. For example, using the psql command line client: psql -U codacy -d postgres -h Create the databases required by Codacy: CREATE DATABASE accounts WITH OWNER = codacy ; CREATE DATABASE analysis WITH OWNER = codacy ; CREATE DATABASE results WITH OWNER = codacy ; CREATE DATABASE metrics WITH OWNER = codacy ; CREATE DATABASE filestore WITH OWNER = codacy ; CREATE DATABASE jobs WITH OWNER = codacy ; CREATE DATABASE listener WITH OWNER = codacy ; CREATE DATABASE crow WITH OWNER = codacy ;", "title": "System requirements"}, {"location": "chart/requirements/#system-requirements", "text": "Before installing Codacy Self-hosted you must ensure that you have the following infrastructure correctly provisioned and configured: Git provider Kubernetes or MicroK8s cluster PostgreSQL server The next sections describe in detail how to set up these prerequisites.", "title": "System requirements"}, {"location": "chart/requirements/#git-provider", "text": "To use Codacy Self-hosted, you must use one or more of our supported Git providers . In particular, if you're using a self-hosted Git provider, make sure that your version is supported by Codacy.", "title": "Git provider"}, {"location": "chart/requirements/#kubernetes-or-microk8s-cluster-setup", "text": "The cluster running Codacy must satisfy the following requirements: The infrastructure hosting the cluster must be provisioned with the hardware and networking requirements described below The orchestration platform managing the cluster must be one of: Kubernetes version 1.22.* to 1.27.* (1.26 recommended) MicroK8s version 1.19.* The NGINX Ingress controller must be installed and correctly set up in the cluster", "title": "Kubernetes or MicroK8s cluster setup"}, {"location": "chart/requirements/#postgresql-server-setup", "text": "Codacy requires a database server to persist data that must satisfy the following requirements: The infrastructure hosting the database server must be provisioned with the hardware requirements described below The DBMS server must be PostgreSQL version 11.20 or version 12.* (12.* recommended) The PostgreSQL server must be configured to accept connections from the cluster The Codacy databases and a dedicated user must be created using the instructions below Important Google, the developer of Kubernetes, doesn't recommend running database servers on your cluster . As such, consider using a managed solution like Amazon RDS or Google Cloud SQL, or running the PostgreSQL server on a dedicated virtual machine. We recommend that you use a managed solution to reduce maintenance and configuration costs of the PostgreSQL server. The main cloud providers all have this service that you can use, for example: Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL-Compatible Edition Azure Database for PostgreSQL Google Cloud SQL for PostgreSQL Digital Ocean Managed Databases", "title": "PostgreSQL server setup"}, {"location": "chart/configuration/caching/", "text": "Caching # Codacy Self-hosted includes a built-in NFS server provisioner that deploys a shared volume to cache the cloned repository files while they're being analyzed by each tool. However, if you're dealing with big repositories or a high volume of analysis, using an NFS server external to the cluster will improve the performance of the cache. To use your own external NFS server: Edit the file values-production.yaml that you used to install Codacy . Set listener.nfsserverprovisioner.enabled: \"false\" and define the remaining listener.cache.* values as described below: listener : nfsserverprovisioner : enabled : false cache : name : listener-cache path : /data nfs : server : # IP address of the external NFS server path : /var/nfs/data/ # External NFS server directory or file system to be mounted Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml Validate that the repository-listener pod is now using the external NFS server: $ kubectl describe pod -n codacy codacy-listener-<...> [ ... ] Volumes: listener-cache: Type: NFS ( an NFS mount that lasts the lifetime of a pod ) Server: Path: /var/nfs/data/ ReadOnly: false", "title": "Caching"}, {"location": "chart/configuration/caching/#caching", "text": "Codacy Self-hosted includes a built-in NFS server provisioner that deploys a shared volume to cache the cloned repository files while they're being analyzed by each tool. However, if you're dealing with big repositories or a high volume of analysis, using an NFS server external to the cluster will improve the performance of the cache. To use your own external NFS server: Edit the file values-production.yaml that you used to install Codacy . Set listener.nfsserverprovisioner.enabled: \"false\" and define the remaining listener.cache.* values as described below: listener : nfsserverprovisioner : enabled : false cache : name : listener-cache path : /data nfs : server : # IP address of the external NFS server path : /var/nfs/data/ # External NFS server directory or file system to be mounted Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml Validate that the repository-listener pod is now using the external NFS server: $ kubectl describe pod -n codacy codacy-listener-<...> [ ... ] Volumes: listener-cache: Type: NFS ( an NFS mount that lasts the lifetime of a pod ) Server: Path: /var/nfs/data/ ReadOnly: false", "title": "Caching"}, {"location": "chart/configuration/logging/", "text": "Logging # Currently, Codacy Self-hosted supports two types of log configurations: Log level : The severity of the messages that will be shown in logs. Log retention period : The period during which logs will be stored, before being removed by the cleanup job specified in the configuration. The sections below provide instructions on how to configure each logging configuration. Configuring the log level # The log level defines the minimum severity of the events contained in the logs, and affects the necessary storage space in MinIO. Important We recommend that you don't use a log level lower than WARN, as the logs are useful to troubleshoot any issues in your Codacy Self-hosted instance. Codacy supports configuring the log level of the following components: codacy-api engine listener worker-manager Follow these instructions to configure the log level: Edit the value of .config.logLevel in the values-production.yaml file that is used to install Codacy, as shown in the example below. worker-manager : replicaCount : 2 config : logLevel : WARN resources : limits : cpu : 500m memory : 1000Mi requests : cpu : 200m memory : 200Mi The list of supported values for logLevel is shown below. Note that each level also prints the information of the levels higher than it: DEBUG (default): Logs detailed information on the flow through the system. This is the most verbose level . INFO: Logs interesting events such as application startup and shutdown, important events on the flow of the system, or behavior that is skipped for expected reasons. WARN: Logs runtime events that are unexpected, or undesirable, but not necessarily wrong such as the use of deprecated APIs. ERROR: Only logs runtime errors, or unexpected conditions that prevent the expected behavior from happening. This is the least verbose level . Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml Configuring the log retention period # The log retention period is the number of days during which logs will be stored before being removed by the MinIO bucket lifecycle configuration policy that we provide in the template lifecycle-police-job.yaml . Follow these instructions to configure the log retention period: Adjust the retention period of your logs by editing the value of fluentdoperator.expirationDays in the values.yaml file, as shown in the example below. fluentdoperator : enabled : true defaultConfigmap : codacy-fluentd-config bucketName : logs expirationDays : 7 Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "Logging"}, {"location": "chart/configuration/logging/#logging", "text": "Currently, Codacy Self-hosted supports two types of log configurations: Log level : The severity of the messages that will be shown in logs. Log retention period : The period during which logs will be stored, before being removed by the cleanup job specified in the configuration. The sections below provide instructions on how to configure each logging configuration.", "title": "Logging"}, {"location": "chart/configuration/logging/#configuring-the-log-level", "text": "The log level defines the minimum severity of the events contained in the logs, and affects the necessary storage space in MinIO. Important We recommend that you don't use a log level lower than WARN, as the logs are useful to troubleshoot any issues in your Codacy Self-hosted instance. Codacy supports configuring the log level of the following components: codacy-api engine listener worker-manager Follow these instructions to configure the log level: Edit the value of .config.logLevel in the values-production.yaml file that is used to install Codacy, as shown in the example below. worker-manager : replicaCount : 2 config : logLevel : WARN resources : limits : cpu : 500m memory : 1000Mi requests : cpu : 200m memory : 200Mi The list of supported values for logLevel is shown below. Note that each level also prints the information of the levels higher than it: DEBUG (default): Logs detailed information on the flow through the system. This is the most verbose level . INFO: Logs interesting events such as application startup and shutdown, important events on the flow of the system, or behavior that is skipped for expected reasons. WARN: Logs runtime events that are unexpected, or undesirable, but not necessarily wrong such as the use of deprecated APIs. ERROR: Only logs runtime errors, or unexpected conditions that prevent the expected behavior from happening. This is the least verbose level . Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "Configuring the log level"}, {"location": "chart/configuration/logging/#configuring-the-log-retention-period", "text": "The log retention period is the number of days during which logs will be stored before being removed by the MinIO bucket lifecycle configuration policy that we provide in the template lifecycle-police-job.yaml . Follow these instructions to configure the log retention period: Adjust the retention period of your logs by editing the value of fluentdoperator.expirationDays in the values.yaml file, as shown in the example below. fluentdoperator : enabled : true defaultConfigmap : codacy-fluentd-config bucketName : logs expirationDays : 7 Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "Configuring the log retention period"}, {"location": "chart/configuration/monitoring/", "text": "Monitoring # Currently, Codacy Self-hosted supports two monitoring solutions: Crow : A simple, lightweight, and built-in monitoring solution, enabled by default when you install Codacy. Prometheus + Grafana + Loki : A comprehensive third-party monitoring solution, recommended for more advanced usage. The sections below provide instructions on how to set up each monitoring solution. Setting up monitoring using Crow # Crow displays information about the projects that are pending analysis and the jobs currently running on Codacy. Crow is installed alongside Codacy when the Helm chart is deployed to the cluster. By default, you can access Crow as follows: URL: http:///monitoring , where is the hostname of your Codacy instance Username: codacy Password: C0dacy123 We highly recommend that you define a custom password for Crow, if you haven't already done it when installing Codacy: Edit the value of global.crow.config.passwordAuth.password in the values-production.yaml file that you used to install Codacy: global : crow : config : passwordAuth : password : C0dacy123 Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml Setting up monitoring using Grafana, Prometheus, and Loki # Prometheus is an open-source systems monitoring and alerting toolkit. Logs can be collected using Loki , which is a horizontally-scalable, highly-available, multi-tenant log aggregation system. Its data can be visualized with Grafana , a widely used open source analytics and monitoring solution. This solution is considerably more resource demanding than Crow, and is recommended only for more advanced usage. Furthermore, its installation, configuration, and management require a deeper knowledge of Kubernetes as each component must be carefully tweaked to match your specific use case, using as starting point the .yaml values files provided by us. The instructions below cover the basic installation of these monitoring services using the Kube Prometheus Stack . Important If you're using MicroK8s run alias kubectl=microk8s.kubectl . 1. Install custom resources # Add the custom resources required for installing the monitoring bundle in your cluster: kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_alertmanagerconfigs.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_alertmanagers.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_podmonitors.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_probes.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_prometheuses.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_prometheusrules.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml kubectl apply --server-side -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/v0.58.0/example/prometheus-operator-crd/monitoring.coreos.com_thanosrulers.yaml 2. Installing Loki # Obtain the configuration file for Loki, values-loki.yaml , and install it by running the command below. While the default storage class setting for Loki persistence should suit most use cases, you may need to adjust it to your specific Kubernetes installation. For instance, for MicroK8s use storageClassName: microk8s-hostpath . helm repo add grafana https://grafana.github.io/helm-charts kubectl create namespace monitoring helm upgrade --install --atomic --timeout 600s loki grafana/loki \\ --version 2 .14.1 --namespace monitoring --values values-loki.yaml 3. Installing Promtail # Promtail is an agent that ships the contents of local logs to a Loki instance. Obtain the configuration file for Promtail, values-promtail.yaml , and install it by running the command below. helm upgrade --install --atomic --timeout 600s promtail grafana/promtail \\ --version 2 .2.0 --namespace monitoring --values values-promtail.yaml 4. Installing Prometheus and Grafana # Obtain the configuration file for the Kube Prometheus Stack , values-prometheus-operator.yaml . Then: Edit the Grafana password for the admin user and the hostname for Grafana in the values-prometheus-operator.yaml file. Install the bundle on your cluster by running the command below. helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update helm upgrade --install --atomic --timeout 600s monitoring prometheus-community/kube-prometheus-stack \\ --version 39 .9.0 --namespace monitoring --values values-prometheus-operator.yaml Grafana will be available on the domain you configured in your values-prometheus-operator.yaml file, with Prometheus and Loki configured as datasources. Follow the Kubernetes documentation if you need to access other monitoring services that are now running on your cluster, using the method that best suits your use case. 5. Enable service dashboards # Now that you have Prometheus and Grafana installed you can enable metrics reporting for Codacy components. Create a file named values-monitoring.yaml with the following content: global : metrics : kamon : enabled : true prometheusReporter : enabled : true serviceMonitor : enabled : true grafana : enabled : true Apply this configuration by performing a Helm upgrade. To do so append --values values-monitoring.yaml to the command used to install Codacy : helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-monitoring.yaml", "title": "Monitoring"}, {"location": "chart/configuration/monitoring/#monitoring", "text": "Currently, Codacy Self-hosted supports two monitoring solutions: Crow : A simple, lightweight, and built-in monitoring solution, enabled by default when you install Codacy. Prometheus + Grafana + Loki : A comprehensive third-party monitoring solution, recommended for more advanced usage. The sections below provide instructions on how to set up each monitoring solution.", "title": "Monitoring"}, {"location": "chart/configuration/monitoring/#setting-up-monitoring-using-crow", "text": "Crow displays information about the projects that are pending analysis and the jobs currently running on Codacy. Crow is installed alongside Codacy when the Helm chart is deployed to the cluster. By default, you can access Crow as follows: URL: http:///monitoring , where is the hostname of your Codacy instance Username: codacy Password: C0dacy123 We highly recommend that you define a custom password for Crow, if you haven't already done it when installing Codacy: Edit the value of global.crow.config.passwordAuth.password in the values-production.yaml file that you used to install Codacy: global : crow : config : passwordAuth : password : C0dacy123 Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "Setting up monitoring using Crow"}, {"location": "chart/configuration/monitoring/#setting-up-monitoring-using-grafana-prometheus-and-loki", "text": "Prometheus is an open-source systems monitoring and alerting toolkit. Logs can be collected using Loki , which is a horizontally-scalable, highly-available, multi-tenant log aggregation system. Its data can be visualized with Grafana , a widely used open source analytics and monitoring solution. This solution is considerably more resource demanding than Crow, and is recommended only for more advanced usage. Furthermore, its installation, configuration, and management require a deeper knowledge of Kubernetes as each component must be carefully tweaked to match your specific use case, using as starting point the .yaml values files provided by us. The instructions below cover the basic installation of these monitoring services using the Kube Prometheus Stack . Important If you're using MicroK8s run alias kubectl=microk8s.kubectl .", "title": "Setting up monitoring using Grafana, Prometheus, and Loki"}, {"location": "chart/configuration/integrations/bitbucket-cloud/", "text": "Bitbucket Cloud # Follow the instructions below to set up the Codacy Self-hosted integration with Bitbucket Cloud. Create an OAuth consumer # To integrate Codacy with Bitbucket Cloud, you must register an OAuth consumer for Codacy on Bitbucket. You can create a consumer on any existing individual or team account. To create a consumer, do the following: On Bitbucket, click on your avatar on the bottom left-hand corner and select Bitbucket settings . Select OAuth on the left sidebar and click the button Add consumer . Fill in the fields to create the OAuth consumer: Name: Name of the OAuth consumer. For example, Codacy . Callback URL: Copy the URL below, replacing the HTTP protocol and hostname with the correct values for your Codacy instance. https://codacy.example.com/login/Bitbucket?codacy_skip_ga=1 This is a private consumer: Enable the check box. Add the permissions: Account: Write Team membership: Read Projects: Read Repositories: Admin Pull requests: Write Issues: Write Webhooks: Read and write Click Save, and then click the name of the new OAuth consumer to take note of the generated key and secret. Configure Bitbucket Cloud on Codacy # After creating the OAuth consumer on Bitbucket Cloud, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.bitbucket.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the OAuth consumer: global : bitbucket : enabled : \"true\" login : \"true\" # Show login button for Bitbucket Cloud key : \"\" # OAuth consumer key secret : \"\" # OAuth consumer secret Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use Bitbucket Cloud to authenticate to Codacy.", "title": "Bitbucket Cloud"}, {"location": "chart/configuration/integrations/bitbucket-cloud/#bitbucket-cloud", "text": "Follow the instructions below to set up the Codacy Self-hosted integration with Bitbucket Cloud.", "title": "Bitbucket Cloud"}, {"location": "chart/configuration/integrations/bitbucket-cloud/#create-oauth", "text": "To integrate Codacy with Bitbucket Cloud, you must register an OAuth consumer for Codacy on Bitbucket. You can create a consumer on any existing individual or team account. To create a consumer, do the following: On Bitbucket, click on your avatar on the bottom left-hand corner and select Bitbucket settings . Select OAuth on the left sidebar and click the button Add consumer . Fill in the fields to create the OAuth consumer: Name: Name of the OAuth consumer. For example, Codacy . Callback URL: Copy the URL below, replacing the HTTP protocol and hostname with the correct values for your Codacy instance. https://codacy.example.com/login/Bitbucket?codacy_skip_ga=1 This is a private consumer: Enable the check box. Add the permissions: Account: Write Team membership: Read Projects: Read Repositories: Admin Pull requests: Write Issues: Write Webhooks: Read and write Click Save, and then click the name of the new OAuth consumer to take note of the generated key and secret.", "title": "Create an OAuth consumer"}, {"location": "chart/configuration/integrations/bitbucket-cloud/#configure", "text": "After creating the OAuth consumer on Bitbucket Cloud, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.bitbucket.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the OAuth consumer: global : bitbucket : enabled : \"true\" login : \"true\" # Show login button for Bitbucket Cloud key : \"\" # OAuth consumer key secret : \"\" # OAuth consumer secret Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use Bitbucket Cloud to authenticate to Codacy.", "title": "Configure Bitbucket Cloud on Codacy"}, {"location": "chart/configuration/integrations/bitbucket-server/", "text": "Bitbucket Server # Follow the instructions below to set up the Codacy Self-hosted integration with Bitbucket Server. Create a Bitbucket Server application link # To integrate Codacy with Bitbucket Server, you must create an application link on your Bitbucket Server instance: Create a key pair to sign and validate the requests between Codacy and the Bitbucket Server instance. Run the following command to create the key pair using the RSA algorithm in the PKCS#8 format: bash < ( curl -fsSL https://raw.githubusercontent.com/codacy/chart/master/docs/configuration/integrations/generate-bitbucket-server-secrets.sh ) Store the keys in a safe place for usage in the next steps and as a backup. Open /plugins/servlet/applinks/listApplicationLinks , where is the URL of your Bitbucket Server instance. Create a new application link with the URL of your Codacy instance. Important If you're using Bitbucket Server 7.20 or later you must select the application type Atlassian product while creating the new application link. This forces the integration to use OAuth 1.0 and is necessary to ensure the compatibility between Codacy and older versions of Bitbucket that only supported OAuth 1.0. If Bitbucket Server may warn you that there was no response from the URL you entered. This is expected, and you can click Continue after verifying that the URL is correct. Fill in the fields: Application Name: Name of the application. For example, Codacy . Application Type: Select Generic Application . The remaining fields should be left blank. After creating the new application link, click Edit to add an incoming authentication. Fill in the fields of the incoming authentication: Consumer Key: Enter the consumerKey generated previously. Consumer Name: Name of the consumer. For example, Codacy . Public Key: Enter the consumerPublicKey generated previously. The remaining fields should be left blank. Configure Bitbucket Server on Codacy # After creating the Bitbucket Server application link, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.bitbucketEnterprise.enabled: \"true\" and define the remaining values as described below and with the information obtained when you created the Bitbucket Server application link: bitbucketEnterprise : enabled : \"true\" login : \"true\" # Show login button for Bitbucket Server hostname : \"bitbucket.example.com\" # Hostname of your Bitbucket Server instance protocol : \"https\" # Protocol of your Bitbucket Server instance port : 7990 # Port of your Bitbucket Server instance consumerKey : \"\" # Generated when creating the Bitbucket Server application link consumerPublicKey : \"\" # Generated when creating the Bitbucket Server application link consumerPrivateKey : \"\" # Generated when creating the Bitbucket Server application link contextPath : \"\" # Context path of your Bitbucket Server, if configured Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use Bitbucket Server to authenticate to Codacy.", "title": "Bitbucket Server"}, {"location": "chart/configuration/integrations/bitbucket-server/#bitbucket-server", "text": "Follow the instructions below to set up the Codacy Self-hosted integration with Bitbucket Server.", "title": "Bitbucket Server"}, {"location": "chart/configuration/integrations/bitbucket-server/#create-a-bitbucket-server-application-link", "text": "To integrate Codacy with Bitbucket Server, you must create an application link on your Bitbucket Server instance: Create a key pair to sign and validate the requests between Codacy and the Bitbucket Server instance. Run the following command to create the key pair using the RSA algorithm in the PKCS#8 format: bash < ( curl -fsSL https://raw.githubusercontent.com/codacy/chart/master/docs/configuration/integrations/generate-bitbucket-server-secrets.sh ) Store the keys in a safe place for usage in the next steps and as a backup. Open /plugins/servlet/applinks/listApplicationLinks , where is the URL of your Bitbucket Server instance. Create a new application link with the URL of your Codacy instance. Important If you're using Bitbucket Server 7.20 or later you must select the application type Atlassian product while creating the new application link. This forces the integration to use OAuth 1.0 and is necessary to ensure the compatibility between Codacy and older versions of Bitbucket that only supported OAuth 1.0. If Bitbucket Server may warn you that there was no response from the URL you entered. This is expected, and you can click Continue after verifying that the URL is correct. Fill in the fields: Application Name: Name of the application. For example, Codacy . Application Type: Select Generic Application . The remaining fields should be left blank. After creating the new application link, click Edit to add an incoming authentication. Fill in the fields of the incoming authentication: Consumer Key: Enter the consumerKey generated previously. Consumer Name: Name of the consumer. For example, Codacy . Public Key: Enter the consumerPublicKey generated previously. The remaining fields should be left blank.", "title": "Create a Bitbucket Server application link"}, {"location": "chart/configuration/integrations/bitbucket-server/#configure-bitbucket-server-on-codacy", "text": "After creating the Bitbucket Server application link, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.bitbucketEnterprise.enabled: \"true\" and define the remaining values as described below and with the information obtained when you created the Bitbucket Server application link: bitbucketEnterprise : enabled : \"true\" login : \"true\" # Show login button for Bitbucket Server hostname : \"bitbucket.example.com\" # Hostname of your Bitbucket Server instance protocol : \"https\" # Protocol of your Bitbucket Server instance port : 7990 # Port of your Bitbucket Server instance consumerKey : \"\" # Generated when creating the Bitbucket Server application link consumerPublicKey : \"\" # Generated when creating the Bitbucket Server application link consumerPrivateKey : \"\" # Generated when creating the Bitbucket Server application link contextPath : \"\" # Context path of your Bitbucket Server, if configured Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use Bitbucket Server to authenticate to Codacy.", "title": "Configure Bitbucket Server on Codacy"}, {"location": "chart/configuration/integrations/email/", "text": "SMTP server # Follow the instructions below to set up Codacy Self-hosted to send emails using your SMTP server: Edit the file values-production.yaml that you used to install Codacy . Set global.email.enabled: \"true\" and define the remaining values with the credentials for your SMTP server: email : enabled : \"true\" replyTo : \"notifications@mycompany.com\" # Reply-to field on sent emails smtp : protocol : \"smtp\" # SMTP protocol to use, either smtps or smtp hostname : \"smtp.example.com\" # Hostname of your SMTP server # username: \"\" # Optional username to authenticate on your SMTP server # password: \"\" # Optional password to authenticate on your SMTP server # port: 25 # Optional port of your SMTP server, the default is 25 Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to: Invite new users via email Receive commit and pull request email notifications", "title": "SMTP server"}, {"location": "chart/configuration/integrations/email/#smtp-server", "text": "Follow the instructions below to set up Codacy Self-hosted to send emails using your SMTP server: Edit the file values-production.yaml that you used to install Codacy . Set global.email.enabled: \"true\" and define the remaining values with the credentials for your SMTP server: email : enabled : \"true\" replyTo : \"notifications@mycompany.com\" # Reply-to field on sent emails smtp : protocol : \"smtp\" # SMTP protocol to use, either smtps or smtp hostname : \"smtp.example.com\" # Hostname of your SMTP server # username: \"\" # Optional username to authenticate on your SMTP server # password: \"\" # Optional password to authenticate on your SMTP server # port: 25 # Optional port of your SMTP server, the default is 25 Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to: Invite new users via email Receive commit and pull request email notifications", "title": "SMTP server"}, {"location": "chart/configuration/integrations/github-app-create/", "text": "Creating a GitHub App # You must create and correctly set up a GitHub App to allow Codacy Self-hosted to integrate with GitHub. To create the GitHub App: If you're using GitHub Cloud , open https://github.com/settings/apps/new . If you're using GitHub Enterprise , open https://github.example.com/settings/apps/new , replacing the HTTP protocol and hostname with the correct values for your GitHub Enterprise instance. Configure the new GitHub App using the values listed on the table below, replacing https://codacy.example.com with the correct base URL of your Codacy instance. Field Value GitHub App name Codacy Homepage URL https://codacy.example.com User authorization callback URL https://codacy.example.com Request user authorization (OAuth) during installation Enabled Make sure this option is selected to request that the installing user grants access to their identity during the installation of your Codacy GitHub App. Webhook URL For GitHub Cloud: https://codacy.example.com/2.0/events/gh/organization For GitHub Enterprise: https://codacy.example.com/2.0/events/ghe/organization Repository permissions Administration Read & write Checks Read & write Issues Read & write Metadata Read only Pull requests Read & write Webhooks Read & write Commit statuses Read & write Organization permissions Members Read only Webhooks Read & write User permissions Email addresses Read only Git SSH keys Read & write Where can this GitHub App be installed? Any account Scroll to the bottom of the page, click Generate a private key , and save the .pem file containing the private key. Take note of the following information, as you'll need it to configure Codacy: GitHub App name App ID Client ID Client secret Private key (contents of the .pem file generated in the previous step)", "title": "Creating a GitHub App"}, {"location": "chart/configuration/integrations/github-app-create/#creating-a-github-app", "text": "You must create and correctly set up a GitHub App to allow Codacy Self-hosted to integrate with GitHub. To create the GitHub App: If you're using GitHub Cloud , open https://github.com/settings/apps/new . If you're using GitHub Enterprise , open https://github.example.com/settings/apps/new , replacing the HTTP protocol and hostname with the correct values for your GitHub Enterprise instance. Configure the new GitHub App using the values listed on the table below, replacing https://codacy.example.com with the correct base URL of your Codacy instance. Field Value GitHub App name Codacy Homepage URL https://codacy.example.com User authorization callback URL https://codacy.example.com Request user authorization (OAuth) during installation Enabled Make sure this option is selected to request that the installing user grants access to their identity during the installation of your Codacy GitHub App. Webhook URL For GitHub Cloud: https://codacy.example.com/2.0/events/gh/organization For GitHub Enterprise: https://codacy.example.com/2.0/events/ghe/organization Repository permissions Administration Read & write Checks Read & write Issues Read & write Metadata Read only Pull requests Read & write Webhooks Read & write Commit statuses Read & write Organization permissions Members Read only Webhooks Read & write User permissions Email addresses Read only Git SSH keys Read & write Where can this GitHub App be installed? Any account Scroll to the bottom of the page, click Generate a private key , and save the .pem file containing the private key. Take note of the following information, as you'll need it to configure Codacy: GitHub App name App ID Client ID Client secret Private key (contents of the .pem file generated in the previous step)", "title": "Creating a GitHub App"}, {"location": "chart/configuration/integrations/github-cloud/", "text": "GitHub Cloud # Follow the instructions below to set up the Codacy Self-hosted integration with GitHub Cloud: Follow the instructions on creating a GitHub App . Edit the file values-production.yaml that you used to install Codacy . Set global.github.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitHub App: github : enabled : \"true\" login : \"true\" # Show login button for GitHub Cloud clientId : \"\" # Client ID clientSecret : \"\" # Client secret app : name : \"codacy\" # GitHub App name id : \"1234\" # App ID privateKey : \"\" # Contents of the .pem file without newlines or the BEGIN/END lines Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitHub Cloud to authenticate to Codacy.", "title": "GitHub Cloud"}, {"location": "chart/configuration/integrations/github-cloud/#github-cloud", "text": "Follow the instructions below to set up the Codacy Self-hosted integration with GitHub Cloud: Follow the instructions on creating a GitHub App . Edit the file values-production.yaml that you used to install Codacy . Set global.github.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitHub App: github : enabled : \"true\" login : \"true\" # Show login button for GitHub Cloud clientId : \"\" # Client ID clientSecret : \"\" # Client secret app : name : \"codacy\" # GitHub App name id : \"1234\" # App ID privateKey : \"\" # Contents of the .pem file without newlines or the BEGIN/END lines Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitHub Cloud to authenticate to Codacy.", "title": "GitHub Cloud"}, {"location": "chart/configuration/integrations/github-enterprise/", "text": "GitHub Enterprise # Follow the instructions below to set up the Codacy Self-hosted integration with GitHub Enterprise: Follow the instructions on creating a GitHub App . Edit the file values-production.yaml that you used to install Codacy . Set global.githubEnterprise.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitHub App: githubEnterprise : enabled : \"true\" login : \"true\" # Show login button for GitHub Enterprise hostname : \"github.example.com\" # Hostname of your GitHub Enterprise instance protocol : \"https\" # Protocol of your GitHub Enterprise instance port : 443 # Port of your GitHub Enterprise instance disableSSL : \"false\" # Disable certificate validation isPrivateMode : \"true\" # Status of private mode on your GitHub Enterprise instance clientId : \"\" # GitHub App Client ID clientSecret : \"\" # GitHub App Client secret app : name : \"codacy\" # GitHub App name id : \"1234\" # GitHub App ID privateKey : \"\" # Contents of the .pem file without newlines or the BEGIN/END lines Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitHub Enterprise to authenticate to Codacy.", "title": "GitHub Enterprise"}, {"location": "chart/configuration/integrations/github-enterprise/#github-enterprise", "text": "Follow the instructions below to set up the Codacy Self-hosted integration with GitHub Enterprise: Follow the instructions on creating a GitHub App . Edit the file values-production.yaml that you used to install Codacy . Set global.githubEnterprise.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitHub App: githubEnterprise : enabled : \"true\" login : \"true\" # Show login button for GitHub Enterprise hostname : \"github.example.com\" # Hostname of your GitHub Enterprise instance protocol : \"https\" # Protocol of your GitHub Enterprise instance port : 443 # Port of your GitHub Enterprise instance disableSSL : \"false\" # Disable certificate validation isPrivateMode : \"true\" # Status of private mode on your GitHub Enterprise instance clientId : \"\" # GitHub App Client ID clientSecret : \"\" # GitHub App Client secret app : name : \"codacy\" # GitHub App name id : \"1234\" # GitHub App ID privateKey : \"\" # Contents of the .pem file without newlines or the BEGIN/END lines Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitHub Enterprise to authenticate to Codacy.", "title": "GitHub Enterprise"}, {"location": "chart/configuration/integrations/gitlab-cloud/", "text": "GitLab Cloud # Follow the instructions below to set up the Codacy Self-hosted integration with GitLab Cloud. Create a GitLab application # To integrate Codacy with GitLab Cloud, you must create a GitLab application: Open https://gitlab.com/-/profile/applications . Fill in the fields to register your Codacy instance on GitLab: Name: Name of the application. For example, Codacy . Redirect URI: Copy the URLs below, replacing the HTTP protocol and hostname with the correct values for your Codacy instance. This field is case sensitive. https://codacy.example.com/login/GitLab https://codacy.example.com/add/addProvider/GitLab https://codacy.example.com/add/addService/GitLab https://codacy.example.com/add/addPermissions/GitLab Scopes: Enable the scopes: api read_user read_repository openid Click Save application and take note of the generated Application Id and Secret. Note You can ignore the following error that GitLab may display when you test or save the new GitLab application: This happens because GitLab tests the new application by calling an endpoint that Codacy doesn't implement. Configure GitLab Cloud on Codacy # After creating the GitLab application, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.gitlab.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitLab application: gitlab : enabled : \"true\" login : \"true\" # Show login button for GitLab Cloud clientId : \"\" # Application ID clientSecret : \"\" # Secret Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitLab Cloud to authenticate to Codacy.", "title": "GitLab Cloud"}, {"location": "chart/configuration/integrations/gitlab-cloud/#gitlab-cloud", "text": "Follow the instructions below to set up the Codacy Self-hosted integration with GitLab Cloud.", "title": "GitLab Cloud"}, {"location": "chart/configuration/integrations/gitlab-cloud/#create-application", "text": "To integrate Codacy with GitLab Cloud, you must create a GitLab application: Open https://gitlab.com/-/profile/applications . Fill in the fields to register your Codacy instance on GitLab: Name: Name of the application. For example, Codacy . Redirect URI: Copy the URLs below, replacing the HTTP protocol and hostname with the correct values for your Codacy instance. This field is case sensitive. https://codacy.example.com/login/GitLab https://codacy.example.com/add/addProvider/GitLab https://codacy.example.com/add/addService/GitLab https://codacy.example.com/add/addPermissions/GitLab Scopes: Enable the scopes: api read_user read_repository openid Click Save application and take note of the generated Application Id and Secret. Note You can ignore the following error that GitLab may display when you test or save the new GitLab application: This happens because GitLab tests the new application by calling an endpoint that Codacy doesn't implement.", "title": "Create a GitLab application"}, {"location": "chart/configuration/integrations/gitlab-cloud/#configure", "text": "After creating the GitLab application, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.gitlab.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitLab application: gitlab : enabled : \"true\" login : \"true\" # Show login button for GitLab Cloud clientId : \"\" # Application ID clientSecret : \"\" # Secret Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitLab Cloud to authenticate to Codacy.", "title": "Configure GitLab Cloud on Codacy"}, {"location": "chart/configuration/integrations/gitlab-enterprise/", "text": "GitLab Enterprise # Follow the instructions below to set up the Codacy Self-hosted integration with GitLab Enterprise: Create a GitLab application # To integrate Codacy with GitLab Enterprise, you must create a GitLab application: Open /-/profile/applications as a GitLab admin, where is the URL of your GitLab Enterprise instance. Fill in the fields to register your Codacy instance on GitLab: Name: Name of the application. For example, Codacy . Redirect URI: Copy the URLs below, replacing the HTTP protocol and hostname with the correct values for your Codacy instance. This field is case sensitive. https://codacy.example.com/login/GitLabEnterprise https://codacy.example.com/add/addProvider/GitLabEnterprise https://codacy.example.com/add/addService/GitLabEnterprise https://codacy.example.com/add/addPermissions/GitLabEnterprise Scopes: Enable the scopes: api read_user read_repository openid Click Save application and take note of the generated Application Id and Secret. Note You can ignore the following error that GitLab Enterprise may display when you test or save the new GitLab application: This happens because GitLab Enterprise tests the new application by calling an endpoint that Codacy doesn't implement. Configure GitLab Enterprise on Codacy # After creating the GitLab application, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.gitlabEnterprise.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitLab application: gitlabEnterprise : enabled : \"true\" login : \"true\" # Show login button for GitLab Enterprise hostname : \"gitlab.example.com\" # Hostname of your GitLab Enterprise instance protocol : \"https\" # Protocol of your GitLab Enterprise instance port : 443 # Port of your GitLab Enterprise instance clientId : \"\" # Application ID clientSecret : \"\" # Secret Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitLab Enterprise to authenticate to Codacy. Detect changes to repositories and organizations # Optionally, Codacy can automatically detect the following changes to repositories and organizations on your GitLab Enterprise instance: For repositories: renames, deletes, and visibility changes For organizations: renames, deletes, and access removed To do this, you must configure a System Hook on your GitLab Enterprise instance to notify Codacy of the changes: Open /admin/hooks as a GitLab admin, where is the URL of your GitLab Enterprise instance. Fill in the fields to create the System Hook: URL: The URL of your Codacy instance with the path /2.0/events/gle/organization . For example, http://codacy.example.com/2.0/events/gle/organization Secret Token: Copy the Application Secret from the GitLab application that you created previously, or from the value of clientSecret in the file values-production.yaml that you used to install Codacy. Trigger: Enable the trigger Repository update events SSL verification: Enable the SSL verification. Click Save Changes to save the System Hook.", "title": "GitLab Enterprise"}, {"location": "chart/configuration/integrations/gitlab-enterprise/#gitlab-enterprise", "text": "Follow the instructions below to set up the Codacy Self-hosted integration with GitLab Enterprise:", "title": "GitLab Enterprise"}, {"location": "chart/configuration/integrations/gitlab-enterprise/#create-application", "text": "To integrate Codacy with GitLab Enterprise, you must create a GitLab application: Open /-/profile/applications as a GitLab admin, where is the URL of your GitLab Enterprise instance. Fill in the fields to register your Codacy instance on GitLab: Name: Name of the application. For example, Codacy . Redirect URI: Copy the URLs below, replacing the HTTP protocol and hostname with the correct values for your Codacy instance. This field is case sensitive. https://codacy.example.com/login/GitLabEnterprise https://codacy.example.com/add/addProvider/GitLabEnterprise https://codacy.example.com/add/addService/GitLabEnterprise https://codacy.example.com/add/addPermissions/GitLabEnterprise Scopes: Enable the scopes: api read_user read_repository openid Click Save application and take note of the generated Application Id and Secret. Note You can ignore the following error that GitLab Enterprise may display when you test or save the new GitLab application: This happens because GitLab Enterprise tests the new application by calling an endpoint that Codacy doesn't implement.", "title": "Create a GitLab application"}, {"location": "chart/configuration/integrations/gitlab-enterprise/#configure", "text": "After creating the GitLab application, you must configure it on Codacy: Edit the file values-production.yaml that you used to install Codacy . Set global.gitlabEnterprise.enabled: \"true\" and define the remaining values as described below using the information obtained when you created the GitLab application: gitlabEnterprise : enabled : \"true\" login : \"true\" # Show login button for GitLab Enterprise hostname : \"gitlab.example.com\" # Hostname of your GitLab Enterprise instance protocol : \"https\" # Protocol of your GitLab Enterprise instance port : 443 # Port of your GitLab Enterprise instance clientId : \"\" # Application ID clientSecret : \"\" # Secret Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml After this is done you will be able to use GitLab Enterprise to authenticate to Codacy.", "title": "Configure GitLab Enterprise on Codacy"}, {"location": "chart/configuration/integrations/gitlab-enterprise/#detect-changes-to-repositories-and-organizations", "text": "Optionally, Codacy can automatically detect the following changes to repositories and organizations on your GitLab Enterprise instance: For repositories: renames, deletes, and visibility changes For organizations: renames, deletes, and access removed To do this, you must configure a System Hook on your GitLab Enterprise instance to notify Codacy of the changes: Open /admin/hooks as a GitLab admin, where is the URL of your GitLab Enterprise instance. Fill in the fields to create the System Hook: URL: The URL of your Codacy instance with the path /2.0/events/gle/organization . For example, http://codacy.example.com/2.0/events/gle/organization Secret Token: Copy the Application Secret from the GitLab application that you created previously, or from the value of clientSecret in the file values-production.yaml that you used to install Codacy. Trigger: Enable the trigger Repository update events SSL verification: Enable the SSL verification. Click Save Changes to save the System Hook.", "title": "Detect changes to repositories and organizations"}, {"location": "chart/infrastructure/eks-quickstart/", "text": "Creating an Amazon EKS cluster # Follow the instructions below to set up an Amazon EKS cluster from scratch, including the necessary underlying infrastructure, using Terraform. The following diagram is a non-exhaustive overview of what you can expect to have deployed in your AWS account by using this quickstart guide. 1. Prepare your environment # Prepare your environment to set up the Amazon EKS cluster: Make sure that you have the following tools installed on your machine: Git version >= 2.0.0 AWS CLI version 1 Terraform version >= 0.12 Kubectl version >= 1.14 Set up the AWS CLI credentials for your AWS account using the AWS CLI and Terraform documentation as reference. Note that, as stated on the Terraform documentation , if your .aws/credentials are more complex you might need to set AWS_SDK_LOAD_CONFIG=1 for Terraform to work correctly: export AWS_SDK_LOAD_CONFIG = 1 Clone the Codacy chart repository and change to the directory that includes the provided Terraform configuration files: git clone https://github.com/codacy/chart.git cd chart/docs/infrastructure/EKS/ This folder includes the following infrastructure stacks: backend: Optional S3 bucket for storing the Terraform state and a DynamoDB table for state locking main: Amazon EKS cluster, including the setup of all network and node infrastructure to go from zero to a fully functional cluster You must have administration privileges on AWS to deploy (and eventually destroy) this infrastructure. The policy file aws-terraform-minimum-admin-policy.json lists the minimum privileges that are required. 2. Set up the Terraform state storage backend # The backend stores the current and historical state of your infrastructure. Although using the backend is optional, we recommend that you deploy it, particularly if you're planning to use these Terraform templates to make modifications to the cluster in the future: Initialize Terraform and deploy the infrastructure described in the backend/ directory, then follow Terraform's instructions: cd backend/ terraform init && terraform apply This creates an Amazon S3 bucket with a unique name to save the infrastructure state. Take note of the value of state_bucket_name in the output of the command. Edit the main/config.tf file and follow the instructions included in the comments to set the name of the Amazon S3 bucket created above and enable the use of the backend in those infrastructure stacks. 3. Create a vanilla Amazon EKS cluster # Create a cluster that includes all the required network and node setup: Initialize Terraform and deploy the infrastructure described in the main/ directory, then follow Terraform's instructions: cd ../main/ terraform init && terraform apply This process takes around 10 minutes. Consider if you want to tailor the cluster to your needs by customizing the cluster configuration. The cluster configuration (such as the type and number of nodes, network CIDRs, etc.) is exposed as variables in the main/variables.tf file. To customize the defaults of that file we recommend that you use a variable definitions file and set the variables in a file named terraform.tfvars in the directory main/ . The following is an example terraform.tfvars : some_key = \"a_string_value\" another_key = 3 someting_else = true Subsequently running terraform apply loads the variables in the terraform.tfvars file by default: terraform apply Set up the kubeconfig file that stores the information needed by kubectl to connect to the new cluster by default: aws eks update-kubeconfig --name codacy-cluster --alias codacy-cluster Get information about the pods in the cluster to test that the cluster was created and that kubectl can successfully connect to the cluster: kubectl get pods -A 4. Prepare to set up the Ingress Controller # Prepare your infrastructure for the Ingress Controller setup, which is performed later during the installation process: Make sure that your network resources are correctly tagged, and create the following required tags if they are missing: Resource Type Key = Value VPC kubernetes.io/cluster/codacy-cluster = shared Subnet (public) kubernetes.io/cluster/codacy-cluster = shared kubernetes.io/role/elb = 1 Subnet (private) kubernetes.io/cluster/codacy-cluster = shared kubernetes.io/role/internal-elb = 1 For more information refer to the AWS documentation . Add the following chart repositories to Helm: helm repo add stable https://charts.helm.sh/stable helm repo update 5. Install the NGINX Ingress Controller # Install the NGINX Ingress Controller: Download the configuration file values-nginx.yaml for the NGINX Ingress Controller. If you wish to use a private load balancer or restrict the IP range for the provisioned load balancer edit the file and enable the required annotation and/or the corresponding setting where indicated. Install the NGINX Ingress Controller. If you're using Kubernetes version <=1.21 , run: kubectl create namespace codacy helm upgrade --install --namespace codacy --version 1 .39.0 codacy-nginx-ingress stable/nginx-ingress -f values-nginx.yaml If you're using Kubernetes version 1.22 or later , run: kubectl create namespace codacy helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update helm upgrade --install --namespace codacy --version 4.8.3 nginx-ingress ingress-nginx/ingress-nginx -f values-nginx.yaml Uninstalling the Amazon EKS cluster # Warning If you proceed beyond this point you'll permanently delete and break things. Delete the Kubernetes cluster. Run the following command in the main/ directory: terraform destroy This process takes around 10 minutes. Remove the Terraform backend. If you created the Terraform backend with the provided stack you can now safely delete it. The backend is purposely created with extra settings to prevent its accidental destruction. To destroy it cleanly you must first disable these settings by editing the file backend/state_and_lock.tf and following the instructions included in the comments. Afterwards, run the following command in the backend/ directory: terraform apply && terraform destroy Note that you first have to run terraform apply to update the settings, and only then will terraform destroy be able to destroy the backend.", "title": "Creating an Amazon EKS cluster"}, {"location": "chart/infrastructure/eks-quickstart/#creating-an-amazon-eks-cluster", "text": "Follow the instructions below to set up an Amazon EKS cluster from scratch, including the necessary underlying infrastructure, using Terraform. The following diagram is a non-exhaustive overview of what you can expect to have deployed in your AWS account by using this quickstart guide.", "title": "Creating an Amazon EKS cluster"}, {"location": "chart/infrastructure/eks-quickstart/#1-prepare-your-environment", "text": "Prepare your environment to set up the Amazon EKS cluster: Make sure that you have the following tools installed on your machine: Git version >= 2.0.0 AWS CLI version 1 Terraform version >= 0.12 Kubectl version >= 1.14 Set up the AWS CLI credentials for your AWS account using the AWS CLI and Terraform documentation as reference. Note that, as stated on the Terraform documentation , if your .aws/credentials are more complex you might need to set AWS_SDK_LOAD_CONFIG=1 for Terraform to work correctly: export AWS_SDK_LOAD_CONFIG = 1 Clone the Codacy chart repository and change to the directory that includes the provided Terraform configuration files: git clone https://github.com/codacy/chart.git cd chart/docs/infrastructure/EKS/ This folder includes the following infrastructure stacks: backend: Optional S3 bucket for storing the Terraform state and a DynamoDB table for state locking main: Amazon EKS cluster, including the setup of all network and node infrastructure to go from zero to a fully functional cluster You must have administration privileges on AWS to deploy (and eventually destroy) this infrastructure. The policy file aws-terraform-minimum-admin-policy.json lists the minimum privileges that are required.", "title": "1. Prepare your environment"}, {"location": "chart/infrastructure/eks-quickstart/#2-set-up-the-terraform-state-storage-backend", "text": "The backend stores the current and historical state of your infrastructure. Although using the backend is optional, we recommend that you deploy it, particularly if you're planning to use these Terraform templates to make modifications to the cluster in the future: Initialize Terraform and deploy the infrastructure described in the backend/ directory, then follow Terraform's instructions: cd backend/ terraform init && terraform apply This creates an Amazon S3 bucket with a unique name to save the infrastructure state. Take note of the value of state_bucket_name in the output of the command. Edit the main/config.tf file and follow the instructions included in the comments to set the name of the Amazon S3 bucket created above and enable the use of the backend in those infrastructure stacks.", "title": "2. Set up the Terraform state storage backend"}, {"location": "chart/infrastructure/eks-quickstart/#3-create-a-vanilla-amazon-eks-cluster", "text": "Create a cluster that includes all the required network and node setup: Initialize Terraform and deploy the infrastructure described in the main/ directory, then follow Terraform's instructions: cd ../main/ terraform init && terraform apply This process takes around 10 minutes. Consider if you want to tailor the cluster to your needs by customizing the cluster configuration. The cluster configuration (such as the type and number of nodes, network CIDRs, etc.) is exposed as variables in the main/variables.tf file. To customize the defaults of that file we recommend that you use a variable definitions file and set the variables in a file named terraform.tfvars in the directory main/ . The following is an example terraform.tfvars : some_key = \"a_string_value\" another_key = 3 someting_else = true Subsequently running terraform apply loads the variables in the terraform.tfvars file by default: terraform apply Set up the kubeconfig file that stores the information needed by kubectl to connect to the new cluster by default: aws eks update-kubeconfig --name codacy-cluster --alias codacy-cluster Get information about the pods in the cluster to test that the cluster was created and that kubectl can successfully connect to the cluster: kubectl get pods -A", "title": "3. Create a vanilla Amazon EKS cluster"}, {"location": "chart/infrastructure/eks-quickstart/#4-prepare-to-set-up-the-ingress-controller", "text": "Prepare your infrastructure for the Ingress Controller setup, which is performed later during the installation process: Make sure that your network resources are correctly tagged, and create the following required tags if they are missing: Resource Type Key = Value VPC kubernetes.io/cluster/codacy-cluster = shared Subnet (public) kubernetes.io/cluster/codacy-cluster = shared kubernetes.io/role/elb = 1 Subnet (private) kubernetes.io/cluster/codacy-cluster = shared kubernetes.io/role/internal-elb = 1 For more information refer to the AWS documentation . Add the following chart repositories to Helm: helm repo add stable https://charts.helm.sh/stable helm repo update", "title": "4. Prepare to set up the Ingress Controller"}, {"location": "chart/infrastructure/eks-quickstart/#5-install-the-nginx-ingress-controller", "text": "Install the NGINX Ingress Controller: Download the configuration file values-nginx.yaml for the NGINX Ingress Controller. If you wish to use a private load balancer or restrict the IP range for the provisioned load balancer edit the file and enable the required annotation and/or the corresponding setting where indicated. Install the NGINX Ingress Controller. If you're using Kubernetes version <=1.21 , run: kubectl create namespace codacy helm upgrade --install --namespace codacy --version 1 .39.0 codacy-nginx-ingress stable/nginx-ingress -f values-nginx.yaml If you're using Kubernetes version 1.22 or later , run: kubectl create namespace codacy helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update helm upgrade --install --namespace codacy --version 4.8.3 nginx-ingress ingress-nginx/ingress-nginx -f values-nginx.yaml", "title": "5. Install the NGINX Ingress Controller"}, {"location": "chart/infrastructure/eks-quickstart/#uninstalling-the-amazon-eks-cluster", "text": "Warning If you proceed beyond this point you'll permanently delete and break things. Delete the Kubernetes cluster. Run the following command in the main/ directory: terraform destroy This process takes around 10 minutes. Remove the Terraform backend. If you created the Terraform backend with the provided stack you can now safely delete it. The backend is purposely created with extra settings to prevent its accidental destruction. To destroy it cleanly you must first disable these settings by editing the file backend/state_and_lock.tf and following the instructions included in the comments. Afterwards, run the following command in the backend/ directory: terraform apply && terraform destroy Note that you first have to run terraform apply to update the settings, and only then will terraform destroy be able to destroy the backend.", "title": "Uninstalling the Amazon EKS cluster"}, {"location": "chart/infrastructure/microk8s-quickstart/", "text": "Creating a MicroK8s cluster # Follow the instructions below to set up a MicroK8s instance from scratch, including all the necessary dependencies and configurations. MicroK8s is a lightweight, fully conformant, single-package Kubernetes developed by Canonical. The project is publicly available on GitHub . 1. Prepare your environment # Prepare your environment to set up the MicroK8s instance. You will need a machine running Ubuntu Server 20.04 LTS that: Is correctly provisioned with the resources described for MicroK8s in the system requirements Is able to establish a connection to the PostgreSQL instance described in the system requirements Make sure that you have Helm version 3.8.1 installed. The next steps assume that you're starting from a clean install of Ubuntu Server and require that you run commands on a local or remote command line session on the machine. 2. Installing MicroK8s # Install MicroK8s on the machine: Make sure that the package nfs-common is installed: sudo apt update && sudo apt install nfs-common -y Install MicroK8s from the 1.19/stable channel: sudo snap install microk8s --classic --channel = 1 .19/stable sudo usermod -a -G microk8s $USER sudo su - $USER Check that MicroK8s is running: microk8s.status --wait-ready If you're running MicroK8s using a single node, disable high-availability clustering for improved performance: microk8s.disable ha-cluster 3. Configuring MicroK8s # Now that MicroK8s is running on the machine we can proceed to enabling the necessary addons: Configure MicroK8s to allow privileged containers: sudo mkdir -p /var/snap/microk8s/current/args sudo echo \"--allow-privileged=true\" >> /var/snap/microk8s/current/args/kube-apiserver microk8s.status --wait-ready Enable the following MicroK8s addons: microk8s.enable dns microk8s.status --wait-ready microk8s.enable storage microk8s.status --wait-ready microk8s.enable ingress microk8s.status --wait-ready Important Check the output of the commands to make sure that all the addons are enabled correctly. If by chance any of the addons fails to be enabled, re-execute the microk8s.enable command for that addon. Restart MicroK8s and its services to make sure that all configurations are working: microk8s.stop microk8s.start microk8s.status --wait-ready Export your kubeconfig so that Helm knows on which cluster to install the charts: microk8s.config > ~/.kube/config The addons are now enabled and the MicroK8s instance bootstrapped. However, we must wait for some MicroK8s pods to be ready, as failing to do so can result in the pods entering a CrashLoopBackoff state: microk8s.kubectl wait -n kube-system --for = condition = Ready pod -l k8s-app = kube-dns microk8s.kubectl wait -n kube-system --for = condition = Ready pod -l k8s-app = hostpath-provisioner # If the following command fails, you probably installed the wrong MicroK8s version microk8s.kubectl wait --all-namespaces --for = condition = Ready pod -l name = nginx-ingress-microk8s Verify that the MicroK8s configuration was successful: microk8s.status --wait-ready The output of the command should be the following: microk8s is running addons: knative: disabled jaeger: disabled fluentd: disabled gpu: disabled cilium: disabled storage: enabled registry: disabled rbac: disabled ingress: enabled dns: enabled metrics-server: disabled linkerd: disabled prometheus: disabled istio: disabled dashboard: disabled After these steps you have ensured that DNS, HTTP, and NGINX Ingress are enabled and working properly inside the MicroK8s instance. Notes on installing Codacy # You can now follow the generic Codacy installation instructions but please note the following: You must execute all kubectl commands as microk8s.kubectl commands instead. To simplify this, we suggest that you create an alias so that you can run the commands directly as provided on the instructions: alias kubectl = microk8s.kubectl When running the helm upgrade command that installs the Codacy chart, you will be instructed to also use the file values-microk8s.yaml that downsizes some component limits, making it easier to fit Codacy in the lightweight MicroK8s solution.", "title": "Creating a MicroK8s cluster"}, {"location": "chart/infrastructure/microk8s-quickstart/#creating-a-microk8s-cluster", "text": "Follow the instructions below to set up a MicroK8s instance from scratch, including all the necessary dependencies and configurations. MicroK8s is a lightweight, fully conformant, single-package Kubernetes developed by Canonical. The project is publicly available on GitHub .", "title": "Creating a MicroK8s cluster"}, {"location": "chart/infrastructure/microk8s-quickstart/#1-prepare-your-environment", "text": "Prepare your environment to set up the MicroK8s instance. You will need a machine running Ubuntu Server 20.04 LTS that: Is correctly provisioned with the resources described for MicroK8s in the system requirements Is able to establish a connection to the PostgreSQL instance described in the system requirements Make sure that you have Helm version 3.8.1 installed. The next steps assume that you're starting from a clean install of Ubuntu Server and require that you run commands on a local or remote command line session on the machine.", "title": "1. Prepare your environment"}, {"location": "chart/infrastructure/microk8s-quickstart/#2-installing-microk8s", "text": "Install MicroK8s on the machine: Make sure that the package nfs-common is installed: sudo apt update && sudo apt install nfs-common -y Install MicroK8s from the 1.19/stable channel: sudo snap install microk8s --classic --channel = 1 .19/stable sudo usermod -a -G microk8s $USER sudo su - $USER Check that MicroK8s is running: microk8s.status --wait-ready If you're running MicroK8s using a single node, disable high-availability clustering for improved performance: microk8s.disable ha-cluster", "title": "2. Installing MicroK8s"}, {"location": "chart/infrastructure/microk8s-quickstart/#3-configuring-microk8s", "text": "Now that MicroK8s is running on the machine we can proceed to enabling the necessary addons: Configure MicroK8s to allow privileged containers: sudo mkdir -p /var/snap/microk8s/current/args sudo echo \"--allow-privileged=true\" >> /var/snap/microk8s/current/args/kube-apiserver microk8s.status --wait-ready Enable the following MicroK8s addons: microk8s.enable dns microk8s.status --wait-ready microk8s.enable storage microk8s.status --wait-ready microk8s.enable ingress microk8s.status --wait-ready Important Check the output of the commands to make sure that all the addons are enabled correctly. If by chance any of the addons fails to be enabled, re-execute the microk8s.enable command for that addon. Restart MicroK8s and its services to make sure that all configurations are working: microk8s.stop microk8s.start microk8s.status --wait-ready Export your kubeconfig so that Helm knows on which cluster to install the charts: microk8s.config > ~/.kube/config The addons are now enabled and the MicroK8s instance bootstrapped. However, we must wait for some MicroK8s pods to be ready, as failing to do so can result in the pods entering a CrashLoopBackoff state: microk8s.kubectl wait -n kube-system --for = condition = Ready pod -l k8s-app = kube-dns microk8s.kubectl wait -n kube-system --for = condition = Ready pod -l k8s-app = hostpath-provisioner # If the following command fails, you probably installed the wrong MicroK8s version microk8s.kubectl wait --all-namespaces --for = condition = Ready pod -l name = nginx-ingress-microk8s Verify that the MicroK8s configuration was successful: microk8s.status --wait-ready The output of the command should be the following: microk8s is running addons: knative: disabled jaeger: disabled fluentd: disabled gpu: disabled cilium: disabled storage: enabled registry: disabled rbac: disabled ingress: enabled dns: enabled metrics-server: disabled linkerd: disabled prometheus: disabled istio: disabled dashboard: disabled After these steps you have ensured that DNS, HTTP, and NGINX Ingress are enabled and working properly inside the MicroK8s instance.", "title": "3. Configuring MicroK8s"}, {"location": "chart/infrastructure/microk8s-quickstart/#notes-on-installing-codacy", "text": "You can now follow the generic Codacy installation instructions but please note the following: You must execute all kubectl commands as microk8s.kubectl commands instead. To simplify this, we suggest that you create an alias so that you can run the commands directly as provided on the instructions: alias kubectl = microk8s.kubectl When running the helm upgrade command that installs the Codacy chart, you will be instructed to also use the file values-microk8s.yaml that downsizes some component limits, making it easier to fit Codacy in the lightweight MicroK8s solution.", "title": "Notes on installing Codacy"}, {"location": "chart/maintenance/database/", "text": "Database migration guide # Migrating databases between pods is a straightforward process with 3 steps: Dump the databases to a dump file. Apply the dump file. Delete the dump file. You will have to dump all the following databases: accounts analysis filestore jobs metrics results Requirements # The following operations must be executed by a user which has elevated access ( SUPERUSER ) in the Postgres databases. Dumping your current data out of a running Postgres # You will need to know the following: $HOSTNAME - the hostname where the database is located. $DB_USER - the username with privileged access to the database that will perform the dump. $DB - the database that you would like to export. $DB_PASSWORD - the database password. pg_dump # The following command lets you extract a given database into a dump file: PGPASSWORD = $DB_PASSWORD pg_dump -h $SRC_HOSTNAME -p $SRC_HOSTPORT -U $DB_USER --clean -Fc $db > /tmp/ $db .dump This will dump the file with the .dump extension into the /tmp folder. For more information and additional options, please check the official documentation. pg_restore # To restore a database, you can run a pg_restore command to consume the dump file and replicate the data onto Postgres: PGPASSWORD = $DB_PASSWORD pg_restore -h $DEST_HOSTNAME -p $DEST_HOSTPORT -U $DB_USER -j 8 -d $db -n public --clean $db .dump With the custom format from pg_dump (by using -Fc ) we can now invoke pg_restore with multiple parallel jobs. This should make the restoration of the databases quicker, depending on which value you provide for the number of parallel jobs to execute. We provide a value of 8 parallel jobs in the example above ( -j 8 ). Note If you run into any problems while restoring, make sure that you have the database created in that Postgres instance (e.g. before restoring the jobs database the Postgres instance should have an empty database called jobs created there). For more information and additional options, please check the official documentation . Sample script # Assuming you have the same $DB_USER and $DB_PASSWORD , and that you want to migrate all the databases from the same hostname to the same destination hostname, you could migrate your databases with the following sample script: SRC_HOSTNAME = $1 SRC_HOSTPORT = $2 DEST_HOSTNAME = $3 DEST_HOSTPORT = $4 DB_USER = $5 DB_PASSWORD = $6 declare -a dbs =( accounts analysis filestore jobs metrics results ) for db in ${ dbs [@] } do PGPASSWORD = $DB_PASSWORD pg_dump -h $SRC_HOSTNAME -p $SRC_HOSTPORT -U $DB_USER --clean -Fc $db > /tmp/ $db .dump PGPASSWORD = $DB_PASSWORD pg_restore -h $DEST_HOSTNAME -p $DEST_HOSTPORT -U $DB_USER -d $db -n public --clean $db .dump done As an example, you could run the script as follows: migrateDBs.sh postgres\u2013instance1.us-east-1.rds.amazonaws.com 25060 postgres\u2013instance1.eu-west-1.rds.amazonaws.com 25060 super_user secret_password", "title": "Database migration guide"}, {"location": "chart/maintenance/database/#database-migration-guide", "text": "Migrating databases between pods is a straightforward process with 3 steps: Dump the databases to a dump file. Apply the dump file. Delete the dump file. You will have to dump all the following databases: accounts analysis filestore jobs metrics results", "title": "Database migration guide"}, {"location": "chart/maintenance/database/#requirements", "text": "The following operations must be executed by a user which has elevated access ( SUPERUSER ) in the Postgres databases.", "title": "Requirements"}, {"location": "chart/maintenance/database/#dumping-your-current-data-out-of-a-running-postgres", "text": "You will need to know the following: $HOSTNAME - the hostname where the database is located. $DB_USER - the username with privileged access to the database that will perform the dump. $DB - the database that you would like to export. $DB_PASSWORD - the database password.", "title": "Dumping your current data out of a running Postgres"}, {"location": "chart/maintenance/database/#sample-script", "text": "Assuming you have the same $DB_USER and $DB_PASSWORD , and that you want to migrate all the databases from the same hostname to the same destination hostname, you could migrate your databases with the following sample script: SRC_HOSTNAME = $1 SRC_HOSTPORT = $2 DEST_HOSTNAME = $3 DEST_HOSTPORT = $4 DB_USER = $5 DB_PASSWORD = $6 declare -a dbs =( accounts analysis filestore jobs metrics results ) for db in ${ dbs [@] } do PGPASSWORD = $DB_PASSWORD pg_dump -h $SRC_HOSTNAME -p $SRC_HOSTPORT -U $DB_USER --clean -Fc $db > /tmp/ $db .dump PGPASSWORD = $DB_PASSWORD pg_restore -h $DEST_HOSTNAME -p $DEST_HOSTPORT -U $DB_USER -d $db -n public --clean $db .dump done As an example, you could run the script as follows: migrateDBs.sh postgres\u2013instance1.us-east-1.rds.amazonaws.com 25060 postgres\u2013instance1.eu-west-1.rds.amazonaws.com 25060 super_user secret_password", "title": "Sample script"}, {"location": "chart/maintenance/license/", "text": "Updating your Codacy license # Some changes to your Codacy plan require that you update your Codacy Self-hosted license with a new one provided by a Codacy representative: Edit the value of codacy-api.config.license in the values-production.yaml file that you used to install Codacy: codacy-api : config : license : <--- insert your Codacy license here ---> Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml Checking the expiration date of your Codacy license # To check the expiration date of your Codacy license, do the following: Click the Admin link in the top right-hand corner. On the Dashboard page, search for your organization and click the organization identifier to navigate to its details. On the Organization details , check your Plan expiry date .", "title": "Updating your Codacy license"}, {"location": "chart/maintenance/license/#updating-your-codacy-license", "text": "Some changes to your Codacy plan require that you update your Codacy Self-hosted license with a new one provided by a Codacy representative: Edit the value of codacy-api.config.license in the values-production.yaml file that you used to install Codacy: codacy-api : config : license : <--- insert your Codacy license here ---> Apply the new configuration by performing a Helm upgrade. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version 14 .0.0 \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "Updating your Codacy license"}, {"location": "chart/maintenance/license/#checking-the-expiration-date-of-your-codacy-license", "text": "To check the expiration date of your Codacy license, do the following: Click the Admin link in the top right-hand corner. On the Dashboard page, search for your organization and click the organization identifier to navigate to its details. On the Organization details , check your Plan expiry date .", "title": "Checking the expiration date of your Codacy license"}, {"location": "chart/maintenance/uninstall/", "text": "Uninstalling Codacy # To ensure a clean removal you should uninstall Codacy Self-hosted before destroying the cluster. To do so run: helm -n codacy uninstall codacy kubectl -n codacy delete --all pod & kubectl -n codacy delete --all pvc & kubectl -n codacy delete --all job & sleep 5 kubectl -n codacy patch pvc -p '{\"metadata\":{\"finalizers\":null}}' $( kubectl -n codacy get pvc -o jsonpath = '{.items[*].metadata.name}' ) sleep 5 kubectl -n codacy delete pod $( kubectl -n codacy get pod -o jsonpath = '{.items[*].metadata.name}' ) --force --grace-period = 0 kubectl -n codacy get pod & kubectl -n codacy get pvc & kubectl -n codacy get job & Note that the deletion of pvc s in the above command has to run in the background due to a cyclic dependency in one of the components. If you're unsure of the effects of these commands please run each of the bash subcommands and validate their output: echo \"PVCs to delete:\" kubectl get pvc -n codacy -o jsonpath = '{.items[*].metadata.name}' echo \"PODS to delete:\" kubectl get pods -n codacy -o jsonpath = '{.items[*].metadata.name}'", "title": "Uninstalling Codacy"}, {"location": "chart/maintenance/uninstall/#uninstalling-codacy", "text": "To ensure a clean removal you should uninstall Codacy Self-hosted before destroying the cluster. To do so run: helm -n codacy uninstall codacy kubectl -n codacy delete --all pod & kubectl -n codacy delete --all pvc & kubectl -n codacy delete --all job & sleep 5 kubectl -n codacy patch pvc -p '{\"metadata\":{\"finalizers\":null}}' $( kubectl -n codacy get pvc -o jsonpath = '{.items[*].metadata.name}' ) sleep 5 kubectl -n codacy delete pod $( kubectl -n codacy get pod -o jsonpath = '{.items[*].metadata.name}' ) --force --grace-period = 0 kubectl -n codacy get pod & kubectl -n codacy get pvc & kubectl -n codacy get job & Note that the deletion of pvc s in the above command has to run in the background due to a cyclic dependency in one of the components. If you're unsure of the effects of these commands please run each of the bash subcommands and validate their output: echo \"PVCs to delete:\" kubectl get pvc -n codacy -o jsonpath = '{.items[*].metadata.name}' echo \"PODS to delete:\" kubectl get pods -n codacy -o jsonpath = '{.items[*].metadata.name}'", "title": "Uninstalling Codacy"}, {"location": "chart/maintenance/upgrade/", "text": "Upgrading Codacy # To upgrade Codacy Self-hosted to the latest stable version: Check the release notes for all Codacy Self-hosted versions between your current version and the most recent version for breaking changes and follow the instructions provided carefully. Warning Failing to follow the steps to deal with breaking changes can cause the upgrade to fail or cause problems while Codacy is running. In particular, Codacy Self-hosted v5.0.0 drops the support for legacy manual organizations . Tip To see the version of your Codacy Self-hosted instance click your avatar on the top right-hand corner of any Codacy page: Store all your currently defined configuration values in a file: helm get values codacy \\ --namespace codacy \\ --output yaml > codacy.yaml Note If you installed Codacy on a Kubernetes namespace different from codacy , make sure that you adjust the namespace when executing the commands in this page. Review the values stored in the file codacy.yaml , making any changes if necessary. Perform the upgrade using the values stored in the file: helm repo update helm upgrade codacy codacy-stable/codacy \\ --version 14 .0.0 \\ --namespace codacy \\ --values codacy.yaml Update your Codacy command-line tools to the versions with the Git tag self-hosted-14.0.0 : Codacy Analysis CLI Codacy Coverage Reporter", "title": "Upgrading Codacy"}, {"location": "chart/maintenance/upgrade/#upgrading-codacy", "text": "To upgrade Codacy Self-hosted to the latest stable version: Check the release notes for all Codacy Self-hosted versions between your current version and the most recent version for breaking changes and follow the instructions provided carefully. Warning Failing to follow the steps to deal with breaking changes can cause the upgrade to fail or cause problems while Codacy is running. In particular, Codacy Self-hosted v5.0.0 drops the support for legacy manual organizations . Tip To see the version of your Codacy Self-hosted instance click your avatar on the top right-hand corner of any Codacy page: Store all your currently defined configuration values in a file: helm get values codacy \\ --namespace codacy \\ --output yaml > codacy.yaml Note If you installed Codacy on a Kubernetes namespace different from codacy , make sure that you adjust the namespace when executing the commands in this page. Review the values stored in the file codacy.yaml , making any changes if necessary. Perform the upgrade using the values stored in the file: helm repo update helm upgrade codacy codacy-stable/codacy \\ --version 14 .0.0 \\ --namespace codacy \\ --values codacy.yaml Update your Codacy command-line tools to the versions with the Git tag self-hosted-14.0.0 : Codacy Analysis CLI Codacy Coverage Reporter", "title": "Upgrading Codacy"}, {"location": "chart/troubleshoot/k8s-cheatsheet/", "text": "Kubernetes cheatsheet # Debugging using events # Important Always check the pods and deployment versions in the namespace to make sure you aren't debugging an issue in a version that's not the one you would expect Events are a great way to understand what's going on under the hood in a Kubernetes cluster. By looking at them you can see if probes are failing, and other important signals from your cluster. Get events for the whole namespace: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp Get error events: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp --field-selector type = Error Get warning events: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp --field-selector type = Warning Get events from a specific pod: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp --field-selector involvedObject.name = Helm # Check all the previous releases in your namespace: helm -n codacy history codacy Rollback to a specific revision: helm -n codacy rollback codacy Edit configmap # kubectl get configmaps and kubectl edit configmap Restart deployment of daemonset # daemonsets # kubectl get daemonsets and kubectl rollout restart daemonset/ deployment # kubectl get deployment and kubectl rollout restart deployment/ and kubectl rollout status deployment/ -w Read logs # daemonset with multiple containers # kubectl logs daemonset/ -f service # kubectl get svc and kubectl logs -l $( kubectl get svc/ -o = json | jq \".spec.selector\" | jq -r 'to_entries|map(\"\\(.key)=\\(.value|tostring)\")|.[]' | sed -e 'H;${x;s/\\n/,/g;s/^,//;p;};d' ) -f Open shell inside container # kubectl exec -it daemonset/ -c sh or kubectl exec -it deployment/ sh MicroK8s # Session Manager SSH # When using AWS Session Manager, to connect to the instance where you installed microk8s, since the CLI is very limited you will benefit from using these aliases: alias kubectl = 'sudo microk8s.kubectl -n ' alias helm = 'sudo helm'", "title": "Kubernetes cheatsheet"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#kubernetes-cheatsheet", "text": "", "title": "Kubernetes cheatsheet"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#debugging-using-events", "text": "Important Always check the pods and deployment versions in the namespace to make sure you aren't debugging an issue in a version that's not the one you would expect Events are a great way to understand what's going on under the hood in a Kubernetes cluster. By looking at them you can see if probes are failing, and other important signals from your cluster. Get events for the whole namespace: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp Get error events: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp --field-selector type = Error Get warning events: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp --field-selector type = Warning Get events from a specific pod: kubectl -n codacy get events --sort-by = .metadata.creationTimestamp --field-selector involvedObject.name = ", "title": "Debugging using events"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#helm", "text": "Check all the previous releases in your namespace: helm -n codacy history codacy Rollback to a specific revision: helm -n codacy rollback codacy ", "title": "Helm"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#edit-configmap", "text": "kubectl get configmaps and kubectl edit configmap ", "title": "Edit configmap"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#restart-deployment-of-daemonset", "text": "", "title": "Restart deployment of daemonset"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#read-logs", "text": "", "title": "Read logs"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#open-shell-inside-container", "text": "kubectl exec -it daemonset/ -c sh or kubectl exec -it deployment/ sh", "title": "Open shell inside container"}, {"location": "chart/troubleshoot/k8s-cheatsheet/#microk8s", "text": "", "title": "MicroK8s"}, {"location": "chart/troubleshoot/logs-collect/", "text": "Collecting logs for Support # To help troubleshoot issues, obtain the logs from your Codacy Self-hosted instance and send them to Codacy's Support: Run the following command on a machine with network access to the Codacy cluster, replacing with the namespace in which Codacy was installed: bash < ( curl -fsSL https://raw.githubusercontent.com/codacy/chart/master/docs/troubleshoot/extract-codacy-logs.sh ) \\ -n This will download the logs of the last 7 days as an archive file with the name codacy_logs_.zip . Tip You can also download the script extract-codacy-logs.sh to run it manually. Send the compressed logs to Codacy's support team at support@codacy.com for analysis. Note If the file is too big, please upload the file to either a cloud storage service such as Google Drive or to a file transfer service such as WeTransfer and send us the link to the file instead. Alternatively, to reduce the size of the compressed archive file, retrieve logs for a smaller number of days by replacing with a number between 1 and 7: bash < ( curl -fsSL https://raw.githubusercontent.com/codacy/chart/master/docs/troubleshoot/extract-codacy-logs.sh ) \\ -n -d ", "title": "Collecting logs for Support"}, {"location": "chart/troubleshoot/logs-collect/#collecting-logs-for-support", "text": "To help troubleshoot issues, obtain the logs from your Codacy Self-hosted instance and send them to Codacy's Support: Run the following command on a machine with network access to the Codacy cluster, replacing with the namespace in which Codacy was installed: bash < ( curl -fsSL https://raw.githubusercontent.com/codacy/chart/master/docs/troubleshoot/extract-codacy-logs.sh ) \\ -n This will download the logs of the last 7 days as an archive file with the name codacy_logs_.zip . Tip You can also download the script extract-codacy-logs.sh to run it manually. Send the compressed logs to Codacy's support team at support@codacy.com for analysis. Note If the file is too big, please upload the file to either a cloud storage service such as Google Drive or to a file transfer service such as WeTransfer and send us the link to the file instead. Alternatively, to reduce the size of the compressed archive file, retrieve logs for a smaller number of days by replacing with a number between 1 and 7: bash < ( curl -fsSL https://raw.githubusercontent.com/codacy/chart/master/docs/troubleshoot/extract-codacy-logs.sh ) \\ -n -d ", "title": "Collecting logs for Support"}, {"location": "chart/troubleshoot/troubleshoot/", "text": "Troubleshooting Codacy Self-hosted # This page includes information to help you troubleshoot issues that you may come across while installing, configuring, and operating Codacy Self-hosted. If the information provided on this page isn't enough to solve your issue, contact support@codacy.com providing: The description of the issue All the information that you were able to obtain while following these troubleshooting instructions The collected logs of your Codacy instance The version of your Codacy instance Tip To see the version of your Codacy Self-hosted instance click your avatar on the top right-hand corner of any Codacy page: Git provider integrations # The following sections help you troubleshoot the integration of Codacy with your Git provider. GitHub Cloud and GitHub Enterprise authentication # 404 error # While trying to authenticate on GitHub you get the following error message: This might mean that there is a mismatch in the Client ID that Codacy is using to authenticate on GitHub. To solve this issue: Make sure that the value of clientId in your values-production.yaml file is the same as the Client ID of the GitHub App that you created If the values were different, update your configuration and re-execute the helm upgrade command as described for GitHub Cloud or GitHub Enterprise If the error persists: Take note of the parameter client_id in the URL of the GitHub error page (for example, Iv1.0000000000000000 ) Check if the value of the parameter matches the value of the Client ID of your GitHub App GitLab Cloud and GitLab Enterprise authentication # Invalid redirect URI # While trying to authenticate on GitLab you get the following error message: This might mean that the redirect URIs are not correct in the GitLab application that Codacy is using to authenticate on GitLab. To solve this issue: Open the GitLab application that you created on GitLab Cloud or GitLab Enterprise Make sure that all the redirect URIs have the correct protocol for the Codacy instance endpoints, either http:// or https:// Make sure that all the redirect URIs have the full path with the correct case, since the field is case-sensitive If the error persists: Take note of the parameter redirect_uri in the URL of the GitLab error page (for example, https%3A%2F%2Fcodacy.example.com%2Flogin%2FGitLab or https%3A%2F%2Fcodacy.example.com%2Flogin%2FGitLabEnterprise ) Decode the value of the parameter using a tool such as urldecoder.com (for example, https://codacy.example.com/login/GitLab or https://codacy.example.com/login/GitLabEnterprise ) Check if the decoded value matches one of the redirect URIs of your GitLab application Unknown client # While trying to authenticate on GitLab you get the following error message: This might mean that there is a mismatch in the Application ID that Codacy is using to authenticate on GitLab. To solve this issue: Make sure that the value of clientId in your values-production.yaml file is the same as the Application ID of the GitLab Cloud or GitLab Enterprise application that you created If the values were different, update your configuration and re-execute the helm upgrade command as described for GitLab Cloud or GitLab Enterprise If the error persists: Take note of the parameter client_id in the URL of the GitLab error page (for example, cca35a2a1f9b9b516ac927d82947bd5149b0e57e922c9e5564ac092ea16a3ccd ) Check if the value of the parameter matches the value of the Application ID of your GitLab application Bitbucket Cloud authentication # Invalid client_id # While trying to authenticate on Bitbucket Cloud you get the following error message: This might mean that there is a mismatch in the OAuth consumer Client ID that Codacy is using to authenticate on Bitbucket Cloud. To solve this issue: Make sure that the value of key in your values-production.yaml file is the same as the Key of the Bitbucket OAuth consumer that you created If the values were different, update your configuration and re-execute the helm upgrade command as described for Bitbucket Cloud If the error persists: Take note of the parameter client_id in the URL of the Bitbucket Cloud error page (for example, r8QJDkkxj8unYfg4Bd ) Check if the value of the parameter matches the value of the Client ID of your Bitbucket OAuth consumer Accessing the RabbitMQ dashboard # We use RabbitMQ for the internal message queue between our components. If you need to access the RabbitMQ dashboard: Create a port-forward from the rabbitmq pod to your local machine, replacing with the namespace in which Codacy was installed: kubectl port-forward codacy-rabbitmq-ha-0 15672 :15672 --namespace = Important If you're using MicroK8s use microk8s.kubectl instead of kubectl . Access the RabbitMQ dashboard on the address localhost:15672 , and log in with the configured RabbitMQ credentials. The default RabbitMQ credentials are the following: Username: rabbitmq-codacy Password: rabbitmq-codacy Missing new tools # If the Code patterns page of your repositories doesn't list a new tool that was included in a new Codacy version, force the list of available tools to refresh by running the following command on any codacy-engine-* pod: curl -X POST localhost:9000/api/v1/engine/initialize Upgrade failed: cannot patch \"codacy-minio\" # If you download and use an updated values-production.yaml file while upgrading to Codacy Self-hosted 9.0.0 , you'll get the following error: Error: UPGRADE FAILED: cannot patch \"codacy-minio\" with kind PersistentVolumeClaim: persistentvolumeclaims \"codacy-minio\" is forbidden: only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize This happens because we updated the MinIO PVC size . As a workaround, you can either: Reset the PVC size back to the original value of 20Gi on your values.yaml file: minio : fullnameOverride : codacy-minio persistence : size : 20Gi Uninstall your current version of Codacy and reinstall Codacy Self-hosted 9.0.0 directly. Your data won't be impacted by the uninstall since it's stored on the database.", "title": "Troubleshooting Codacy Self-hosted"}, {"location": "chart/troubleshoot/troubleshoot/#troubleshooting-codacy-self-hosted", "text": "This page includes information to help you troubleshoot issues that you may come across while installing, configuring, and operating Codacy Self-hosted. If the information provided on this page isn't enough to solve your issue, contact support@codacy.com providing: The description of the issue All the information that you were able to obtain while following these troubleshooting instructions The collected logs of your Codacy instance The version of your Codacy instance Tip To see the version of your Codacy Self-hosted instance click your avatar on the top right-hand corner of any Codacy page:", "title": "Troubleshooting Codacy Self-hosted"}, {"location": "chart/troubleshoot/troubleshoot/#git-provider-integrations", "text": "The following sections help you troubleshoot the integration of Codacy with your Git provider.", "title": "Git provider integrations"}, {"location": "chart/troubleshoot/troubleshoot/#accessing-the-rabbitmq-dashboard", "text": "We use RabbitMQ for the internal message queue between our components. If you need to access the RabbitMQ dashboard: Create a port-forward from the rabbitmq pod to your local machine, replacing with the namespace in which Codacy was installed: kubectl port-forward codacy-rabbitmq-ha-0 15672 :15672 --namespace = Important If you're using MicroK8s use microk8s.kubectl instead of kubectl . Access the RabbitMQ dashboard on the address localhost:15672 , and log in with the configured RabbitMQ credentials. The default RabbitMQ credentials are the following: Username: rabbitmq-codacy Password: rabbitmq-codacy", "title": "Accessing the RabbitMQ dashboard"}, {"location": "chart/troubleshoot/troubleshoot/#missing-new-tools", "text": "If the Code patterns page of your repositories doesn't list a new tool that was included in a new Codacy version, force the list of available tools to refresh by running the following command on any codacy-engine-* pod: curl -X POST localhost:9000/api/v1/engine/initialize", "title": "Missing new tools"}, {"location": "chart/troubleshoot/troubleshoot/#upgrade-failed-cannot-patch-codacy-minio", "text": "If you download and use an updated values-production.yaml file while upgrading to Codacy Self-hosted 9.0.0 , you'll get the following error: Error: UPGRADE FAILED: cannot patch \"codacy-minio\" with kind PersistentVolumeClaim: persistentvolumeclaims \"codacy-minio\" is forbidden: only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize This happens because we updated the MinIO PVC size . As a workaround, you can either: Reset the PVC size back to the original value of 20Gi on your values.yaml file: minio : fullnameOverride : codacy-minio persistence : size : 20Gi Uninstall your current version of Codacy and reinstall Codacy Self-hosted 9.0.0 directly. Your data won't be impacted by the uninstall since it's stored on the database.", "title": "Upgrade failed: cannot patch \"codacy-minio\""}, {"location": "codacy-api/api-tokens/", "text": "API tokens # Codacy provides account and repository -level API tokens that allow you to: Upload coverage data to Codacy Upload to Codacy the results of running client-side analysis tools Authenticate when using the Codacy API The sections below provide details about the two types of API tokens and instructions on how to generate and revoke them. Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. Generating and revoking account API tokens # Account API tokens are defined at the Codacy user account level . Each account API token authorizes access to the same organizations, repositories, and operations as the roles and permissions of the owner of the account . Important If you're using an account API token to upload coverage be sure to check the roles that your Git provider account must have to authorize uploading coverage to Codacy. Use a dedicated service account to integrate Codacy with your repositories. This prevents disruption of service if the user who created an account API token loses access to the repositories, which may happen when a user leaves the team or the organization. You can create new account API tokens programmatically using the Codacy API or using the Codacy UI: Open your account, tab Access management . Click the button Create API token under Account API tokens . Tip You can create multiple account API tokens. This can be useful to have a more flexible control by revoking only a specific token. To revoke an account API token, click the \"X\" next to the token. After this, all applications or services using that token to access the Codacy API will fail to authenticate and will receive the reply {\"error\":\"not found\"} . Generating and revoking repository API tokens # Repository API tokens are defined on individual repositories . Each repository API token only authorizes access to the corresponding repository. You can create new repository API tokens programmatically using the Codacy API or using the Codacy UI: Open your repository Settings , tab Integrations . Click the button Create API token under Repository API tokens . Tip You can create multiple (up to 100) API tokens per repository. This can be useful to have a more flexible control by revoking only a specific token. To revoke a repository API token, click the X next to the token. After this, all applications or services using that token to access the Codacy API will fail to authenticate and will receive the reply {\"error\":\"not found\"} . See also # Adding coverage to your repository Client-side tools Creating repository API tokens programmatically", "title": "API tokens"}, {"location": "codacy-api/api-tokens/#api-tokens", "text": "Codacy provides account and repository -level API tokens that allow you to: Upload coverage data to Codacy Upload to Codacy the results of running client-side analysis tools Authenticate when using the Codacy API The sections below provide details about the two types of API tokens and instructions on how to generate and revoke them. Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this.", "title": "API tokens"}, {"location": "codacy-api/api-tokens/#account-api-tokens", "text": "Account API tokens are defined at the Codacy user account level . Each account API token authorizes access to the same organizations, repositories, and operations as the roles and permissions of the owner of the account . Important If you're using an account API token to upload coverage be sure to check the roles that your Git provider account must have to authorize uploading coverage to Codacy. Use a dedicated service account to integrate Codacy with your repositories. This prevents disruption of service if the user who created an account API token loses access to the repositories, which may happen when a user leaves the team or the organization. You can create new account API tokens programmatically using the Codacy API or using the Codacy UI: Open your account, tab Access management . Click the button Create API token under Account API tokens . Tip You can create multiple account API tokens. This can be useful to have a more flexible control by revoking only a specific token. To revoke an account API token, click the \"X\" next to the token. After this, all applications or services using that token to access the Codacy API will fail to authenticate and will receive the reply {\"error\":\"not found\"} .", "title": "Generating and revoking account API tokens"}, {"location": "codacy-api/api-tokens/#repository-api-tokens", "text": "Repository API tokens are defined on individual repositories . Each repository API token only authorizes access to the corresponding repository. You can create new repository API tokens programmatically using the Codacy API or using the Codacy UI: Open your repository Settings , tab Integrations . Click the button Create API token under Repository API tokens . Tip You can create multiple (up to 100) API tokens per repository. This can be useful to have a more flexible control by revoking only a specific token. To revoke a repository API token, click the X next to the token. After this, all applications or services using that token to access the Codacy API will fail to authenticate and will receive the reply {\"error\":\"not found\"} .", "title": "Generating and revoking repository API tokens"}, {"location": "codacy-api/api-tokens/#see-also", "text": "Adding coverage to your repository Client-side tools Creating repository API tokens programmatically", "title": "See also"}, {"location": "codacy-api/using-the-codacy-api/", "text": "Using the Codacy API # The Codacy API allows you to programmatically retrieve and analyze data from Codacy and perform a few configuration changes. Codacy supports two API versions but we strongly recommend using the new API v3 when possible since it's the version being actively developed. Import the OpenAPI 2.0 definition provided below into your development tools to help bootstrap your integration with Codacy. API v3 (recommended) API v2 Endpoint documentation https://api.codacy.com/api/api-docs https://api.codacy.com/api-docs OpenAPI 2.0 definition https://api.codacy.com/api/api-docs/swagger.yaml - Base URL https://api.codacy.com/api/v3 https://api.codacy.com/ Overview Use the new endpoints to access and manipulate the following resources, among others: Analysis details, issue and ignored issue details, repository quality settings Account details and API token management Organization details and join request management People management Repository management and file details Tool and code pattern details Use the legacy endpoints to access and manipulate the following resources: Commit code quality details and deltas Project details and configurations, file code quality and issue details Important If you're using Codacy Self-hosted you must use your own Codacy instance domain name in the API URLs to access the endpoint documentation matching your Codacy Self-hosted version and to call the endpoints on your Codacy instance. For example, use the following URLs for the API v3 endpoint documentation and endpoints: https:///api/api-docs https:///api/v3 Authenticating requests # Most API endpoints require that you authenticate using an API token. After obtaining the necessary tokens , include them in your request headers using the format api-token: or project-token: . Note Currently, all API v3 endpoints that require authentication must use account API tokens , while the API v2 endpoints require either account or repository API tokens . Performing GET requests for public repositories doesn't require authentication. For example, to make a request to an API v3 endpoint that requires an account API token: curl -X GET 'https://api.codacy.com/api/v3/user/organizations/gh' \\ -H 'api-token: ' Or to make a request to an API v2 endpoint that requires a repository API token: curl -X GET 'https://api.codacy.com/2.0/commit/da275c14ffab6e402dcc6009828067ffa44b7ee0' \\ -H 'project-token: ' Using parameters in requests # Most API endpoints require that you specify parameters. For GET requests , specify parameters directly as path segments of the endpoint URLs. Some endpoints also accept optional query string parameters. For example, to call the endpoint getRepositoryWithAnalysis with the parameters: provider: gh remoteOrganizationName: codacy repositoryName: docs branch (query string): api-overview curl -X GET 'https://app.codacy.com/api/v3/analysis/organizations/gh/codacy/repositories/docs?branch=api-overview' \\ -H 'api-token: ' For POST , PATCH , and DELETE requests , besides the parameters included in the URL you may also need to include a JSON body. For example, to call the endpoint searchRepositoryIssues specifying the issue levels Error and Warning in the body: curl -X POST 'https://app.codacy.com/api/v3/analysis/organizations/gh/codacy/repositories/docs/issues/search' \\ -H 'api-token: ' \\ -H 'Content-Type: application/json' \\ -d '{\"levels\": [\"Error\", \"Warning\"]}' Using pagination # Endpoints that return lists containing a potential large number of results use cursor-based pagination to return the results in small batches. These endpoints return the results together with a pagination object: If the pagination object includes a cursor , obtain the next page of results by calling the endpoint again using the cursor from the previous response as a query string parameter If the pagination object doesn't include a cursor , the endpoint returned the last page of results Use the query string parameter limit to configure the number of results that the endpoint returns in each page. The maximum limit is 1000 and the default is 100 The total is the total number of results that the endpoint can return Note To make sure that you receive all results when calling an endpoint with pagination, repeat the process above until the response doesn't include the cursor to obtain another page of results. For example, the following command requests the first 10 repositories in the Codacy GitHub organization: curl -X GET 'https://app.codacy.com/api/v3/organizations/gh/codacy/repositories?limit=10' -H 'api-token: ' The response includes the first 10 results, as well as the cursor to obtain the next page of results: { \"data\" : [ ... ], \"pagination\" : { \"cursor\" : \"codacy_2\" , \"limit\" : 10 , \"total\" : 156 } } To obtain the next page of results, it's necessary to include the cursor from the previous page as a parameter: curl -X GET 'https://app.codacy.com/api/v3/organizations/gh/codacy/repositories?limit=10&cursor=codacy_2' -H 'api-token: ' If you continue requesting more pages the endpoint will eventually return a pagination object that doesn't include a cursor . This means that you've reached the last page of results: { \"data\" : [ ... ], \"pagination\" : { \"limit\" : 10 , \"total\" : 156 } } Request rate limit # On Codacy Cloud the number of requests that you can perform to the Codacy API is rate limited to help us provide a reliable service: The limit is 2500 requests per 5 minutes and per source IP address When a request is rate limited, Codacy responds with an HTTP 503 or 504 error code and you should wait before attempting the request again Although it's possible for you to perform short bursts of requests to the Codacy API, you should always use a delay between requests to ensure that your API client doesn't hit the rate limits. The request rate limit doesn't apply to Codacy Self-hosted.", "title": "Using the Codacy API"}, {"location": "codacy-api/using-the-codacy-api/#using-the-codacy-api", "text": "The Codacy API allows you to programmatically retrieve and analyze data from Codacy and perform a few configuration changes. Codacy supports two API versions but we strongly recommend using the new API v3 when possible since it's the version being actively developed. Import the OpenAPI 2.0 definition provided below into your development tools to help bootstrap your integration with Codacy. API v3 (recommended) API v2 Endpoint documentation https://api.codacy.com/api/api-docs https://api.codacy.com/api-docs OpenAPI 2.0 definition https://api.codacy.com/api/api-docs/swagger.yaml - Base URL https://api.codacy.com/api/v3 https://api.codacy.com/ Overview Use the new endpoints to access and manipulate the following resources, among others: Analysis details, issue and ignored issue details, repository quality settings Account details and API token management Organization details and join request management People management Repository management and file details Tool and code pattern details Use the legacy endpoints to access and manipulate the following resources: Commit code quality details and deltas Project details and configurations, file code quality and issue details Important If you're using Codacy Self-hosted you must use your own Codacy instance domain name in the API URLs to access the endpoint documentation matching your Codacy Self-hosted version and to call the endpoints on your Codacy instance. For example, use the following URLs for the API v3 endpoint documentation and endpoints: https:///api/api-docs https:///api/v3", "title": "Using the Codacy API"}, {"location": "codacy-api/using-the-codacy-api/#authenticating-requests", "text": "Most API endpoints require that you authenticate using an API token. After obtaining the necessary tokens , include them in your request headers using the format api-token: or project-token: . Note Currently, all API v3 endpoints that require authentication must use account API tokens , while the API v2 endpoints require either account or repository API tokens . Performing GET requests for public repositories doesn't require authentication. For example, to make a request to an API v3 endpoint that requires an account API token: curl -X GET 'https://api.codacy.com/api/v3/user/organizations/gh' \\ -H 'api-token: ' Or to make a request to an API v2 endpoint that requires a repository API token: curl -X GET 'https://api.codacy.com/2.0/commit/da275c14ffab6e402dcc6009828067ffa44b7ee0' \\ -H 'project-token: '", "title": "Authenticating requests"}, {"location": "codacy-api/using-the-codacy-api/#using-parameters-in-requests", "text": "Most API endpoints require that you specify parameters. For GET requests , specify parameters directly as path segments of the endpoint URLs. Some endpoints also accept optional query string parameters. For example, to call the endpoint getRepositoryWithAnalysis with the parameters: provider: gh remoteOrganizationName: codacy repositoryName: docs branch (query string): api-overview curl -X GET 'https://app.codacy.com/api/v3/analysis/organizations/gh/codacy/repositories/docs?branch=api-overview' \\ -H 'api-token: ' For POST , PATCH , and DELETE requests , besides the parameters included in the URL you may also need to include a JSON body. For example, to call the endpoint searchRepositoryIssues specifying the issue levels Error and Warning in the body: curl -X POST 'https://app.codacy.com/api/v3/analysis/organizations/gh/codacy/repositories/docs/issues/search' \\ -H 'api-token: ' \\ -H 'Content-Type: application/json' \\ -d '{\"levels\": [\"Error\", \"Warning\"]}'", "title": "Using parameters in requests"}, {"location": "codacy-api/using-the-codacy-api/#using-pagination", "text": "Endpoints that return lists containing a potential large number of results use cursor-based pagination to return the results in small batches. These endpoints return the results together with a pagination object: If the pagination object includes a cursor , obtain the next page of results by calling the endpoint again using the cursor from the previous response as a query string parameter If the pagination object doesn't include a cursor , the endpoint returned the last page of results Use the query string parameter limit to configure the number of results that the endpoint returns in each page. The maximum limit is 1000 and the default is 100 The total is the total number of results that the endpoint can return Note To make sure that you receive all results when calling an endpoint with pagination, repeat the process above until the response doesn't include the cursor to obtain another page of results. For example, the following command requests the first 10 repositories in the Codacy GitHub organization: curl -X GET 'https://app.codacy.com/api/v3/organizations/gh/codacy/repositories?limit=10' -H 'api-token: ' The response includes the first 10 results, as well as the cursor to obtain the next page of results: { \"data\" : [ ... ], \"pagination\" : { \"cursor\" : \"codacy_2\" , \"limit\" : 10 , \"total\" : 156 } } To obtain the next page of results, it's necessary to include the cursor from the previous page as a parameter: curl -X GET 'https://app.codacy.com/api/v3/organizations/gh/codacy/repositories?limit=10&cursor=codacy_2' -H 'api-token: ' If you continue requesting more pages the endpoint will eventually return a pagination object that doesn't include a cursor . This means that you've reached the last page of results: { \"data\" : [ ... ], \"pagination\" : { \"limit\" : 10 , \"total\" : 156 } }", "title": "Using pagination"}, {"location": "codacy-api/using-the-codacy-api/#request-rate-limit", "text": "On Codacy Cloud the number of requests that you can perform to the Codacy API is rate limited to help us provide a reliable service: The limit is 2500 requests per 5 minutes and per source IP address When a request is rate limited, Codacy responds with an HTTP 503 or 504 error code and you should wait before attempting the request again Although it's possible for you to perform short bursts of requests to the Codacy API, you should always use a delay between requests to ensure that your API client doesn't hit the rate limits. The request rate limit doesn't apply to Codacy Self-hosted.", "title": "Request rate limit"}, {"location": "codacy-api/examples/adding-people-to-codacy-programmatically/", "text": "Adding people to Codacy programmatically # There are scenarios where manually adding people on the Codacy UI is inconvenient or time-consuming. For example, you're adding many people to Codacy, such as when initially onboarding all developers within a team. To add people programmatically, use the Codacy API endpoint addPeopleToOrganization by performing an HTTP POST request to /people , specifying a list of email addresses in the body of the request: curl -X POST https://app.codacy.com/api/v3/organizations///people \\ -H 'Content-Type: application/json' \\ -H 'api-token: ' \\ -d '[\"\", \"\"]' Substitute the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the organization, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server ORGANIZATION: Name of the organization on the Git provider. For example, codacy . You must have admin permissions over the organization on the Git provider. EMAIL#1...N: Email addresses of the people to be added. For example, no-reply@codacy.com . Example: Adding people from a file containing emails # We provide an example Bash script that adds all emails in a text file to Codacy. We suggest that you adapt the script to your specific scenario. The example script: Defines the account API token used to authenticate on the Codacy API. Defines the path and filename of the file containing the email addresses list. Uses awk and sed to read the email addresses list from a file. Calls the endpoint addPeopleToOrganization to add a list of email addresses to Codacy. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" FILENAME = \"emails.txt\" EMAILS = ` awk -vORS = , '{if(length($1)>0) printf(\"\\\"%s\\\",\", $1)}' $FILENAME | sed 's/,$//' ` curl -X POST \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /people\" \\ -H 'Content-Type: application/json' \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -d \"[ $EMAILS ]\" Expected format of the file containing the email addresses list: $ cat emails.txt email1@codacy.com email2@codacy.com email3@codacy.com email4@codacy.com See also # Adding people to your organization", "title": "Adding people to Codacy programmatically"}, {"location": "codacy-api/examples/adding-people-to-codacy-programmatically/#adding-people-to-codacy-programmatically", "text": "There are scenarios where manually adding people on the Codacy UI is inconvenient or time-consuming. For example, you're adding many people to Codacy, such as when initially onboarding all developers within a team. To add people programmatically, use the Codacy API endpoint addPeopleToOrganization by performing an HTTP POST request to /people , specifying a list of email addresses in the body of the request: curl -X POST https://app.codacy.com/api/v3/organizations///people \\ -H 'Content-Type: application/json' \\ -H 'api-token: ' \\ -d '[\"\", \"\"]' Substitute the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the organization, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server ORGANIZATION: Name of the organization on the Git provider. For example, codacy . You must have admin permissions over the organization on the Git provider. EMAIL#1...N: Email addresses of the people to be added. For example, no-reply@codacy.com .", "title": "Adding people to Codacy programmatically"}, {"location": "codacy-api/examples/adding-people-to-codacy-programmatically/#example-adding-people-from-a-file-containing-emails", "text": "We provide an example Bash script that adds all emails in a text file to Codacy. We suggest that you adapt the script to your specific scenario. The example script: Defines the account API token used to authenticate on the Codacy API. Defines the path and filename of the file containing the email addresses list. Uses awk and sed to read the email addresses list from a file. Calls the endpoint addPeopleToOrganization to add a list of email addresses to Codacy. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" FILENAME = \"emails.txt\" EMAILS = ` awk -vORS = , '{if(length($1)>0) printf(\"\\\"%s\\\",\", $1)}' $FILENAME | sed 's/,$//' ` curl -X POST \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /people\" \\ -H 'Content-Type: application/json' \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -d \"[ $EMAILS ]\" Expected format of the file containing the email addresses list: $ cat emails.txt email1@codacy.com email2@codacy.com email3@codacy.com email4@codacy.com", "title": "Example: Adding people from a file containing emails"}, {"location": "codacy-api/examples/adding-people-to-codacy-programmatically/#see-also", "text": "Adding people to your organization", "title": "See also"}, {"location": "codacy-api/examples/adding-repositories-to-codacy-programmatically/", "text": "Adding repositories to Codacy programmatically # There are scenarios where manually adding Git repositories on the Codacy UI is inconvenient or time-consuming. For example: You want to add all new repositories to Codacy when they're created on the Git provider You're adding many repositories to Codacy, such as when initially adding all repositories in your Git provider organization To add repositories programmatically, use the Codacy API v3 endpoint addRepository by performing an HTTP POST request to /repositories , specifying the Git provider and the full path of the repository in the body of the request: curl -X POST https://app.codacy.com/api/v3/repositories \\ -H 'Content-Type: application/json' \\ -H 'api-token: ' \\ -d '{\"provider\":\"\", \"repositoryFullPath\":\"\"}' Substitute the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the repository, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server REPOSITORY_FULL_PATH: Name of the organization and repository on the Git provider, using the format / . For example, codacy/docs . You must have admin permissions over the repository on the Git provider. Important If you're using GitLab you must specify the full group path and the repository using the format //...// . Example: Adding all repositories in a GitHub organization # We provide an example Bash script that adds all repositories in a GitHub Cloud organization to Codacy. We suggest that you adapt the script to your specific scenario. Warning Since Codacy automatically analyzes new repositories, adding many repositories in a short time can cause delays in the analysis of other repositories depending on the size of the repositories, the sizing of the infrastructure, and the concurrent analysis configuration. For example: Repositories added Expected delay 1 to 10 Small 11 to 100 Considerable More than 100 Extreme To avoid these delays, add repositories in small batches or space out adding new repositories over time. The example script: Defines a GitHub personal access token , the GitHub organization name, and the account API token used to authenticate on the Codacy API. Calls the GitHub API to obtain the list of all repositories in the defined organization. Uses jq to return the value of full_name for each repository obtained in the JSON response. The full_name already includes the organization and repository names using the format / . For each repository, calls the endpoint addRepository to add a new repository specifying gh as the Git provider and the value of full_name as the full path of the repository. Checks the HTTP status code obtained in the response and performs basic error handling. Pauses a few seconds between requests to the Codacy API to avoid rate limiting. #!/bin/bash GITHUB_AUTH_TOKEN = \"\" GITHUB_ORG_NAME = \"\" CODACY_API_TOKEN = \"\" printf \"Obtaining all repositories in the $GITHUB_ORG_NAME organization\\n\" for repo in $( curl -s https://api.github.com/orgs/ $GITHUB_ORG_NAME /repos -H \"Authorization: Bearer $GITHUB_AUTH_TOKEN \" | jq -r '.[] | .full_name' ) ; do printf \"Adding $repo to Codacy\\n\" http_status = $( curl -X POST https://app.codacy.com/api/v3/repositories \\ -H \"Content-Type: application/json\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -d '{\"provider\":\"gh\", \"repositoryFullPath\":\"' $repo '\"}' \\ -sSo /dev/null -w \"%{http_code}\" ) case \" $http_status \" in 200 ) printf \" $repo added successfully\\n\" ;; 401 ) printf \"Error: 401 Unauthorized, check the Codacy API token\\n\" break ;; 409 ) printf \"Error: 409 Conflict, $repo is already added to Codacy\\n\" ;; * ) printf \"Error: $http_status HTTP status code\\n\" break ;; esac sleep 60 # Pause between repositories done Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API. Besides this, the script doesn't consider paginated results obtained from the GitHub API. Learn how to use pagination on the GitHub API to ensure that you obtain all the repositories in your organization.", "title": "Adding repositories to Codacy programmatically"}, {"location": "codacy-api/examples/adding-repositories-to-codacy-programmatically/#adding-repositories-to-codacy-programmatically", "text": "There are scenarios where manually adding Git repositories on the Codacy UI is inconvenient or time-consuming. For example: You want to add all new repositories to Codacy when they're created on the Git provider You're adding many repositories to Codacy, such as when initially adding all repositories in your Git provider organization To add repositories programmatically, use the Codacy API v3 endpoint addRepository by performing an HTTP POST request to /repositories , specifying the Git provider and the full path of the repository in the body of the request: curl -X POST https://app.codacy.com/api/v3/repositories \\ -H 'Content-Type: application/json' \\ -H 'api-token: ' \\ -d '{\"provider\":\"\", \"repositoryFullPath\":\"\"}' Substitute the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the repository, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server REPOSITORY_FULL_PATH: Name of the organization and repository on the Git provider, using the format / . For example, codacy/docs . You must have admin permissions over the repository on the Git provider. Important If you're using GitLab you must specify the full group path and the repository using the format //...// .", "title": "Adding repositories to Codacy programmatically"}, {"location": "codacy-api/examples/adding-repositories-to-codacy-programmatically/#example-adding-all-repositories-in-a-github-organization", "text": "We provide an example Bash script that adds all repositories in a GitHub Cloud organization to Codacy. We suggest that you adapt the script to your specific scenario. Warning Since Codacy automatically analyzes new repositories, adding many repositories in a short time can cause delays in the analysis of other repositories depending on the size of the repositories, the sizing of the infrastructure, and the concurrent analysis configuration. For example: Repositories added Expected delay 1 to 10 Small 11 to 100 Considerable More than 100 Extreme To avoid these delays, add repositories in small batches or space out adding new repositories over time. The example script: Defines a GitHub personal access token , the GitHub organization name, and the account API token used to authenticate on the Codacy API. Calls the GitHub API to obtain the list of all repositories in the defined organization. Uses jq to return the value of full_name for each repository obtained in the JSON response. The full_name already includes the organization and repository names using the format / . For each repository, calls the endpoint addRepository to add a new repository specifying gh as the Git provider and the value of full_name as the full path of the repository. Checks the HTTP status code obtained in the response and performs basic error handling. Pauses a few seconds between requests to the Codacy API to avoid rate limiting. #!/bin/bash GITHUB_AUTH_TOKEN = \"\" GITHUB_ORG_NAME = \"\" CODACY_API_TOKEN = \"\" printf \"Obtaining all repositories in the $GITHUB_ORG_NAME organization\\n\" for repo in $( curl -s https://api.github.com/orgs/ $GITHUB_ORG_NAME /repos -H \"Authorization: Bearer $GITHUB_AUTH_TOKEN \" | jq -r '.[] | .full_name' ) ; do printf \"Adding $repo to Codacy\\n\" http_status = $( curl -X POST https://app.codacy.com/api/v3/repositories \\ -H \"Content-Type: application/json\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -d '{\"provider\":\"gh\", \"repositoryFullPath\":\"' $repo '\"}' \\ -sSo /dev/null -w \"%{http_code}\" ) case \" $http_status \" in 200 ) printf \" $repo added successfully\\n\" ;; 401 ) printf \"Error: 401 Unauthorized, check the Codacy API token\\n\" break ;; 409 ) printf \"Error: 409 Conflict, $repo is already added to Codacy\\n\" ;; * ) printf \"Error: $http_status HTTP status code\\n\" break ;; esac sleep 60 # Pause between repositories done Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API. Besides this, the script doesn't consider paginated results obtained from the GitHub API. Learn how to use pagination on the GitHub API to ensure that you obtain all the repositories in your organization.", "title": "Example: Adding all repositories in a GitHub organization"}, {"location": "codacy-api/examples/creating-repository-api-tokens-programmatically/", "text": "Creating repository API tokens programmatically # To create new repository API tokens for your Codacy repositories programmatically, use the Codacy API endpoint createRepositoryApiToken . You can also list all repository API tokens for a repository using the endpoint listRepositoryApiTokens . For example, if you're setting up coverage for all your repositories and prefer not to use a single account API token that grants the same permissions as an administrator, you need to create an individual repository API token for each repository. Example: Creating a repository API token for a single repository # This example creates a new repository API token for a repository and outputs the new token string. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, the organization name, and the repository name passed as an argument to the script. Calls the endpoint createRepositoryApiToken to create a new repository API token and uses jq to obtain only the created token string. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = $1 curl -sX POST \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /tokens\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data | .token\" Example usage and output $ ./create-token.sh website Example: Creating repository API tokens for all repositories in an organization # This example creates new repository API tokens for all the repositories in an organization and outputs a comma-separated list of repository names and corresponding token strings. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, and the organization name. Calls the endpoint listOrganizationRepositories to retrieve the list of repositories in the organization. Uses jq to select only the name of the repositories. Asks for confirmation from the user before making any changes. For each repository, calls the endpoint createRepositoryApiToken to create a new repository API token and uses jq to obtain only the created token string. Outputs a comma-separated list of the repository names and the corresponding new token strings. Pauses a few seconds between requests to the Codacy API to avoid rate limiting. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" repositories = $( curl -sX GET \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data[] | .name\" ) count = $( echo \" $repositories \" | wc -l ) read -p \"Create repository tokens for $count repositories? (y/n) \" choice if [ \" $choice \" = \"y\" ] ; then echo \" $repositories \" | while read repository ; do echo -n \" $repository ,\" curl -sX POST \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $repository /tokens\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data | .token\" sleep 2 # Wait 2 seconds done else echo \"No changes made.\" ; fi Example output: chart, docs, website, [...] Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API. Example: Listing the repository API tokens for a repository # This example lists all repository API tokens created for a repository. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, the organization name, and the repository name passed as an argument to the script. Calls the endpoint listRepositoryApiTokens to list the repository API tokens available on the repository and uses jq to obtain only the token strings, or exit with a non-zero status if the repository doesn't have any repository API tokens created yet. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = $1 curl -sX GET \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /tokens\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -er \".data[] | .token\" Example usage to obtain only the repository API token created most recently for the repository: $ ./list-tokens.sh website | head -n 1 See also # API tokens", "title": "Creating repository API tokens programmatically"}, {"location": "codacy-api/examples/creating-repository-api-tokens-programmatically/#creating-repository-api-tokens-programmatically", "text": "To create new repository API tokens for your Codacy repositories programmatically, use the Codacy API endpoint createRepositoryApiToken . You can also list all repository API tokens for a repository using the endpoint listRepositoryApiTokens . For example, if you're setting up coverage for all your repositories and prefer not to use a single account API token that grants the same permissions as an administrator, you need to create an individual repository API token for each repository.", "title": "Creating repository API tokens programmatically"}, {"location": "codacy-api/examples/creating-repository-api-tokens-programmatically/#example-creating-a-repository-api-token-for-a-single-repository", "text": "This example creates a new repository API token for a repository and outputs the new token string. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, the organization name, and the repository name passed as an argument to the script. Calls the endpoint createRepositoryApiToken to create a new repository API token and uses jq to obtain only the created token string. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = $1 curl -sX POST \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /tokens\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data | .token\" Example usage and output $ ./create-token.sh website ", "title": "Example: Creating a repository API token for a single repository"}, {"location": "codacy-api/examples/creating-repository-api-tokens-programmatically/#example-creating-repository-api-tokens-for-all-repositories-in-an-organization", "text": "This example creates new repository API tokens for all the repositories in an organization and outputs a comma-separated list of repository names and corresponding token strings. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, and the organization name. Calls the endpoint listOrganizationRepositories to retrieve the list of repositories in the organization. Uses jq to select only the name of the repositories. Asks for confirmation from the user before making any changes. For each repository, calls the endpoint createRepositoryApiToken to create a new repository API token and uses jq to obtain only the created token string. Outputs a comma-separated list of the repository names and the corresponding new token strings. Pauses a few seconds between requests to the Codacy API to avoid rate limiting. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" repositories = $( curl -sX GET \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data[] | .name\" ) count = $( echo \" $repositories \" | wc -l ) read -p \"Create repository tokens for $count repositories? (y/n) \" choice if [ \" $choice \" = \"y\" ] ; then echo \" $repositories \" | while read repository ; do echo -n \" $repository ,\" curl -sX POST \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $repository /tokens\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data | .token\" sleep 2 # Wait 2 seconds done else echo \"No changes made.\" ; fi Example output: chart, docs, website, [...] Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API.", "title": "Example: Creating repository API tokens for all repositories in an organization"}, {"location": "codacy-api/examples/creating-repository-api-tokens-programmatically/#example-listing-the-repository-api-tokens-for-a-repository", "text": "This example lists all repository API tokens created for a repository. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, the organization name, and the repository name passed as an argument to the script. Calls the endpoint listRepositoryApiTokens to list the repository API tokens available on the repository and uses jq to obtain only the token strings, or exit with a non-zero status if the repository doesn't have any repository API tokens created yet. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = $1 curl -sX GET \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /tokens\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -er \".data[] | .token\" Example usage to obtain only the repository API token created most recently for the repository: $ ./list-tokens.sh website | head -n 1 ", "title": "Example: Listing the repository API tokens for a repository"}, {"location": "codacy-api/examples/creating-repository-api-tokens-programmatically/#see-also", "text": "API tokens", "title": "See also"}, {"location": "codacy-api/examples/identifying-commits-without-coverage-data/", "text": "Identifying commits without coverage data # To calculate the supported coverage metrics for pull requests, Codacy requires that at least the following commits provide coverage data: The common ancestor commit of the pull request branch and the target branch The head commit of the pull request branch The following diagram highlights the commits that must have received coverage data for Codacy to display the coverage variation metric on a pull request: However, different factors may prevent your setup from correctly reporting coverage data for the required commits. To check if Codacy has received the required coverage data to calculate the coverage metrics for a pull request, use the Codacy API endpoint getPullRequestCoverageReports . Example: Identifying which pull request commits are missing coverage data # This example checks whether the open pull requests in a repository have received coverage data for their head and common ancestor commits. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, the organization name, and the repository name passed as an argument to the script. Calls the Codacy API endpoint listRepositoryPullRequests to retrieve the list of open pull requests on the repository. Uses jq to select only the numbers that identify the pull requests on the Git provider. For each pull request, outputs the pull request number and calls the Codacy API endpoint getPullRequestCoverageReports to obtain the information about the coverage data received for the head and common ancestor commits of the pull request. Uses jq to select and output the commit SHA-1 and coverage status for the commits. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = $1 curl -sX GET \"https://app.codacy.com/api/v3/analysis/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /pull-requests\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: application/json\" \\ | jq -r \".data[] | .pullRequest.number\" | \\ while read pull_request_number ; do echo \"Checking # $pull_request_number \" curl -sX GET \"https://app.codacy.com/api/v3/analysis/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /pull-requests/ $pull_request_number /coverage/status\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: application/json\" \\ | jq -r '.data[] | \"Coverage for \\(.commitSha) is \\(.reports[0].status)\"' done Example usage and output, where: The first commit listed for each pull request is the head commit of the pull request branch The second commit listed for each pull request is the common ancestor commit of the pull request branch Note If you find commits where the coverage status is different from Processed , follow these troubleshooting instructions to validate that your coverage setup is working correctly. $ ./check-coverage.sh pulse Checking #1563 Coverage for 4faccc86676f7dba3af2b71400605b0be4a686e3 is Processed Coverage for 51e57784468459b9b2839aa63c3e7e807a39c4ab is null Checking #1481 Coverage for 6d6a3ec0c773fb016a7302f8111c185a34e1a9b2 is null Coverage for 4015f987fab77d41dc27ec3100b57fa58bef4559 is Processed Checking #1434 Coverage for 74efe5d7542846f36cb8c030bd6b73fa9060dca2 is null Coverage for 1a64ea8885717e7b9874c9f3702806ec96b00276 is null Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API. See also # Adding coverage to your repository", "title": "Identifying commits without coverage data"}, {"location": "codacy-api/examples/identifying-commits-without-coverage-data/#identifying-commits-without-coverage-data", "text": "To calculate the supported coverage metrics for pull requests, Codacy requires that at least the following commits provide coverage data: The common ancestor commit of the pull request branch and the target branch The head commit of the pull request branch The following diagram highlights the commits that must have received coverage data for Codacy to display the coverage variation metric on a pull request: However, different factors may prevent your setup from correctly reporting coverage data for the required commits. To check if Codacy has received the required coverage data to calculate the coverage metrics for a pull request, use the Codacy API endpoint getPullRequestCoverageReports .", "title": "Identifying commits without coverage data"}, {"location": "codacy-api/examples/identifying-commits-without-coverage-data/#example-identifying-which-pull-request-commits-are-missing-coverage-data", "text": "This example checks whether the open pull requests in a repository have received coverage data for their head and common ancestor commits. The example script: Defines the account API token used to authenticate on the Codacy API, the Git provider, the organization name, and the repository name passed as an argument to the script. Calls the Codacy API endpoint listRepositoryPullRequests to retrieve the list of open pull requests on the repository. Uses jq to select only the numbers that identify the pull requests on the Git provider. For each pull request, outputs the pull request number and calls the Codacy API endpoint getPullRequestCoverageReports to obtain the information about the coverage data received for the head and common ancestor commits of the pull request. Uses jq to select and output the commit SHA-1 and coverage status for the commits. #!/bin/bash CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = $1 curl -sX GET \"https://app.codacy.com/api/v3/analysis/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /pull-requests\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: application/json\" \\ | jq -r \".data[] | .pullRequest.number\" | \\ while read pull_request_number ; do echo \"Checking # $pull_request_number \" curl -sX GET \"https://app.codacy.com/api/v3/analysis/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /pull-requests/ $pull_request_number /coverage/status\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: application/json\" \\ | jq -r '.data[] | \"Coverage for \\(.commitSha) is \\(.reports[0].status)\"' done Example usage and output, where: The first commit listed for each pull request is the head commit of the pull request branch The second commit listed for each pull request is the common ancestor commit of the pull request branch Note If you find commits where the coverage status is different from Processed , follow these troubleshooting instructions to validate that your coverage setup is working correctly. $ ./check-coverage.sh pulse Checking #1563 Coverage for 4faccc86676f7dba3af2b71400605b0be4a686e3 is Processed Coverage for 51e57784468459b9b2839aa63c3e7e807a39c4ab is null Checking #1481 Coverage for 6d6a3ec0c773fb016a7302f8111c185a34e1a9b2 is null Coverage for 4015f987fab77d41dc27ec3100b57fa58bef4559 is Processed Checking #1434 Coverage for 74efe5d7542846f36cb8c030bd6b73fa9060dca2 is null Coverage for 1a64ea8885717e7b9874c9f3702806ec96b00276 is null Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API.", "title": "Example: Identifying which pull request commits are missing coverage data"}, {"location": "codacy-api/examples/identifying-commits-without-coverage-data/#see-also", "text": "Adding coverage to your repository", "title": "See also"}, {"location": "codacy-api/examples/obtaining-code-quality-metrics-for-files/", "text": "Obtaining code quality metrics for files # To obtain the code quality information for your files in a flexible way, use the Codacy API endpoint listFiles . For example, if you're managing your source code using a monorepo strategy you may want to generate separate code quality reports for the subset of files that belong to each component or project in your repository. Example: Obtaining code quality metrics for a subdirectory of your repository # This example exports the grade, total issues, complexity, coverage, and duplication in CSV format for all files in the directory src/router of the GitHub repository codacy/website . The example script: Defines the account API token used to authenticate on the Codacy API. Calls the endpoint listFiles to retrieve the code quality metrics, filtering the results by files that include src/router/ in the path. Uses jq to select only the necessary data fields and convert the results to the CSV format. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = \"\" curl -X GET \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /files?search=src/router/\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data[] | [.path, .gradeLetter, .totalIssues, .complexity, .coverage, .duplication] | @csv\" Example output: \"src/components/router/index.ts\",\"A\",0,8,70,0 \"src/components/router/Link.tsx\",\"A\",0,5,100,0 \"src/components/router/Redirect.tsx\",\"B\",0,2,14,0 \"src/components/router/routes/account.ts\",\"A\",0,0,100,0 [...] Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API. See also # Which metrics does Codacy calculate? Files page", "title": "Obtaining code quality metrics for files"}, {"location": "codacy-api/examples/obtaining-code-quality-metrics-for-files/#obtaining-code-quality-metrics-for-files", "text": "To obtain the code quality information for your files in a flexible way, use the Codacy API endpoint listFiles . For example, if you're managing your source code using a monorepo strategy you may want to generate separate code quality reports for the subset of files that belong to each component or project in your repository.", "title": "Obtaining code quality metrics for files"}, {"location": "codacy-api/examples/obtaining-code-quality-metrics-for-files/#example-obtaining-code-quality-metrics-for-a-subdirectory-of-your-repository", "text": "This example exports the grade, total issues, complexity, coverage, and duplication in CSV format for all files in the directory src/router of the GitHub repository codacy/website . The example script: Defines the account API token used to authenticate on the Codacy API. Calls the endpoint listFiles to retrieve the code quality metrics, filtering the results by files that include src/router/ in the path. Uses jq to select only the necessary data fields and convert the results to the CSV format. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = \"\" curl -X GET \"https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /files?search=src/router/\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ | jq -r \".data[] | [.path, .gradeLetter, .totalIssues, .complexity, .coverage, .duplication] | @csv\" Example output: \"src/components/router/index.ts\",\"A\",0,8,70,0 \"src/components/router/Link.tsx\",\"A\",0,5,100,0 \"src/components/router/Redirect.tsx\",\"B\",0,2,14,0 \"src/components/router/routes/account.ts\",\"A\",0,0,100,0 [...] Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API.", "title": "Example: Obtaining code quality metrics for a subdirectory of your repository"}, {"location": "codacy-api/examples/obtaining-code-quality-metrics-for-files/#see-also", "text": "Which metrics does Codacy calculate? Files page", "title": "See also"}, {"location": "codacy-api/examples/obtaining-current-issues-in-repositories/", "text": "Obtaining current issues in repositories # To obtain information about the current issues in your repositories in a flexible way, use the Codacy API endpoint searchRepositoryIssues . For example, you may want to generate a report that includes only issues that belong to specific categories (such as security issues), or that have a minimum severity level. Example: Obtaining security issues with level Error and Warning # This example exports the pattern ID, issue level, file path, and timestamp for all security issues that have the severity level Warning or Error in the GitHub repository codacy/website . The example script: Defines the account API token used to authenticate on the Codacy API. Calls the endpoint searchRepositoryIssues to retrieve information about the issues, filtering the results by security issues with the relevant severity levels. Uses jq to select only the necessary data fields and convert the results to the CSV format. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = \"\" curl -X POST \"https://app.codacy.com/api/v3/analysis/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /issues/search\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: application/json\" \\ -d '{ \"levels\": [\"Error\", \"Warning\"], \"categories\": [\"Security\"] }' \\ | jq -r \".data[] | [.patternInfo.id, .patternInfo.level, .filePath, .commitInfo.timestamp] | @csv\" Example output: \"BundlerAudit_Insecure Dependency\",\"Error\",\"Gemfile.lock\",\"2021-06-16T11:46:24Z\" \"Custom_Scala_PredictableRandom\",\"Warning\",\"src/test/database/SpecsHelper.scala\",\"2021-05-21T16:20:15Z\" \"Custom_Scala_PlayUntrustedHttpRequestParameter\",\"Warning\",\"app/RedirectController.scala\",\"2021-04-26T15:06:33Z\" [...] Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API. See also # Which metrics does Codacy calculate? Issues page", "title": "Obtaining current issues in repositories"}, {"location": "codacy-api/examples/obtaining-current-issues-in-repositories/#obtaining-current-issues-in-repositories", "text": "To obtain information about the current issues in your repositories in a flexible way, use the Codacy API endpoint searchRepositoryIssues . For example, you may want to generate a report that includes only issues that belong to specific categories (such as security issues), or that have a minimum severity level.", "title": "Obtaining current issues in repositories"}, {"location": "codacy-api/examples/obtaining-current-issues-in-repositories/#example-obtaining-security-issues-with-level-error-and-warning", "text": "This example exports the pattern ID, issue level, file path, and timestamp for all security issues that have the severity level Warning or Error in the GitHub repository codacy/website . The example script: Defines the account API token used to authenticate on the Codacy API. Calls the endpoint searchRepositoryIssues to retrieve information about the issues, filtering the results by security issues with the relevant severity levels. Uses jq to select only the necessary data fields and convert the results to the CSV format. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # gh, ghe, gl, gle, bb, or bbe ORGANIZATION = \"\" REPOSITORY = \"\" curl -X POST \"https://app.codacy.com/api/v3/analysis/organizations/ $GIT_PROVIDER / $ORGANIZATION /repositories/ $REPOSITORY /issues/search\" \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: application/json\" \\ -d '{ \"levels\": [\"Error\", \"Warning\"], \"categories\": [\"Security\"] }' \\ | jq -r \".data[] | [.patternInfo.id, .patternInfo.level, .filePath, .commitInfo.timestamp] | @csv\" Example output: \"BundlerAudit_Insecure Dependency\",\"Error\",\"Gemfile.lock\",\"2021-06-16T11:46:24Z\" \"Custom_Scala_PredictableRandom\",\"Warning\",\"src/test/database/SpecsHelper.scala\",\"2021-05-21T16:20:15Z\" \"Custom_Scala_PlayUntrustedHttpRequestParameter\",\"Warning\",\"app/RedirectController.scala\",\"2021-04-26T15:06:33Z\" [...] Important For the sake of simplicity, the example doesn't consider paginated results obtained from the Codacy API. Learn how to use pagination to ensure that you process all results returned by the API.", "title": "Example: Obtaining security issues with level Error and Warning"}, {"location": "codacy-api/examples/obtaining-current-issues-in-repositories/#see-also", "text": "Which metrics does Codacy calculate? Issues page", "title": "See also"}, {"location": "codacy-api/examples/uploading-dast-results/", "text": "Uploading DAST results to Codacy # To ensure the security of your web applications, Codacy allows you to upload DAST (dynamic application security testing) results from Zed Attack Proxy (ZAP) directly to Codacy and monitor them as findings under Security and risk management . Uploading results to Codacy # Use ZAP to perform DAST on your application and generate a report in the Traditional JSON format . For details on generating reports in ZAP, refer to the ZAP documentation . Upload the report to Codacy using the API endpoint uploadDASTReport : Note The DAST report must be under 20MB in size. curl -X POST https://app.codacy.com/api/v3/organizations///security/tools/dast//reports \\ -H 'api-token: ' \\ -H 'Content-Type: multipart/form-data' \\ -H 'Accept: application/json' \\ -F 'file=@' \\ -F 'reportFormat=json' Replace the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the organization, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server ORGANIZATION: Name of the organization on the Git provider. For example, codacy . You must have admin permissions over the organization on the Git provider. TOOL_NAME: Name of the tool used to generate the report. Currently, only ZAP is supported. REPORT_PATH: Path to the file containing the DAST report. Replace placeholders with your specific details to complete the upload. This process seamlessly integrates the security insights of third-party DAST tools with Codacy for a comprehensive security overview. Retrieving uploaded results on Codacy # To retrieve a list of uploaded DAST reports, access the Codacy API endpoint listDASTReports : GET /organizations/{provider}/{remoteOrganizationName}/security/dast/reports curl -X GET https://api.codacy.com/api/v3/organizations///security/dast/reports \\ -H 'api-token: ' \\ -H 'Accept: application/json' Replace the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the organization, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server TOOL_NAME: Name of the tool used to generate the report. Currently, only ZAP is supported. This endpoint provides a list of all DAST reports uploaded to Codacy, allowing you to check the status and details of each report. Example: Uploading ZAP DAST results # Use this example Bash script to upload the ZAP DAST report to Codacy. This example can be adapted to fit your specific needs. The example script: Defines the API token used to authenticate on the Codacy API. Defines the path and filename of the file containing the DAST report. Calls the endpoint uploadDASTReport to upload the report to Codacy. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # e.g., gh for GitHub ORGANIZATION_NAME = \"\" TOOL_NAME = \"\" # e.g., ZAP REPORT_FILE_PATH = \"zap-report.json\" curl -X POST https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION_NAME /security/tools/dast/ $TOOL_NAME /reports \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: multipart/form-data\" \\ -H \"Accept: application/json\" \\ -F \"file=@ $REPORT_FILE_PATH \" \\ -F \"reportFormat=json\"", "title": "Uploading DAST results to Codacy"}, {"location": "codacy-api/examples/uploading-dast-results/#uploading-dast-results-to-codacy", "text": "To ensure the security of your web applications, Codacy allows you to upload DAST (dynamic application security testing) results from Zed Attack Proxy (ZAP) directly to Codacy and monitor them as findings under Security and risk management .", "title": "Uploading DAST results to Codacy"}, {"location": "codacy-api/examples/uploading-dast-results/#uploading-results-to-codacy", "text": "Use ZAP to perform DAST on your application and generate a report in the Traditional JSON format . For details on generating reports in ZAP, refer to the ZAP documentation . Upload the report to Codacy using the API endpoint uploadDASTReport : Note The DAST report must be under 20MB in size. curl -X POST https://app.codacy.com/api/v3/organizations///security/tools/dast//reports \\ -H 'api-token: ' \\ -H 'Content-Type: multipart/form-data' \\ -H 'Accept: application/json' \\ -F 'file=@' \\ -F 'reportFormat=json' Replace the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the organization, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server ORGANIZATION: Name of the organization on the Git provider. For example, codacy . You must have admin permissions over the organization on the Git provider. TOOL_NAME: Name of the tool used to generate the report. Currently, only ZAP is supported. REPORT_PATH: Path to the file containing the DAST report. Replace placeholders with your specific details to complete the upload. This process seamlessly integrates the security insights of third-party DAST tools with Codacy for a comprehensive security overview.", "title": "Uploading results to Codacy"}, {"location": "codacy-api/examples/uploading-dast-results/#retrieving-uploaded-results-on-codacy", "text": "To retrieve a list of uploaded DAST reports, access the Codacy API endpoint listDASTReports : GET /organizations/{provider}/{remoteOrganizationName}/security/dast/reports curl -X GET https://api.codacy.com/api/v3/organizations///security/dast/reports \\ -H 'api-token: ' \\ -H 'Accept: application/json' Replace the placeholders with your own values: API_KEY: Account API token used to authenticate on the Codacy API. GIT_PROVIDER: Git provider hosting of the organization, using one of the values in the table below. For example, gh for GitHub Cloud. Value Git provider gh GitHub Cloud ghe GitHub Enterprise gl GitLab Cloud gle GitLab Enterprise bb Bitbucket Cloud bbe Bitbucket Server TOOL_NAME: Name of the tool used to generate the report. Currently, only ZAP is supported. This endpoint provides a list of all DAST reports uploaded to Codacy, allowing you to check the status and details of each report.", "title": "Retrieving uploaded results on Codacy"}, {"location": "codacy-api/examples/uploading-dast-results/#example-uploading-zap-dast-results", "text": "Use this example Bash script to upload the ZAP DAST report to Codacy. This example can be adapted to fit your specific needs. The example script: Defines the API token used to authenticate on the Codacy API. Defines the path and filename of the file containing the DAST report. Calls the endpoint uploadDASTReport to upload the report to Codacy. CODACY_API_TOKEN = \"\" GIT_PROVIDER = \"\" # e.g., gh for GitHub ORGANIZATION_NAME = \"\" TOOL_NAME = \"\" # e.g., ZAP REPORT_FILE_PATH = \"zap-report.json\" curl -X POST https://app.codacy.com/api/v3/organizations/ $GIT_PROVIDER / $ORGANIZATION_NAME /security/tools/dast/ $TOOL_NAME /reports \\ -H \"api-token: $CODACY_API_TOKEN \" \\ -H \"Content-Type: multipart/form-data\" \\ -H \"Accept: application/json\" \\ -F \"file=@ $REPORT_FILE_PATH \" \\ -F \"reportFormat=json\"", "title": "Example: Uploading ZAP DAST results"}, {"location": "coverage-reporter/", "text": "Adding coverage to your repository # Code coverage is a metric used to describe the degree to which the source code of a program is tested. A program with high code coverage has been more thoroughly tested and has a lower chance of containing software bugs than a program with low code coverage. You can read more about the basics of code coverage on Codacy's blog. To monitor the code coverage of your repository on Codacy you must generate coverage reports for each commit on your CI/CD workflow, and then upload the coverage data to Codacy. Complete these main steps to set up coverage for your repository: Generating coverage reports Ensure that you're generating one of the code coverage report formats supported by Codacy on each push to your repository. Uploading coverage data to Codacy After each push to your repository, run the Codacy Coverage Reporter to parse your report file and upload the coverage data to Codacy. Validating that the coverage setup is complete Check if Codacy displays the coverage metrics for new commits and pull requests and troubleshoot the coverage setup if necessary. The next sections include detailed instructions on how to complete each step of the setup process. 1. Generating coverage reports # Before setting up Codacy to display code coverage metrics for your repository you must have tests and use tools to generate coverage reports for the source code files in your repository. Consider the following when generating coverage reports for your repository: There are many tools that you can use to generate coverage reports, but you must ensure that the coverage reports are in one of the formats that Codacy supports If your repository includes multiple programming languages, you may need to generate a separate coverage report for each language depending on the specific languages and tools that you use Make sure that you generate coverage reports that include coverage data for all tested source code files in your repository and not just the files that were changed in each commit The following table contains example coverage tools that generate reports in formats that Codacy supports: Language Example coverage tools Report files C# OpenCover opencover.xml (OpenCover) dotCover CLI dotcover.xml (dotCover detailedXML ) Coverlet Make sure that you output the report files in a supported format using one of the following file names: opencover.xml (OpenCover) cobertura.xml (Cobertura) lcov.info , lcov.dat , *.lcov (LCOV) Go Golang Code Coverage Golang report files don't have a specific name. Because of this, later in the setup process you must follow specific instructions while submitting coverage to Codacy. Java JaCoCo jacoco*.xml (JaCoCo) Cobertura cobertura.xml (Cobertura) JavaScript Istanbul Mocha + Blanket.js lcov.info , lcov.dat , *.lcov (LCOV) PHP PHPUnit coverage-xml/index.xml (PHPUnit XML version <= 4) clover.xml (Clover) Python Coverage.py cobertura.xml (Cobertura) Ruby SimpleCov cobertura.xml (Cobertura) lcov.info , lcov.dat , *.lcov (LCOV) Scala sbt-jacoco jacoco*.xml (JaCoCo) scoverage cobertura.xml (Cobertura) Swift/Objective-C Xcode Code Coverage See below how to generate coverage reports with Xcode Handling unsupported languages # If you're generating a report format that Codacy doesn't support yet, contribute with a parser implementation yourself or use one of the community projects below to generate coverage reports in a supported format: SlatherOrg/slather : generate Cobertura reports from Xcode coverage reports: gem install slather slather coverage -x --output-directory --scheme .xcodeproj This will generate a file cobertura.xml inside the folder . dariodf/lcov_ex : generate LCOV reports for Elixir projects chrisgit/sfdx-plugins_apex_coverage_report : generate LCOV or Cobertura reports from Apex code coverage data danielpalme/ReportGenerator : convert between different report formats Important Make sure that you specify the language when uploading coverage for an unsupported language. As a last resort, you can also send the coverage data directly by calling one of the following Codacy API endpoints: saveCoverage saveCoverageWithAccountToken 2. Uploading coverage data to Codacy # After having coverage reports set up for your repository, you must use the Codacy Coverage Reporter to upload them to Codacy. The recommended way to do this is by using a CI/CD platform that automatically runs tests, generates coverage, and then uses the Codacy Coverage Reporter to upload the coverage report information to Codacy. Important Please note that Codacy needs to receive coverage data for: Every push to your repository including merge commits or any commits created automatically by tools such as Dependabot All tested files in your repository including the files that weren't changed in the commit, or files from unchanged modules in a monorepo setup Alternative ways of running the Codacy Coverage Reporter Codacy makes available alternative ways to run the Codacy Coverage Reporter , such as by installing the binary manually or by using Docker, a GitHub Action, or a CircleCI Orb. However, the instructions on this page assume that you'll run the recommended self-contained bash script get.sh to automatically download and run the most recent version of the Codacy Coverage Reporter. Set up an API token to allow Codacy Coverage Reporter to authenticate on Codacy: If you're setting up coverage for one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up and automating coverage for multiple repositories , obtain an account API Token and set the following environment variables: CODACY_API_TOKEN: Your account API token. CODACY_ORGANIZATION_PROVIDER: Git provider hosting the repository. Must be one of gh , ghe , gl , gle , bb , or bbe to specify GitHub, GitHub Enterprise, GitLab, GitLab Enterprise, Bitbucket, or Bitbucket Enterprise, respectively. CODACY_USERNAME: Name of your organization on the Git provider, or your username on the Git provider if you're using a personal organization. CODACY_PROJECT_NAME: Name of the repository for which you're uploading the coverage data. export CODACY_API_TOKEN = export CODACY_ORGANIZATION_PROVIDER = export CODACY_USERNAME = export CODACY_PROJECT_NAME = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variables to specify your Codacy instance URL and the Codacy Coverage Reporter version that's compatible with Codacy Self-hosted 14.0.0: export CODACY_API_BASE_URL = export CODACY_REPORTER_VERSION = 13 .10.15 Run Codacy Coverage Reporter on the root of the locally checked out branch of your Git repository , specifying the relative path to the coverage report to upload: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report -r Check the console output to validate that the Codacy Coverage Reporter detected the correct commit SHA-1 hash and successfully uploaded the coverage data to Codacy. If you need help, check the troubleshooting page for solutions to the most common issues while running the CLI. Note Be sure to also check the instructions for more advanced scenarios while uploading the coverage data to Codacy, such as when running parallel tests, using monorepos, or testing source code in multiple or unsupported languages. 3. Validating that the coverage setup is complete # Codacy displays the code coverage in each branch, as well as the evolution of code coverage between commits and the code coverage variation introduced by pull requests. Because of this, to ensure that all code coverage metrics are available on Codacy, you must have successfully uploaded coverage data and analyzed: The last two commits in each branch The common ancestor commit of each pull request branch and its target branch Example The example below shows that after pushing a commit that correctly sets up coverage on the default branch: Codacy will report coverage metrics for all subsequent commits and pull requests relative to the default branch. Codacy won't report coverage metrics for commits and pull requests that are relative to older branches where the coverage setup wasn't performed yet. To solve this issue, you can rebase the old feature branch to update the common ancestor commit to one that already has coverage data. Follow these instructions to validate that your coverage setup is working correctly: On Codacy, open your Repository Settings , tab Coverage , and observe the list of the most recent 50 coverage reports in the section Test your integration . Make sure that Codacy receives and processes the coverage data successfully for at least two commits . If there are commits with a status different from Processed , please follow the troubleshooting instructions for the corresponding error status and click the button Test integration to display any new coverage reports uploaded to Codacy. Commit not found # Codacy doesn't have information about the commit associated with the coverage data. What causes the error? How to fix the error? Codacy didn't receive the webhook for that commit from the Git provider. Wait a few more minutes until Codacy detects the commit and the status will update automatically. If it takes more than 5 to 10 minutes for Codacy to detect the commit, the webhook call from the Git provider may have been lost. You can wait until you push a new commit or contact support@codacy.com asking us to sync the commits on Codacy with your Git provider. The commit SHA-1 hash sent while uploading coverage is wrong. Make sure that the Codacy Coverage Reporter detects the correct commit SHA-1 hash for the uploaded coverage data. Branch not enabled # The commit associated with the coverage data doesn't belong to any branch that Codacy is analyzing. What causes the error? How to fix the error? Coverage was uploaded for a commit that belongs to a branch that isn't analyzed by Codacy. Make sure that the branch is enabled on Codacy . Alternatively, ensure that the target branch is enabled and open a pull request for Codacy to start analyzing the branch automatically. If Codacy is already analyzing the branch, make sure that the Codacy Coverage Reporter detects the correct commit SHA-1 hash for the uploaded coverage data. Coverage was uploaded for a commit that no longer belongs to any branch on the Git repository, for example after a rebase or squash merge. The error status is expected in this scenario and you can ignore it. Commit not analyzed # Due to technical limitations, Codacy only reports coverage for a commit after successfully completing the static code analysis of that commit. What causes the error? How to fix the error? Codacy hasn't finished analyzing the commit yet. Wait a few more minutes until Codacy completes the static code analysis for the commit and the status will update automatically. Codacy didn't analyze the commit on a private repository because the committer doesn't belong to the Codacy organization. Make sure that you add all committers to your Codacy organization . Codacy skipped analyzing the commit because there are more recent commits in the branch. Upload coverage data for the most recent commit in the branch. The setting Run analysis on your build server is on, but your client-side tools didn't upload results to Codacy. Make sure that your client-side tools run successfully and upload the results to Codacy to complete the analysis. Codacy ran into an error while analyzing the commit. Solve the issue that caused the analysis to fail (such as Codacy losing access to the repository ), or contact us at support@codacy.com asking for help. Final report not sent # Codacy is waiting to receive more coverage data before reporting the coverage for a commit. What causes the error? How to fix the error? Coverage was uploaded with the --partial flag but Codacy didn't receive the final notification. Make sure that after uploading all partial reports you send the final notification . Pending # Codacy is waiting to receive valid coverage data for the files in your repository. What causes the error? How to fix the error? The file paths in the coverage report don't match the ones on the repository Files page on Codacy. Make sure that the file paths included in your coverage report are relative to the root directory of your repository. For example, src/index.js . The uploaded coverage data only includes information for files that are ignored on Codacy . Check which files are ignored on Codacy and make sure that you're generating coverage reports for the correct files in your repository. The uploaded coverage data is incorrectly associated, using the -l option, to a language that's not present in your repository. Verify that you are associating the correct language, or don't specify a language to let Codacy detect the contents of the coverage reports automatically. See how to upload coverage in advanced scenarios for more information. Check that Codacy displays the coverage metrics for the latest commits and pull requests. If Codacy can't calculate the coverage metrics for pull requests, make sure that you're uploading coverage data for the following commits of the pull request: Commit Required to calculate the coverage metrics Head commit of the pull request branch Coverage variation Diff coverage Common ancestor commit of the pull request and target branches Coverage variation The following diagram highlights the commits that must receive coverage data for Codacy to calculate the coverage metrics for pull requests: Click View logs on a pull request detail page to see the SHA-1 hashes of the commits that are missing coverage data. If you have many open pull requests, you can also use a script to identify if any pull requests are missing coverage data . Need help? If you need help setting up coverage on your repository please contact us at support@codacy.com including the following information: URL of your repository on Codacy Your CI/CD configuration files and the name of your CI/CD platform Full console output of your CI/CD when running the Codacy Coverage Reporter Branch name and commit SHA-1 hash corresponding to the CI/CD output Test coverage report that you're uploading to Codacy Any other relevant information or screenshots of your setup See also # Identifying commits without coverage data Why does Codacy show unexpected coverage changes?", "title": "Adding coverage to your repository"}, {"location": "coverage-reporter/#adding-coverage-to-your-repository", "text": "Code coverage is a metric used to describe the degree to which the source code of a program is tested. A program with high code coverage has been more thoroughly tested and has a lower chance of containing software bugs than a program with low code coverage. You can read more about the basics of code coverage on Codacy's blog. To monitor the code coverage of your repository on Codacy you must generate coverage reports for each commit on your CI/CD workflow, and then upload the coverage data to Codacy. Complete these main steps to set up coverage for your repository: Generating coverage reports Ensure that you're generating one of the code coverage report formats supported by Codacy on each push to your repository. Uploading coverage data to Codacy After each push to your repository, run the Codacy Coverage Reporter to parse your report file and upload the coverage data to Codacy. Validating that the coverage setup is complete Check if Codacy displays the coverage metrics for new commits and pull requests and troubleshoot the coverage setup if necessary. The next sections include detailed instructions on how to complete each step of the setup process.", "title": "Adding coverage to your repository"}, {"location": "coverage-reporter/#generating-coverage", "text": "Before setting up Codacy to display code coverage metrics for your repository you must have tests and use tools to generate coverage reports for the source code files in your repository. Consider the following when generating coverage reports for your repository: There are many tools that you can use to generate coverage reports, but you must ensure that the coverage reports are in one of the formats that Codacy supports If your repository includes multiple programming languages, you may need to generate a separate coverage report for each language depending on the specific languages and tools that you use Make sure that you generate coverage reports that include coverage data for all tested source code files in your repository and not just the files that were changed in each commit The following table contains example coverage tools that generate reports in formats that Codacy supports: Language Example coverage tools Report files C# OpenCover opencover.xml (OpenCover) dotCover CLI dotcover.xml (dotCover detailedXML ) Coverlet Make sure that you output the report files in a supported format using one of the following file names: opencover.xml (OpenCover) cobertura.xml (Cobertura) lcov.info , lcov.dat , *.lcov (LCOV) Go Golang Code Coverage Golang report files don't have a specific name. Because of this, later in the setup process you must follow specific instructions while submitting coverage to Codacy. Java JaCoCo jacoco*.xml (JaCoCo) Cobertura cobertura.xml (Cobertura) JavaScript Istanbul Mocha + Blanket.js lcov.info , lcov.dat , *.lcov (LCOV) PHP PHPUnit coverage-xml/index.xml (PHPUnit XML version <= 4) clover.xml (Clover) Python Coverage.py cobertura.xml (Cobertura) Ruby SimpleCov cobertura.xml (Cobertura) lcov.info , lcov.dat , *.lcov (LCOV) Scala sbt-jacoco jacoco*.xml (JaCoCo) scoverage cobertura.xml (Cobertura) Swift/Objective-C Xcode Code Coverage See below how to generate coverage reports with Xcode", "title": "1. Generating coverage reports"}, {"location": "coverage-reporter/#uploading-coverage", "text": "After having coverage reports set up for your repository, you must use the Codacy Coverage Reporter to upload them to Codacy. The recommended way to do this is by using a CI/CD platform that automatically runs tests, generates coverage, and then uses the Codacy Coverage Reporter to upload the coverage report information to Codacy. Important Please note that Codacy needs to receive coverage data for: Every push to your repository including merge commits or any commits created automatically by tools such as Dependabot All tested files in your repository including the files that weren't changed in the commit, or files from unchanged modules in a monorepo setup Alternative ways of running the Codacy Coverage Reporter Codacy makes available alternative ways to run the Codacy Coverage Reporter , such as by installing the binary manually or by using Docker, a GitHub Action, or a CircleCI Orb. However, the instructions on this page assume that you'll run the recommended self-contained bash script get.sh to automatically download and run the most recent version of the Codacy Coverage Reporter. Set up an API token to allow Codacy Coverage Reporter to authenticate on Codacy: If you're setting up coverage for one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up and automating coverage for multiple repositories , obtain an account API Token and set the following environment variables: CODACY_API_TOKEN: Your account API token. CODACY_ORGANIZATION_PROVIDER: Git provider hosting the repository. Must be one of gh , ghe , gl , gle , bb , or bbe to specify GitHub, GitHub Enterprise, GitLab, GitLab Enterprise, Bitbucket, or Bitbucket Enterprise, respectively. CODACY_USERNAME: Name of your organization on the Git provider, or your username on the Git provider if you're using a personal organization. CODACY_PROJECT_NAME: Name of the repository for which you're uploading the coverage data. export CODACY_API_TOKEN = export CODACY_ORGANIZATION_PROVIDER = export CODACY_USERNAME = export CODACY_PROJECT_NAME = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variables to specify your Codacy instance URL and the Codacy Coverage Reporter version that's compatible with Codacy Self-hosted 14.0.0: export CODACY_API_BASE_URL = export CODACY_REPORTER_VERSION = 13 .10.15 Run Codacy Coverage Reporter on the root of the locally checked out branch of your Git repository , specifying the relative path to the coverage report to upload: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report -r Check the console output to validate that the Codacy Coverage Reporter detected the correct commit SHA-1 hash and successfully uploaded the coverage data to Codacy. If you need help, check the troubleshooting page for solutions to the most common issues while running the CLI. Note Be sure to also check the instructions for more advanced scenarios while uploading the coverage data to Codacy, such as when running parallel tests, using monorepos, or testing source code in multiple or unsupported languages.", "title": "2. Uploading coverage data to Codacy"}, {"location": "coverage-reporter/#validating-coverage", "text": "Codacy displays the code coverage in each branch, as well as the evolution of code coverage between commits and the code coverage variation introduced by pull requests. Because of this, to ensure that all code coverage metrics are available on Codacy, you must have successfully uploaded coverage data and analyzed: The last two commits in each branch The common ancestor commit of each pull request branch and its target branch Example The example below shows that after pushing a commit that correctly sets up coverage on the default branch: Codacy will report coverage metrics for all subsequent commits and pull requests relative to the default branch. Codacy won't report coverage metrics for commits and pull requests that are relative to older branches where the coverage setup wasn't performed yet. To solve this issue, you can rebase the old feature branch to update the common ancestor commit to one that already has coverage data. Follow these instructions to validate that your coverage setup is working correctly: On Codacy, open your Repository Settings , tab Coverage , and observe the list of the most recent 50 coverage reports in the section Test your integration . Make sure that Codacy receives and processes the coverage data successfully for at least two commits . If there are commits with a status different from Processed , please follow the troubleshooting instructions for the corresponding error status and click the button Test integration to display any new coverage reports uploaded to Codacy.", "title": "3. Validating that the coverage setup is complete"}, {"location": "coverage-reporter/#see-also", "text": "Identifying commits without coverage data Why does Codacy show unexpected coverage changes?", "title": "See also"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/", "text": "Alternative ways of running Coverage Reporter # The following sections list the alternative ways of running or installing Codacy Coverage Reporter. Important If you're using Codacy Self-hosted 14.0.0 you must use Codacy Coverage Reporter 13.10.15 to ensure it's compatible with your Codacy instance. Bash script (recommended) # The recommended way to run the Codacy Coverage Reporter is by using the self-contained bash script get.sh that automatically downloads and runs the most recent version of the Codacy Coverage Reporter: On Ubuntu, run: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report -r On Alpine Linux, run: wget -qO - https://coverage.codacy.com/get.sh | sh -s -- report -r Note Starting on version 13.0.0 the script automatically validates the checksum of the downloaded binary. To skip the checksum validation, define the following environment variable: export CODACY_REPORTER_SKIP_CHECKSUM = true The self-contained script can cache the binary. To avoid downloading the binary every time that the script runs, add one of the following directories to your CI cached folders: $HOME/.cache/codacy on Linux $HOME/Library/Caches/Codacy on Mac OS X To use a specific version of the Codacy Coverage Reporter, set the following environment variable to one of the released versions : export CODACY_REPORTER_VERSION = Docker # You can use Docker to run Codacy Coverage Reporter. Use the following command where is either one of the released versions , or latest to use the most recent version: docker run -v $PWD :/code codacy/codacy-coverage-reporter: report GitHub Action # If you're using GitHub Actions to report coverage, you can use our GitHub Action codacy/codacy-coverage-reporter-action . CircleCI orb # If you're using CircleCI to report coverage, you can use our orb codacy/coverage-reporter . Manually downloading the binary # Linux amd64 # If you prefer, you can manually download and run the native codacy-coverage-reporter binary, either for the latest version or a specific one. You can use the scripts below to automatically check for the latest version of the binaries, download the binaries from either Codacy's public store or GitHub, and run them. Using Codacy's public S3: LATEST_VERSION = \" $( curl -Ls https://artifacts.codacy.com/bin/codacy-coverage-reporter/latest ) \" curl -Ls -o codacy-coverage-reporter \"https://artifacts.codacy.com/bin/codacy-coverage-reporter/ ${ LATEST_VERSION } /codacy-coverage-reporter-linux\" chmod +x codacy-coverage-reporter ./codacy-coverage-reporter report Using GitHub: curl -Ls -o codacy-coverage-reporter \" $( curl -Ls https://api.github.com/repos/codacy/codacy-coverage-reporter/releases/latest | jq -r '.assets | map({name, browser_download_url} | select(.name | contains(\"codacy-coverage-reporter-linux\"))) | .[0].browser_download_url' ) \" chmod +x codacy-coverage-reporter ./codacy-coverage-reporter report Java # Use the Java binary to run Codacy Coverage reporter on other platforms, such as Linux x86, macOS, Windows, etc. You can use the scripts below to automatically check for the latest version of the Java binaries, download the binaries from either Codacy's public store or GitHub, and run them. Using Codacy's public store: LATEST_VERSION = \" $( curl -Ls https://artifacts.codacy.com/bin/codacy-coverage-reporter/latest ) \" curl -Ls -o codacy-coverage-reporter-assembly.jar \"https://artifacts.codacy.com/bin/codacy-coverage-reporter/ ${ LATEST_VERSION } /codacy-coverage-reporter-assembly.jar\" java -jar codacy-coverage-reporter-assembly.jar report Using GitHub: curl -LS -o codacy-coverage-reporter-assembly.jar \" $( curl -LSs https://api.github.com/repos/codacy/codacy-coverage-reporter/releases/latest | jq -r '.assets | map({name, browser_download_url} | select(.name | endswith(\".jar\"))) | .[0].browser_download_url' ) \" java -jar codacy-coverage-reporter-assembly.jar report Validating the checksum of the binaries # You can use the checksums available for each release to validate the binaries that you download manually. You can use any tool of your choice to validate the checksum, as long as it uses the SHA512 algorithm. For example, run the commands below to download and validate the checksum for the 13.0.0 Linux binary. Note that the command sha512sum expects to find the binary on the same directory and with the original name codacy-coverage-reporter-linux . curl -Ls -O https://github.com/codacy/codacy-coverage-reporter/releases/download/13.0.0/codacy-coverage-reporter-linux.SHA512SUM sha512sum -c codacy-coverage-reporter-linux.SHA512SUM Building from source # If you are having any issues with your installation, you can also build the coverage reporter from source. Clone the Codacy Coverage Reporter repository: git clone https://github.com/codacy/codacy-coverage-reporter.git Run the command sbt assembly inside the local repository folder: cd codacy-coverage-reporter sbt assembly This will produce a file target/codacy-coverage-reporter-assembly-.jar that you can run. Execute this .jar in the repository where you want to upload the coverage. For example: /java-project$ java -jar ../codacy-coverage-reporter/target/codacy-coverage-reporter-assembly-.jar report Community supported alternatives # Maven plugin # Thanks to the amazing job of Gavin Mogan you can now send your coverage to Codacy using his Maven plugin halkeye/codacy-maven-plugin ! Be sure to follow the instructions on his repository. Travis CI # If you are using Travis CI to report coverage, update your file .travis.yml to include the following blocks: before_script : - bash <(curl -Ls https://coverage.codacy.com/get.sh) download after_success : - bash <(curl -Ls https://coverage.codacy.com/get.sh) Make sure that you also set your project or account API Token as an environment variable in your Travis CI job. Gradle task # If you're using Gradle to automate your CI/CD you can add use the following example task, where is the name of the task that generates your coverage report: task uploadCoverage ( type: Exec , dependsOn: < COVERAGE_REPORT_TASK >) { description 'Uploads coverage data to Codacy.' commandLine 'bash' , '-c' , 'bash <(curl -Ls https://coverage.codacy.com/get.sh) report' }", "title": "Alternative ways of running Coverage Reporter"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#alternative-ways-of-running-coverage-reporter", "text": "The following sections list the alternative ways of running or installing Codacy Coverage Reporter. Important If you're using Codacy Self-hosted 14.0.0 you must use Codacy Coverage Reporter 13.10.15 to ensure it's compatible with your Codacy instance.", "title": "Alternative ways of running Coverage Reporter"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#bash-script", "text": "The recommended way to run the Codacy Coverage Reporter is by using the self-contained bash script get.sh that automatically downloads and runs the most recent version of the Codacy Coverage Reporter: On Ubuntu, run: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report -r On Alpine Linux, run: wget -qO - https://coverage.codacy.com/get.sh | sh -s -- report -r Note Starting on version 13.0.0 the script automatically validates the checksum of the downloaded binary. To skip the checksum validation, define the following environment variable: export CODACY_REPORTER_SKIP_CHECKSUM = true The self-contained script can cache the binary. To avoid downloading the binary every time that the script runs, add one of the following directories to your CI cached folders: $HOME/.cache/codacy on Linux $HOME/Library/Caches/Codacy on Mac OS X To use a specific version of the Codacy Coverage Reporter, set the following environment variable to one of the released versions : export CODACY_REPORTER_VERSION = ", "title": "Bash script (recommended)"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#docker", "text": "You can use Docker to run Codacy Coverage Reporter. Use the following command where is either one of the released versions , or latest to use the most recent version: docker run -v $PWD :/code codacy/codacy-coverage-reporter: report", "title": "Docker"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#github-action", "text": "If you're using GitHub Actions to report coverage, you can use our GitHub Action codacy/codacy-coverage-reporter-action .", "title": "GitHub Action"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#circleci-orb", "text": "If you're using CircleCI to report coverage, you can use our orb codacy/coverage-reporter .", "title": "CircleCI orb"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#manually-downloading-the-binary", "text": "", "title": "Manually downloading the binary"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#building-from-source", "text": "If you are having any issues with your installation, you can also build the coverage reporter from source. Clone the Codacy Coverage Reporter repository: git clone https://github.com/codacy/codacy-coverage-reporter.git Run the command sbt assembly inside the local repository folder: cd codacy-coverage-reporter sbt assembly This will produce a file target/codacy-coverage-reporter-assembly-.jar that you can run. Execute this .jar in the repository where you want to upload the coverage. For example: /java-project$ java -jar ../codacy-coverage-reporter/target/codacy-coverage-reporter-assembly-.jar report", "title": "Building from source"}, {"location": "coverage-reporter/alternative-ways-of-running-coverage-reporter/#community-supported-alternatives", "text": "", "title": "Community supported alternatives"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/", "text": "Troubleshooting coverage CLI issues # The sections below provide instructions or workarounds to overcome common issues while using Codacy Coverage Reporter CLI: Can't guess any report due to no matching Can't validate checksum Commit SHA-1 hash detection Connect timed out while uploading coverage data coverage-xml/index.xml generated an empty result JsonParseException while uploading coverage data MalformedInputException while parsing report No coverage data was sent Report generated an empty result while uploading C# coverage data SubstrateSegfaultHandler caught signal 11 Can't guess any report due to no matching # Codacy Coverage Reporter automatically searches for coverage reports matching the file name conventions for supported formats . However, if Codacy Coverage Reporter doesn't find your coverage report, you can explicitly define the report file name with the flag -r . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report -r Can't validate checksum # Starting on version 13.0.0 the get.sh script automatically validates the checksum of the downloaded Codacy Coverage Reporter binary. This requires having either the sha512sum or shasum command on the operating system where you're running the script. If you're getting this error while uploading your coverage data to Codacy, install the correct version of sha512sum or shasum for the operating system that you're using. You can also skip validating the checksum of the binary by defining the following environment variable, however, Codacy doesn't recommend this: export CODACY_REPORTER_SKIP_CHECKSUM = true Commit SHA-1 hash detection # The Codacy Coverage Reporter automatically detects the SHA-1 hash of the current commit to associate with the coverage data when you're using one of the following CI/CD platforms: Appveyor Argo CD AWS CodeBuild Azure Pipelines Bitrise Buildkite Circle CI Codefresh Codeship Docker GitLab Greenhouse CI Heroku CI Jenkins Magnum CI Semaphore CI Shippable CI Solano CI TeamCity CI Travis CI Wercker CI If the Codacy Coverage Reporter fails to detect the current commit from the CI workflow context, it will use the current commit from the local Git repository instead. However, you can also force using a specific commit SHA-1 hash with the flag --commit-uuid . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -r report.xml \\ --commit-uuid cd4d000083a744cf1617d46af4ec108b79e06bed Connect timed out while uploading coverage data # If you get a Error doing a post to <...> connect timed out error while uploading your coverage data to Codacy it means that the Codacy Coverage Reporter is timing out while connecting to the Codacy API. This typically happens if you're uploading coverage data for larger repositories. To increase the default timeout while connecting to the Codacy API, use the flag --http-timeout to set a value larger than 10000 milliseconds. For example, to set the timeout to 30 seconds: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -r report.xml \\ --http-timeout 30000 coverage-xml/index.xml generated an empty result # If you're using PHPUnit version 5 or above to generate your coverage report, you must output the report using the Clover format. Codacy Coverage Reporter supports the PHPUnit XML format only for versions 4 and older. To change the output format replace the flag --coverage-xml with --coverage-clover when executing phpunit . See PHPUnit command-line documentation for more information. JsonParseException while uploading coverage data # If you get a com.fasterxml.jackson.core.JsonParseException error while uploading your coverage data to Codacy it means that your coverage report is too big and that Codacy Coverage Reporter hit a limit of 10 MB when uploading the coverage data to Codacy. There are some ways you can solve this: Split your coverage reports into smaller files and upload them to Codacy one at a time . If you're using dotCover to generate coverage reports for your C# projects , you should exclude xUnit files from the coverage analysis as follows: dotCover.exe cover <...> /Filters = -:xunit* By default, dotCover includes xUnit files in the coverage analysis and this results in larger coverage reports. This filter helps ensure that the resulting coverage data doesn't exceed the size limit accepted by the Codacy API when uploading the results. MalformedInputException while parsing report # If you get a java.nio.charset.MalformedInputException when running the Codacy Coverage Reporter it means that the coverage report includes a character that's not encoded in UTF-8. The invalid character can belong to the file name of one of your source code files, or even a class or method name. For maximum compatibility of your coverage reports with the Codacy Coverage Reporter, make sure that your coverage reports use UTF-8 encoding and that they only include UTF-8 characters. No coverage data was sent # You can get the No coverage data was sent error when running the Codacy Coverage Reporter for the following reasons: The coverage report doesn't include any coverage data. The coverage report only includes data for files that don't exist in the associated Git repository. In this case, you also get one or more warnings File: [filename] will be discarded and will not be considered for coverage calculation . Make sure that your coverage report isn't empty and that it includes coverage data for files in the associated Git repository. Note If you upload multiple coverage reports and at least one contains valid data, the Codacy Coverage Reporter uploads the valid reports and ignores the invalid ones. Report generated an empty result while uploading C# coverage data # If you're using dotCover to generate coverage reports for your C# projects, you must use the dotCover detailedXML report format as follows: dotCover.exe cover <...> --reportType = DetailedXml SubstrateSegfaultHandler caught signal 11 # If you're experiencing segmentation faults when uploading the coverage results due to oracle/graal#624 , execute the following command before running the reporter, as a workaround: echo \" $( dig +short api.codacy.com | tail -n1 ) api.codacy.com\" >> /etc/hosts", "title": "Troubleshooting coverage CLI issues"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#troubleshooting-coverage-cli-issues", "text": "The sections below provide instructions or workarounds to overcome common issues while using Codacy Coverage Reporter CLI: Can't guess any report due to no matching Can't validate checksum Commit SHA-1 hash detection Connect timed out while uploading coverage data coverage-xml/index.xml generated an empty result JsonParseException while uploading coverage data MalformedInputException while parsing report No coverage data was sent Report generated an empty result while uploading C# coverage data SubstrateSegfaultHandler caught signal 11", "title": "Troubleshooting coverage CLI issues"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#cant-guess-any-report-due-to-no-matching", "text": "Codacy Coverage Reporter automatically searches for coverage reports matching the file name conventions for supported formats . However, if Codacy Coverage Reporter doesn't find your coverage report, you can explicitly define the report file name with the flag -r . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report -r ", "title": "Can't guess any report due to no matching"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#checksum", "text": "Starting on version 13.0.0 the get.sh script automatically validates the checksum of the downloaded Codacy Coverage Reporter binary. This requires having either the sha512sum or shasum command on the operating system where you're running the script. If you're getting this error while uploading your coverage data to Codacy, install the correct version of sha512sum or shasum for the operating system that you're using. You can also skip validating the checksum of the binary by defining the following environment variable, however, Codacy doesn't recommend this: export CODACY_REPORTER_SKIP_CHECKSUM = true", "title": "Can't validate checksum"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#commit-detection", "text": "The Codacy Coverage Reporter automatically detects the SHA-1 hash of the current commit to associate with the coverage data when you're using one of the following CI/CD platforms: Appveyor Argo CD AWS CodeBuild Azure Pipelines Bitrise Buildkite Circle CI Codefresh Codeship Docker GitLab Greenhouse CI Heroku CI Jenkins Magnum CI Semaphore CI Shippable CI Solano CI TeamCity CI Travis CI Wercker CI If the Codacy Coverage Reporter fails to detect the current commit from the CI workflow context, it will use the current commit from the local Git repository instead. However, you can also force using a specific commit SHA-1 hash with the flag --commit-uuid . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -r report.xml \\ --commit-uuid cd4d000083a744cf1617d46af4ec108b79e06bed", "title": "Commit SHA-1 hash detection"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#connect-timed-out-while-uploading-coverage-data", "text": "If you get a Error doing a post to <...> connect timed out error while uploading your coverage data to Codacy it means that the Codacy Coverage Reporter is timing out while connecting to the Codacy API. This typically happens if you're uploading coverage data for larger repositories. To increase the default timeout while connecting to the Codacy API, use the flag --http-timeout to set a value larger than 10000 milliseconds. For example, to set the timeout to 30 seconds: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -r report.xml \\ --http-timeout 30000", "title": "Connect timed out while uploading coverage data"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#coverage-xmlindexxml-generated-an-empty-result", "text": "If you're using PHPUnit version 5 or above to generate your coverage report, you must output the report using the Clover format. Codacy Coverage Reporter supports the PHPUnit XML format only for versions 4 and older. To change the output format replace the flag --coverage-xml with --coverage-clover when executing phpunit . See PHPUnit command-line documentation for more information.", "title": "coverage-xml/index.xml generated an empty result"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#jsonparseexception-while-uploading-coverage-data", "text": "If you get a com.fasterxml.jackson.core.JsonParseException error while uploading your coverage data to Codacy it means that your coverage report is too big and that Codacy Coverage Reporter hit a limit of 10 MB when uploading the coverage data to Codacy. There are some ways you can solve this: Split your coverage reports into smaller files and upload them to Codacy one at a time . If you're using dotCover to generate coverage reports for your C# projects , you should exclude xUnit files from the coverage analysis as follows: dotCover.exe cover <...> /Filters = -:xunit* By default, dotCover includes xUnit files in the coverage analysis and this results in larger coverage reports. This filter helps ensure that the resulting coverage data doesn't exceed the size limit accepted by the Codacy API when uploading the results.", "title": "JsonParseException while uploading coverage data"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#malformedinputexception-while-parsing-report", "text": "If you get a java.nio.charset.MalformedInputException when running the Codacy Coverage Reporter it means that the coverage report includes a character that's not encoded in UTF-8. The invalid character can belong to the file name of one of your source code files, or even a class or method name. For maximum compatibility of your coverage reports with the Codacy Coverage Reporter, make sure that your coverage reports use UTF-8 encoding and that they only include UTF-8 characters.", "title": "MalformedInputException while parsing report"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#no-coverage-data-was-sent", "text": "You can get the No coverage data was sent error when running the Codacy Coverage Reporter for the following reasons: The coverage report doesn't include any coverage data. The coverage report only includes data for files that don't exist in the associated Git repository. In this case, you also get one or more warnings File: [filename] will be discarded and will not be considered for coverage calculation . Make sure that your coverage report isn't empty and that it includes coverage data for files in the associated Git repository. Note If you upload multiple coverage reports and at least one contains valid data, the Codacy Coverage Reporter uploads the valid reports and ignores the invalid ones.", "title": "No coverage data was sent"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#detailedxml", "text": "If you're using dotCover to generate coverage reports for your C# projects, you must use the dotCover detailedXML report format as follows: dotCover.exe cover <...> --reportType = DetailedXml", "title": "Report generated an empty result while uploading C# coverage data"}, {"location": "coverage-reporter/troubleshooting-coverage-cli-issues/#substratesegfaulthandler-caught-signal-11", "text": "If you're experiencing segmentation faults when uploading the coverage results due to oracle/graal#624 , execute the following command before running the reporter, as a workaround: echo \" $( dig +short api.codacy.com | tail -n1 ) api.codacy.com\" >> /etc/hosts", "title": "SubstrateSegfaultHandler caught signal 11"}, {"location": "coverage-reporter/uploading-coverage-in-advanced-scenarios/", "text": "Uploading coverage in advanced scenarios # The following sections include instructions on how to use the Codacy Coverage Reporter to upload coverage data in more advanced scenarios. Uploading multiple coverage reports for the same language # If your test suite is split into different modules or runs in parallel, you must upload multiple coverage reports for the same language either at once or in sequence. Alternatively, consider merging multiple coverage reports before uploading them to Codacy. Most coverage tools support merging or aggregating coverage data. For example, use the merge mojo for JaCoCo . Note If one or more coverage reports mark a line as covered multiple times, Codacy counts it as a single covered line when calculating coverage. Uploading all reports at once # Upload multiple partial coverage reports with a single command by specifying each report with the flag -r . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -l Java -r report1.xml -r report2.xml -r report3.xml You can also upload all your reports dynamically using the command find . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -l Java $( find . -name 'jacoco*.xml' | sed 's,^, -r ,' | xargs echo ) Uploading reports in sequence # Upload multiple partial coverage reports in sequence: Upload each report separately with the flag --partial . If you're sending reports for a language with the flag --partial , you must use the flag in all reports for that language to ensure the correct calculation of the coverage. Notify Codacy with the final command after uploading all reports. For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --partial -l Java -r report1.xml bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --partial -l Java -r report2.xml bash < ( curl -Ls https://coverage.codacy.com/get.sh ) final Uploading the same coverage report for multiple languages # If your test suite generates a single coverage report for more than one language, you must upload the same coverage report for each language. To do this, upload the same report multiple times, specifying each different language with the flag -l . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --partial -l Javascript -r report.xml bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --partial -l TypeScript -r report.xml bash < ( curl -Ls https://coverage.codacy.com/get.sh ) final Uploading coverage for Golang # Codacy can't automatically detect Golang coverage report files because they don't have specific file names. If you're uploading a Golang coverage report, you must also specify the report type: go test -coverprofile = unit.coverage.out ./... bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --force-coverage-parser go -r unit.coverage.out Uploading coverage for unsupported languages # If your language isn't in the list of supported languages , you can still send coverage to Codacy. To do this, provide the correct language with the flag -l , together with --force-language . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -l Kotlin --force-language -r See the list of languages that you can specify using the flag -l .", "title": "Uploading coverage in advanced scenarios"}, {"location": "coverage-reporter/uploading-coverage-in-advanced-scenarios/#uploading-coverage-in-advanced-scenarios", "text": "The following sections include instructions on how to use the Codacy Coverage Reporter to upload coverage data in more advanced scenarios.", "title": "Uploading coverage in advanced scenarios"}, {"location": "coverage-reporter/uploading-coverage-in-advanced-scenarios/#multiple-reports", "text": "If your test suite is split into different modules or runs in parallel, you must upload multiple coverage reports for the same language either at once or in sequence. Alternatively, consider merging multiple coverage reports before uploading them to Codacy. Most coverage tools support merging or aggregating coverage data. For example, use the merge mojo for JaCoCo . Note If one or more coverage reports mark a line as covered multiple times, Codacy counts it as a single covered line when calculating coverage.", "title": "Uploading multiple coverage reports for the same language"}, {"location": "coverage-reporter/uploading-coverage-in-advanced-scenarios/#multiple-languages", "text": "If your test suite generates a single coverage report for more than one language, you must upload the same coverage report for each language. To do this, upload the same report multiple times, specifying each different language with the flag -l . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --partial -l Javascript -r report.xml bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --partial -l TypeScript -r report.xml bash < ( curl -Ls https://coverage.codacy.com/get.sh ) final", "title": "Uploading the same coverage report for multiple languages"}, {"location": "coverage-reporter/uploading-coverage-in-advanced-scenarios/#golang", "text": "Codacy can't automatically detect Golang coverage report files because they don't have specific file names. If you're uploading a Golang coverage report, you must also specify the report type: go test -coverprofile = unit.coverage.out ./... bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ --force-coverage-parser go -r unit.coverage.out", "title": "Uploading coverage for Golang"}, {"location": "coverage-reporter/uploading-coverage-in-advanced-scenarios/#unsupported-languages", "text": "If your language isn't in the list of supported languages , you can still send coverage to Codacy. To do this, provide the correct language with the flag -l , together with --force-language . For example: bash < ( curl -Ls https://coverage.codacy.com/get.sh ) report \\ -l Kotlin --force-language -r See the list of languages that you can specify using the flag -l .", "title": "Uploading coverage for unsupported languages"}, {"location": "faq/code-analysis/can-i-bypass-codacy-status-check/", "text": "Can I bypass Codacy status check? # To protect your code from unwelcome changes, you can configure your Git workflow to block merging pull requests if they don't pass the Codacy status check. However, on very specific and exceptional situations where your pull request merging is blocked due to an unexpected issue not related to the quality of your code, Codacy allows repository admins to bypass the Codacy status check for that pull request. To bypass Codacy status check for a pull request, a repository admin must click Bypass status checks on the pull request status area of the pull request detail screen.", "title": "Can I bypass Codacy status check?"}, {"location": "faq/code-analysis/can-i-bypass-codacy-status-check/#can-i-bypass-codacy-status-check", "text": "To protect your code from unwelcome changes, you can configure your Git workflow to block merging pull requests if they don't pass the Codacy status check. However, on very specific and exceptional situations where your pull request merging is blocked due to an unexpected issue not related to the quality of your code, Codacy allows repository admins to bypass the Codacy status check for that pull request. To bypass Codacy status check for a pull request, a repository admin must click Bypass status checks on the pull request status area of the pull request detail screen.", "title": "Can I bypass Codacy status check?"}, {"location": "faq/code-analysis/does-codacy-check-for-dependencies/", "text": "Does Codacy check for dependencies? # Yes, Codacy scans the manifest files of your repositories and displays any vulnerable dependencies as Codacy issues. For a list of supported languages and manifest files scanned by the Codacy dependency vulnerability scanning tools, see Supported languages and tools .", "title": "Does Codacy check for dependencies?"}, {"location": "faq/code-analysis/does-codacy-check-for-dependencies/#does-codacy-check-for-dependencies", "text": "Yes, Codacy scans the manifest files of your repositories and displays any vulnerable dependencies as Codacy issues. For a list of supported languages and manifest files scanned by the Codacy dependency vulnerability scanning tools, see Supported languages and tools .", "title": "Does Codacy check for dependencies?"}, {"location": "faq/code-analysis/does-codacy-place-limits-on-the-code-analysis/", "text": "Does Codacy place limits on the code analysis? # Codacy uses limits when performing the analysis of your repositories to ensure good performance levels and avoid degradation of service during peak load. The following table describes these limits and includes links to more information and workarounds, if available: Limit Value Rationale File size 150 KB Large source code files are typically generated by or dependent on a third-party, and could significantly delay the analysis. See Why is my file over 150 KB missing? File size for coverage reports 10 MB Codacy doesn't parse code coverage reports that are over the file size limit. See JsonParseException while uploading coverage data Number of files for duplication 5000 Some tools fail to calculate duplication or time out when analyzing a number of files above this number. See Why aren't duplication metrics being calculated? Number of issues per file and per tool 50 Codacy limits the number of issues returned on each file by individual tools as a safeguard against degradation of performance on large or unexpected use cases. This means that in some situations Codacy could report more issues after a push that includes fixes for the currently reported issues. Number of comments on the Git provider 25 Codacy limits the number of comments for reporting found issues on pull requests to avoid triggering too many notification emails and to guard against hitting API rate limits. Showing issues on duplicated lines - For now, Codacy only reports the first code issue when there are issues on duplicated lines on the same file. If you believe that you may have hit any of these limits and need help to overcome them, please contact us at support@codacy.com . See also # Which metrics does Codacy calculate?", "title": "Does Codacy place limits on the code analysis?"}, {"location": "faq/code-analysis/does-codacy-place-limits-on-the-code-analysis/#does-codacy-place-limits-on-the-code-analysis", "text": "Codacy uses limits when performing the analysis of your repositories to ensure good performance levels and avoid degradation of service during peak load. The following table describes these limits and includes links to more information and workarounds, if available: Limit Value Rationale File size 150 KB Large source code files are typically generated by or dependent on a third-party, and could significantly delay the analysis. See Why is my file over 150 KB missing? File size for coverage reports 10 MB Codacy doesn't parse code coverage reports that are over the file size limit. See JsonParseException while uploading coverage data Number of files for duplication 5000 Some tools fail to calculate duplication or time out when analyzing a number of files above this number. See Why aren't duplication metrics being calculated? Number of issues per file and per tool 50 Codacy limits the number of issues returned on each file by individual tools as a safeguard against degradation of performance on large or unexpected use cases. This means that in some situations Codacy could report more issues after a push that includes fixes for the currently reported issues. Number of comments on the Git provider 25 Codacy limits the number of comments for reporting found issues on pull requests to avoid triggering too many notification emails and to guard against hitting API rate limits. Showing issues on duplicated lines - For now, Codacy only reports the first code issue when there are issues on duplicated lines on the same file. If you believe that you may have hit any of these limits and need help to overcome them, please contact us at support@codacy.com .", "title": "Does Codacy place limits on the code analysis?"}, {"location": "faq/code-analysis/does-codacy-place-limits-on-the-code-analysis/#see-also", "text": "Which metrics does Codacy calculate?", "title": "See also"}, {"location": "faq/code-analysis/how-long-does-it-take-for-my-repository-to-be-analyzed/", "text": "How long does it take for my repository to be analyzed? # Codacy usually takes under 5 minutes to analyze your repository. It may however take longer, depending on a number of factors: Whether it's the initial analysis of your repository The initial analysis examines all files in the repository, while each subsequent commit triggers an analysis only on files changed in that commit. Whether tool configurations have been updated Updates to tool configurations trigger a reanalysis of all files in the repository on the next commit and may impact analysis duration. The size of your repository To speed up the analysis, ignore any files and directories that aren't relevant to your project, such as generated code or any third-party libraries included in your repositories. The time it takes your Git provider to trigger the analysis Codacy relies on post-commit hooks sent by your Git provider to trigger the analysis after each push to the repository, so if your analysis is taking a lot of time to start check that the Post-Commit Hook integration for your repository is enabled . The priority of your analysis request and the current load on Codacy's servers Open-source projects have lower priority in the Codacy analysis queues. Whether Codacy or your Git provider is currently experiencing issues or outages Check the Codacy status page and the status page of your Git provider ( GitHub , GitLab , Bitbucket ) to see if there is any ongoing incident that could delay the analysis.", "title": "How long does it take for my repository to be analyzed?"}, {"location": "faq/code-analysis/how-long-does-it-take-for-my-repository-to-be-analyzed/#how-long-does-it-take-for-my-repository-to-be-analyzed", "text": "Codacy usually takes under 5 minutes to analyze your repository. It may however take longer, depending on a number of factors: Whether it's the initial analysis of your repository The initial analysis examines all files in the repository, while each subsequent commit triggers an analysis only on files changed in that commit. Whether tool configurations have been updated Updates to tool configurations trigger a reanalysis of all files in the repository on the next commit and may impact analysis duration. The size of your repository To speed up the analysis, ignore any files and directories that aren't relevant to your project, such as generated code or any third-party libraries included in your repositories. The time it takes your Git provider to trigger the analysis Codacy relies on post-commit hooks sent by your Git provider to trigger the analysis after each push to the repository, so if your analysis is taking a lot of time to start check that the Post-Commit Hook integration for your repository is enabled . The priority of your analysis request and the current load on Codacy's servers Open-source projects have lower priority in the Codacy analysis queues. Whether Codacy or your Git provider is currently experiencing issues or outages Check the Codacy status page and the status page of your Git provider ( GitHub , GitLab , Bitbucket ) to see if there is any ongoing incident that could delay the analysis.", "title": "How long does it take for my repository to be analyzed?"}, {"location": "faq/code-analysis/how-to-configure-php-codesniffer-coding-standards/", "text": "How to configure PHP_CodeSniffer coding standards? # By default, Codacy uses the PHP_CodeSniffer configuration on the Code patterns page when analyzing your repositories. To enforce a specific PHP_CodeSniffer coding standard you must create a configuration file on the root of your repository that references one or more of the following coding standards: Default coding standards packaged together with PHP_CodeSniffer: https://github.com/squizlabs/PHP_CodeSniffer/tree/master/src/Standards Additional coding standards that Codacy packages on the PHP_CodeSniffer tool plugin. Check the repository the additional coding standards to learn how you can reference them in your configuration files: https://github.com/codacy/codacy-codesniffer/blob/master/composer.json For example, create a text file with the name phpcs.xml to use the PSR12 coding standard but excluding the sniffs Generic.WhiteSpace.DisallowTabIndent and PSR12.Operators.OperatorSpacing : PHP_CodeSniffer configuration See also # Check these external resources for more help on customizing your PHP_CodeSniffer configuration: PHP_CodeSniffer configuration file syntax PHP Coding Standard Generator", "title": "How to configure PHP_CodeSniffer coding standards?"}, {"location": "faq/code-analysis/how-to-configure-php-codesniffer-coding-standards/#how-to-configure-php_codesniffer-coding-standards", "text": "By default, Codacy uses the PHP_CodeSniffer configuration on the Code patterns page when analyzing your repositories. To enforce a specific PHP_CodeSniffer coding standard you must create a configuration file on the root of your repository that references one or more of the following coding standards: Default coding standards packaged together with PHP_CodeSniffer: https://github.com/squizlabs/PHP_CodeSniffer/tree/master/src/Standards Additional coding standards that Codacy packages on the PHP_CodeSniffer tool plugin. Check the repository the additional coding standards to learn how you can reference them in your configuration files: https://github.com/codacy/codacy-codesniffer/blob/master/composer.json For example, create a text file with the name phpcs.xml to use the PSR12 coding standard but excluding the sniffs Generic.WhiteSpace.DisallowTabIndent and PSR12.Operators.OperatorSpacing : PHP_CodeSniffer configuration ", "title": "How to configure PHP_CodeSniffer coding standards?"}, {"location": "faq/code-analysis/how-to-configure-php-codesniffer-coding-standards/#see-also", "text": "Check these external resources for more help on customizing your PHP_CodeSniffer configuration: PHP_CodeSniffer configuration file syntax PHP Coding Standard Generator", "title": "See also"}, {"location": "faq/code-analysis/how-to-skip-an-analysis/", "text": "How to skip an analysis? # By default, Codacy automatically analyzes a repository whenever you push changes. However, you can override this behavior by adding one of the \"skip\" tags - [ci skip] , [skip ci] , [codacy skip] or [skip codacy] - anywhere in the subject or body of the commit message. For example: git commit -a -m \"Add eslint-plugin-chai-expect version 1.1.1 [ci skip]\" If you later decide to analyze a skipped commit, you can override any skip tags by reanalyzing the commit . Note This feature isn't supported for pull requests.", "title": "How to skip an analysis?"}, {"location": "faq/code-analysis/how-to-skip-an-analysis/#how-to-skip-an-analysis", "text": "By default, Codacy automatically analyzes a repository whenever you push changes. However, you can override this behavior by adding one of the \"skip\" tags - [ci skip] , [skip ci] , [codacy skip] or [skip codacy] - anywhere in the subject or body of the commit message. For example: git commit -a -m \"Add eslint-plugin-chai-expect version 1.1.1 [ci skip]\" If you later decide to analyze a skipped commit, you can override any skip tags by reanalyzing the commit . Note This feature isn't supported for pull requests.", "title": "How to skip an analysis?"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/", "text": "Which metrics does Codacy calculate? # Codacy performs static code analysis and calculates code duplication, code complexity, and code coverage metrics for most supported programming languages . The following sections describe how Codacy calculates each supported metric and where you can see each metric on the Codacy UI: Grade Issues Complexity Duplication Code coverage Note Depending on certain characteristics of your repository, such as the number of source code files and their size, Codacy may apply limits to the code analysis that impact the calculation of the supported metrics. Grade # Codacy assigns an overall grade to your repository branches and to individual files to help you assess the code quality of your repository. Grades represent a weighted average of the available code quality metrics (issues, complexity, duplication, and coverage), and range from A to F : Highest grade Lowest grade Codacy displays grades on the following places: Place Metric Files page Grade for each file in your repository Repository Dashboard Codacy badge Grade of each analyzed branch in your repository Email notifications Grade of your repository Organization overview Average grade of the repositories in your organization and grade of each repository Repositories list Grade of each repository in your organization Issues # Codacy calculates the number of issues in the following static code analysis categories: Code style: Code formatting and syntax problems, such as variable names style and enforcing the use of brackets and quotation marks Error prone: Code that may hide bugs and language keywords that should be used with caution, such as the operator == in JavaScript or Option.get in Scala Code complexity: High complexity methods and classes that should be refactored Performance: Code that can have performance problems Compatibility: Mainly for frontend code, compatibility problems across different browser versions Unused code: Unused variables and methods, code that can't be reached Security: Potential security vulnerabilities, including hard-coded passwords and keys (secret scanning), vulnerable dependencies (software composition analysis or SCA), and insecure code patterns (static application security testing or SAST). For more information, see the complete list of security issue categories Documentation: Methods and classes that don't have the correct comment annotations Best practice: Code that doesn't follow the recommended coding standards and best practices Comprehensibility: Code that can be difficult to understand and modify Besides this, Codacy also allows you to compare issues across repositories with different sizes by calculating the issue cost relative to a baseline of 1 point per line of code , where the cost of each issue depends on its severity: Critical = 10 points, Medium = 5 points, Minor = 1 point. This means that if your repository has 50% issues, the amount and severity of the issues in your repository is half of the baseline. Codacy displays issues on the following places: Place Metric Commit detail page Pull request detail page Email notifications Number of new and fixed issues introduced by the commit or pull request Files page Number of issues in each file Issues page List of all issues detected in each branch Repository Dashboard Issue percentage and how the metric is evolving over time Organization overview Average issue percentage of the repositories in your organization and issue percentage of each repository Repositories list page Issue percentage in each repository in your organization Complexity # Codacy uses cyclomatic complexity to identify files with complex methods in your repository. Cyclomatic complexity is the number of linearly independent paths through the source code of a method: the more control flow statements used in a method, the higher the value. Methods with a high cyclomatic complexity are more difficult to test and more likely to have defects. Learn more about code complexity on Codacy's blog. Codacy calculates complexity as follows: The complexity value for each file is the highest cyclomatic complexity of the methods in the file. A file is considered complex if its cyclomatic complexity value is higher than the threshold File is complex when over . The complexity value of a commit or pull request is the sum of the cyclomatic complexity of the files that were changed in the commit or pull request and that have a high complexity increase, defined as an increase of 4 or more. Codacy displays complexity on the following places: Place Metric Commit detail page Pull request detail page Email notifications Variation of the complexity value introduced by the commit or pull request Files page Complexity value of each file Repository Dashboard Percentage of complex files in your repository and how the metric is evolving over time Organization overview Average percentage of complex files in the repositories in your organization and percentage of complex files in each repository Repositories list page Percentage of complex files in each repository in your organization Duplication # Codacy identifies clones or sequences of duplicate code that exist in at least two different places of the source code of your repository. Clones typically indicate deeper code quality issues and should be eliminated through abstraction when possible. Codacy calculates duplication as follows: The duplication value for each file is the number of clones in the file. A file is considered duplicated if the number of clones in the file is higher than the threshold File is duplicated when over . The duplication value of a commit or pull request is the number of clones introduced by the commit or pull request. Note You can customize the rules for identifying duplicated blocks of code when using PMD CPD to analyze the source code of your repository. Codacy displays duplication on the following places: Place Metric Commit detail page Pull request detail page Email notifications Number of clones added or fixed by a commit or pull request Files page Duplication value of each file Repository Dashboard Percentage of duplicated files in your repository and how the metric is evolving over time Organization overview Average percentage of duplicated files in the repositories in your organization and percentage of complex files in each repository Repositories list page Percentage of duplicated files in each repository in your organization Code coverage # Code coverage describes the degree to which the source code of a program is tested. There are several types of coverage, but Codacy uses line coverage, which measures the percentage of coverable lines of code that are covered by automated tests. Learn more about code coverage on Codacy's blog. You must set up your CI/CD pipeline to upload code coverage data to Codacy . Because of this, the tool that you use to generate the coverage reports is responsible for creating the data that Codacy then uses to calculate code coverage. Codacy calculates code coverage as follows: The coverage value for each file is the percentage of coverable lines that are covered by tests in the file. If a line is covered multiple times, Codacy counts it as a single covered line when calculating coverage. A repository is considered to have acceptable coverage if the percentage of coverable lines that are covered by tests in the repository is higher than the threshold Coverage is under . The coverage variation of a commit or pull request is the increase or drop in the percentage of coverable lines that are covered by tests in the repository because of the changes of the commit or pull request. The diff coverage of a pull request is the percentage of coverable lines that the pull request added or modified that are covered by tests. If a pull request doesn't add or modify any coverable lines, the diff coverage is \u2205 (not applicable). This scenario happens when the only changes in a pull request are: Deleted lines Added or modified lines that aren't coverable Note If you encounter a situation where Codacy shows an unexpected drop in coverage, learn about the most common reasons causing those scenarios . Once the coverage setup is complete, Codacy displays coverage data on the following places: Place Metric Commit detail page Pull request detail page Email notifications Variation in percentage points of the coverage value for all files in the commit or pull request Pull request detail page Diff coverage for the changes included in the pull request Files page Coverage percentage of each file Repository Dashboard Coverage of the most recent commit of the selected branch and its evolution over time Codacy badge Coverage of the most recent commit of the configured branch Organization overview Average coverage of the repositories in your organization and coverage of each repository Repositories list page Coverage of each repository in your organization See also # Diff coverage: we have a new metric and quality gate rule for PRs Why does Codacy show unexpected coverage changes? Does Codacy place limits on the code analysis?", "title": "Which metrics does Codacy calculate?"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#which-metrics-does-codacy-calculate", "text": "Codacy performs static code analysis and calculates code duplication, code complexity, and code coverage metrics for most supported programming languages . The following sections describe how Codacy calculates each supported metric and where you can see each metric on the Codacy UI: Grade Issues Complexity Duplication Code coverage Note Depending on certain characteristics of your repository, such as the number of source code files and their size, Codacy may apply limits to the code analysis that impact the calculation of the supported metrics.", "title": "Which metrics does Codacy calculate?"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#grade", "text": "Codacy assigns an overall grade to your repository branches and to individual files to help you assess the code quality of your repository. Grades represent a weighted average of the available code quality metrics (issues, complexity, duplication, and coverage), and range from A to F : Highest grade Lowest grade Codacy displays grades on the following places: Place Metric Files page Grade for each file in your repository Repository Dashboard Codacy badge Grade of each analyzed branch in your repository Email notifications Grade of your repository Organization overview Average grade of the repositories in your organization and grade of each repository Repositories list Grade of each repository in your organization", "title": "Grade"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#issues", "text": "Codacy calculates the number of issues in the following static code analysis categories: Code style: Code formatting and syntax problems, such as variable names style and enforcing the use of brackets and quotation marks Error prone: Code that may hide bugs and language keywords that should be used with caution, such as the operator == in JavaScript or Option.get in Scala Code complexity: High complexity methods and classes that should be refactored Performance: Code that can have performance problems Compatibility: Mainly for frontend code, compatibility problems across different browser versions Unused code: Unused variables and methods, code that can't be reached Security: Potential security vulnerabilities, including hard-coded passwords and keys (secret scanning), vulnerable dependencies (software composition analysis or SCA), and insecure code patterns (static application security testing or SAST). For more information, see the complete list of security issue categories Documentation: Methods and classes that don't have the correct comment annotations Best practice: Code that doesn't follow the recommended coding standards and best practices Comprehensibility: Code that can be difficult to understand and modify Besides this, Codacy also allows you to compare issues across repositories with different sizes by calculating the issue cost relative to a baseline of 1 point per line of code , where the cost of each issue depends on its severity: Critical = 10 points, Medium = 5 points, Minor = 1 point. This means that if your repository has 50% issues, the amount and severity of the issues in your repository is half of the baseline. Codacy displays issues on the following places: Place Metric Commit detail page Pull request detail page Email notifications Number of new and fixed issues introduced by the commit or pull request Files page Number of issues in each file Issues page List of all issues detected in each branch Repository Dashboard Issue percentage and how the metric is evolving over time Organization overview Average issue percentage of the repositories in your organization and issue percentage of each repository Repositories list page Issue percentage in each repository in your organization", "title": "Issues"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#complexity", "text": "Codacy uses cyclomatic complexity to identify files with complex methods in your repository. Cyclomatic complexity is the number of linearly independent paths through the source code of a method: the more control flow statements used in a method, the higher the value. Methods with a high cyclomatic complexity are more difficult to test and more likely to have defects. Learn more about code complexity on Codacy's blog. Codacy calculates complexity as follows: The complexity value for each file is the highest cyclomatic complexity of the methods in the file. A file is considered complex if its cyclomatic complexity value is higher than the threshold File is complex when over . The complexity value of a commit or pull request is the sum of the cyclomatic complexity of the files that were changed in the commit or pull request and that have a high complexity increase, defined as an increase of 4 or more. Codacy displays complexity on the following places: Place Metric Commit detail page Pull request detail page Email notifications Variation of the complexity value introduced by the commit or pull request Files page Complexity value of each file Repository Dashboard Percentage of complex files in your repository and how the metric is evolving over time Organization overview Average percentage of complex files in the repositories in your organization and percentage of complex files in each repository Repositories list page Percentage of complex files in each repository in your organization", "title": "Complexity"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#duplication", "text": "Codacy identifies clones or sequences of duplicate code that exist in at least two different places of the source code of your repository. Clones typically indicate deeper code quality issues and should be eliminated through abstraction when possible. Codacy calculates duplication as follows: The duplication value for each file is the number of clones in the file. A file is considered duplicated if the number of clones in the file is higher than the threshold File is duplicated when over . The duplication value of a commit or pull request is the number of clones introduced by the commit or pull request. Note You can customize the rules for identifying duplicated blocks of code when using PMD CPD to analyze the source code of your repository. Codacy displays duplication on the following places: Place Metric Commit detail page Pull request detail page Email notifications Number of clones added or fixed by a commit or pull request Files page Duplication value of each file Repository Dashboard Percentage of duplicated files in your repository and how the metric is evolving over time Organization overview Average percentage of duplicated files in the repositories in your organization and percentage of complex files in each repository Repositories list page Percentage of duplicated files in each repository in your organization", "title": "Duplication"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#code-coverage", "text": "Code coverage describes the degree to which the source code of a program is tested. There are several types of coverage, but Codacy uses line coverage, which measures the percentage of coverable lines of code that are covered by automated tests. Learn more about code coverage on Codacy's blog. You must set up your CI/CD pipeline to upload code coverage data to Codacy . Because of this, the tool that you use to generate the coverage reports is responsible for creating the data that Codacy then uses to calculate code coverage. Codacy calculates code coverage as follows: The coverage value for each file is the percentage of coverable lines that are covered by tests in the file. If a line is covered multiple times, Codacy counts it as a single covered line when calculating coverage. A repository is considered to have acceptable coverage if the percentage of coverable lines that are covered by tests in the repository is higher than the threshold Coverage is under . The coverage variation of a commit or pull request is the increase or drop in the percentage of coverable lines that are covered by tests in the repository because of the changes of the commit or pull request. The diff coverage of a pull request is the percentage of coverable lines that the pull request added or modified that are covered by tests. If a pull request doesn't add or modify any coverable lines, the diff coverage is \u2205 (not applicable). This scenario happens when the only changes in a pull request are: Deleted lines Added or modified lines that aren't coverable Note If you encounter a situation where Codacy shows an unexpected drop in coverage, learn about the most common reasons causing those scenarios . Once the coverage setup is complete, Codacy displays coverage data on the following places: Place Metric Commit detail page Pull request detail page Email notifications Variation in percentage points of the coverage value for all files in the commit or pull request Pull request detail page Diff coverage for the changes included in the pull request Files page Coverage percentage of each file Repository Dashboard Coverage of the most recent commit of the selected branch and its evolution over time Codacy badge Coverage of the most recent commit of the configured branch Organization overview Average coverage of the repositories in your organization and coverage of each repository Repositories list page Coverage of each repository in your organization", "title": "Code coverage"}, {"location": "faq/code-analysis/which-metrics-does-codacy-calculate/#see-also", "text": "Diff coverage: we have a new metric and quality gate rule for PRs Why does Codacy show unexpected coverage changes? Does Codacy place limits on the code analysis?", "title": "See also"}, {"location": "faq/code-analysis/why-does-codacy-show-unexpected-coverage-changes/", "text": "Why does Codacy show unexpected coverage changes? # You may encounter some situations where Codacy shows unexpected drops in coverage, potentially causing your quality gates to fail. Usually, these drops in coverage happen in files that the commit or pull request didn't change. There are multiple reasons for this, but it's important to understand that each coverage report that you upload to Codacy contains information about which lines of code in your repository are tested or not in a specific commit. In particular, each coverage report provides the following information about the lines of your source code files: Coverable lines (lines that can be tested), by listing those lines Covered lines (lines that were tested at least once), by marking those lines as tested or having a number of test hits Not coverable lines (lines that can't be tested), by not listing those lines For example, the coverage report represented below includes coverage information for two source code files: File ClassA.java has two coverable lines and all are covered by tests File ClassB.java has three coverable lines but only line 1 is covered by tests File Line number Covered by tests? ClassA.java 2 Yes 4 Yes ClassB.java 1 Yes 3 No 11 No Based on the information obtained from the coverage reports, Codacy calculates code coverage as follows: The coverage for a file, commit, or pull request is the percentage of covered lines in the universe of coverable lines for that file, commit, or pull request. For example, a commit with 85 covered lines out of a total of 100 coverable lines has 85% coverage. The coverage variation of a commit or pull request is the increase or drop in the percentage of coverable lines that are covered by tests in the repository because of the changes of the commit or pull request. The diff coverage of a pull request is the percentage of coverable lines that the pull request added or modified that are covered by tests. If a pull request doesn't add or modify any coverable lines, the diff coverage is \u2205 (not applicable). This scenario happens when the only changes in a pull request are: Deleted lines Added or modified lines that aren't coverable Important Note that changes external to a source code file can affect the lines that are or aren't covered in that file. Common reasons for unexpected coverage changes # There are several reasons that could cause Codacy to report unexpected coverage results, from changes to your source code to external factors. The following is a non-exhaustive list of the most common reasons: Adding new tests or removing existing tests from your project. Even small and localized changes to your tests can have an impact on the amount of covered lines across your repository. Changing the logic of your application or tests. Changing the control flow of your application or tests can mean that different areas of your code start or stop being covered by tests. For example, inverting the result of the Boolean expression of an if statement means that a different branch of your code could now be tested. Failing to upload coverage reports, or uploading a different number of reports between commits. This can be caused by a failed step in your CI/CD pipeline, for example. In the case of pull requests, you should make sure that you upload all relevant coverage reports for both the common ancestor commit and the head commit of the pull request branch. Ignoring files on Codacy. Updating the list of ignored files can have an impact on the amount of coverable and covered lines of the commits that Codacy compares to calculate the coverage variation metric. External factors affecting the execution of tests. A variety of factors that are external to your code can affect the execution of tests and, consequently, the results contained in the coverage reports. A few examples of these external factors are: Updates to dependencies of your project that could result in different test execution paths Misconfiguration of repository secrets that could prevent some test execution paths Tests that are dependent on time, such as running test cases only on specific dates or times of the day \"Flaky\" tests caused by any inconsistent or unreliable behavior of your code, infrastructure, or third-party services The examples below describe in more detail how specific changes in your code impact the coverage metrics that Codacy calculates. Example: Diff coverage is 100% but pull request coverage variation is negative # Consider an example pull request where Codacy shows the following metrics: 100% diff coverage A negative coverage variation There are two possible scenarios that could cause this result: Removing covered lines or tests Since diff coverage only applies to covered lines that the pull request added or modified, removed lines don't affect the diff coverage metric. However, removing covered lines or tests means that there are now less covered lines in the repository, causing a drop in coverage. Application logic changes A change in the flow of execution of your application or tests can mean that a different number of coverable lines in your repository are now covered by tests, causing a drop in coverage. However, if all lines modified in the pull request continue to be covered, the diff coverage metric is 100%. The table below represents two example coverage reports reflecting a pull request that causes line 1 of the file ClassB.java to stop being covered: Common ancestor commit Head commit File Line number Covered by tests? Line number Covered by tests? ClassA.java 2 Yes 2 Yes 4 Yes 4 Yes ClassB.java 1 Yes 1 No 3 No 3 No 11 No 11 No The table below displays the code coverage metrics as calculated by Codacy: Initially, ClassB.java was 33.33% covered but after the changes from the pull request the file is now 0% covered, causing the repository coverage to drop 20% As long as the pull request also modified any covered line that continues to be covered, the diff coverage is 100% Common ancestor commit Head commit Pull request results File Coverable lines Covered lines Coverage Coverable lines Covered lines Coverage Coverage variation Diff coverage ClassA.java 2 2 100% 2 2 100% 0% ClassB.java 3 1 33.33% 3 0 0% -33.33% Total 5 3 60% 5 2 40% -20% 100% Example: Pull request coverage variation is negative but no files have coverage variation # Consider an example pull request where Codacy shows the following metrics: Negative coverage variation There aren't any files with coverage variation Removing covered lines from a file that had 100% coverage means that the file will continue to have 100% coverage. All lines in the file continue to be covered, even though there are now less covered lines. As such, there is no coverage variation for the file. However, since the proportion between the total number of covered and coverable lines across all files in the repository is now different, there can be a drop in the coverage variation for the pull request. Important If you're using the gate Coverage variation is under , configure at least a -0.10% coverage variation margin to ensure that developers aren't blocked while performing code refactors such as the one from this example. The table below represents two example coverage reports reflecting a pull request that removes lines 5 and 6 of the file ClassA.java : Common ancestor commit Head commit File Line number Covered by tests? Line number Covered by tests? ClassA.java 2 Yes 2 Yes 4 Yes 4 Yes 5 Yes 6 Yes ClassB.java 1 Yes 1 Yes 3 No 3 No 11 No 11 No The table below displays the code coverage metrics as calculated by Codacy: Initially, ClassA.java was 100% covered and continues to be 100% covered after the pull request, causing the coverage variation for the file to be 0% However, there were 62.5% lines covered across all files in the repository but after the pull request only 60% of the lines are now covered, causing the pull request coverage variation to drop 2.5% Common ancestor commit Head commit Pull request results File Coverable lines Covered lines Coverage Coverable lines Covered lines Coverage Coverage variation ClassA.java 4 4 100% 2 2 100% 0% ClassB.java 3 1 33.33% 3 1 33.33% 0% Total 7 5 62.5% 5 3 60% -2.5% See also # Which metrics does Codacy calculate? Adding coverage to your repository /*Center text*/ .center { text-align: center !important; } /*Right border*/ th.border { border-right: 1px solid white; } .border { border-right: 1px solid var(--md-default-fg-color--light); } /*Red background*/ .background-red { background-color: #ffe6e6; } /*Green text*/ .text-green { color: #21c178; } /*Red text*/ .text-red { color: #ef5454; }", "title": "Why does Codacy show unexpected coverage changes?"}, {"location": "faq/code-analysis/why-does-codacy-show-unexpected-coverage-changes/#why-does-codacy-show-unexpected-coverage-changes", "text": "You may encounter some situations where Codacy shows unexpected drops in coverage, potentially causing your quality gates to fail. Usually, these drops in coverage happen in files that the commit or pull request didn't change. There are multiple reasons for this, but it's important to understand that each coverage report that you upload to Codacy contains information about which lines of code in your repository are tested or not in a specific commit. In particular, each coverage report provides the following information about the lines of your source code files: Coverable lines (lines that can be tested), by listing those lines Covered lines (lines that were tested at least once), by marking those lines as tested or having a number of test hits Not coverable lines (lines that can't be tested), by not listing those lines For example, the coverage report represented below includes coverage information for two source code files: File ClassA.java has two coverable lines and all are covered by tests File ClassB.java has three coverable lines but only line 1 is covered by tests File Line number Covered by tests? ClassA.java 2 Yes 4 Yes ClassB.java 1 Yes 3 No 11 No Based on the information obtained from the coverage reports, Codacy calculates code coverage as follows: The coverage for a file, commit, or pull request is the percentage of covered lines in the universe of coverable lines for that file, commit, or pull request. For example, a commit with 85 covered lines out of a total of 100 coverable lines has 85% coverage. The coverage variation of a commit or pull request is the increase or drop in the percentage of coverable lines that are covered by tests in the repository because of the changes of the commit or pull request. The diff coverage of a pull request is the percentage of coverable lines that the pull request added or modified that are covered by tests. If a pull request doesn't add or modify any coverable lines, the diff coverage is \u2205 (not applicable). This scenario happens when the only changes in a pull request are: Deleted lines Added or modified lines that aren't coverable Important Note that changes external to a source code file can affect the lines that are or aren't covered in that file.", "title": "Why does Codacy show unexpected coverage changes?"}, {"location": "faq/code-analysis/why-does-codacy-show-unexpected-coverage-changes/#common-reasons-for-unexpected-coverage-changes", "text": "There are several reasons that could cause Codacy to report unexpected coverage results, from changes to your source code to external factors. The following is a non-exhaustive list of the most common reasons: Adding new tests or removing existing tests from your project. Even small and localized changes to your tests can have an impact on the amount of covered lines across your repository. Changing the logic of your application or tests. Changing the control flow of your application or tests can mean that different areas of your code start or stop being covered by tests. For example, inverting the result of the Boolean expression of an if statement means that a different branch of your code could now be tested. Failing to upload coverage reports, or uploading a different number of reports between commits. This can be caused by a failed step in your CI/CD pipeline, for example. In the case of pull requests, you should make sure that you upload all relevant coverage reports for both the common ancestor commit and the head commit of the pull request branch. Ignoring files on Codacy. Updating the list of ignored files can have an impact on the amount of coverable and covered lines of the commits that Codacy compares to calculate the coverage variation metric. External factors affecting the execution of tests. A variety of factors that are external to your code can affect the execution of tests and, consequently, the results contained in the coverage reports. A few examples of these external factors are: Updates to dependencies of your project that could result in different test execution paths Misconfiguration of repository secrets that could prevent some test execution paths Tests that are dependent on time, such as running test cases only on specific dates or times of the day \"Flaky\" tests caused by any inconsistent or unreliable behavior of your code, infrastructure, or third-party services The examples below describe in more detail how specific changes in your code impact the coverage metrics that Codacy calculates.", "title": "Common reasons for unexpected coverage changes"}, {"location": "faq/code-analysis/why-does-codacy-show-unexpected-coverage-changes/#example-diff-coverage-is-100-but-pull-request-coverage-variation-is-negative", "text": "Consider an example pull request where Codacy shows the following metrics: 100% diff coverage A negative coverage variation There are two possible scenarios that could cause this result: Removing covered lines or tests Since diff coverage only applies to covered lines that the pull request added or modified, removed lines don't affect the diff coverage metric. However, removing covered lines or tests means that there are now less covered lines in the repository, causing a drop in coverage. Application logic changes A change in the flow of execution of your application or tests can mean that a different number of coverable lines in your repository are now covered by tests, causing a drop in coverage. However, if all lines modified in the pull request continue to be covered, the diff coverage metric is 100%. The table below represents two example coverage reports reflecting a pull request that causes line 1 of the file ClassB.java to stop being covered: Common ancestor commit Head commit File Line number Covered by tests? Line number Covered by tests? ClassA.java 2 Yes 2 Yes 4 Yes 4 Yes ClassB.java 1 Yes 1 No 3 No 3 No 11 No 11 No The table below displays the code coverage metrics as calculated by Codacy: Initially, ClassB.java was 33.33% covered but after the changes from the pull request the file is now 0% covered, causing the repository coverage to drop 20% As long as the pull request also modified any covered line that continues to be covered, the diff coverage is 100% Common ancestor commit Head commit Pull request results File Coverable lines Covered lines Coverage Coverable lines Covered lines Coverage Coverage variation Diff coverage ClassA.java 2 2 100% 2 2 100% 0% ClassB.java 3 1 33.33% 3 0 0% -33.33% Total 5 3 60% 5 2 40% -20% 100%", "title": "Example: Diff coverage is 100% but pull request coverage variation is negative"}, {"location": "faq/code-analysis/why-does-codacy-show-unexpected-coverage-changes/#example-pull-request-coverage-variation-is-negative-but-no-files-have-coverage-variation", "text": "Consider an example pull request where Codacy shows the following metrics: Negative coverage variation There aren't any files with coverage variation Removing covered lines from a file that had 100% coverage means that the file will continue to have 100% coverage. All lines in the file continue to be covered, even though there are now less covered lines. As such, there is no coverage variation for the file. However, since the proportion between the total number of covered and coverable lines across all files in the repository is now different, there can be a drop in the coverage variation for the pull request. Important If you're using the gate Coverage variation is under , configure at least a -0.10% coverage variation margin to ensure that developers aren't blocked while performing code refactors such as the one from this example. The table below represents two example coverage reports reflecting a pull request that removes lines 5 and 6 of the file ClassA.java : Common ancestor commit Head commit File Line number Covered by tests? Line number Covered by tests? ClassA.java 2 Yes 2 Yes 4 Yes 4 Yes 5 Yes 6 Yes ClassB.java 1 Yes 1 Yes 3 No 3 No 11 No 11 No The table below displays the code coverage metrics as calculated by Codacy: Initially, ClassA.java was 100% covered and continues to be 100% covered after the pull request, causing the coverage variation for the file to be 0% However, there were 62.5% lines covered across all files in the repository but after the pull request only 60% of the lines are now covered, causing the pull request coverage variation to drop 2.5% Common ancestor commit Head commit Pull request results File Coverable lines Covered lines Coverage Coverable lines Covered lines Coverage Coverage variation ClassA.java 4 4 100% 2 2 100% 0% ClassB.java 3 1 33.33% 3 1 33.33% 0% Total 7 5 62.5% 5 3 60% -2.5%", "title": "Example: Pull request coverage variation is negative but no files have coverage variation"}, {"location": "faq/code-analysis/why-does-codacy-show-unexpected-coverage-changes/#see-also", "text": "Which metrics does Codacy calculate? Adding coverage to your repository /*Center text*/ .center { text-align: center !important; } /*Right border*/ th.border { border-right: 1px solid white; } .border { border-right: 1px solid var(--md-default-fg-color--light); } /*Red background*/ .background-red { background-color: #ffe6e6; } /*Green text*/ .text-green { color: #21c178; } /*Red text*/ .text-red { color: #ef5454; }", "title": "See also"}, {"location": "faq/general/does-codacy-keep-audit-logs/", "text": "Does Codacy keep audit logs for my organization? # On Business plan , Codacy logs significant organization events that can be retrieved for audit reporting. See Audit logs for organizations for the complete list of events that Codacy logs, and how to obtain audit log data.", "title": "Does Codacy keep audit logs for my organization?"}, {"location": "faq/general/does-codacy-keep-audit-logs/#does-codacy-keep-audit-logs-for-my-organization", "text": "On Business plan , Codacy logs significant organization events that can be retrieved for audit reporting. See Audit logs for organizations for the complete list of events that Codacy logs, and how to obtain audit log data.", "title": "Does Codacy keep audit logs for my organization?"}, {"location": "faq/general/how-can-i-change-or-cancel-my-plan/", "text": "How can I change or cancel my plan? # You can change or cancel your Codacy plan at any time. If you choose to cancel your annual subscription before the conclusion of the 12 months, your account will continue to work for the remainder of the annual billing period. Codacy values feedback and we thank you in advance for letting us know the primary reason behind your decision to leave, whether budgetary constraints or missing deal-breaker functionality. If you're using Codacy Cloud # If you're using Codacy Cloud see how to change the plan and billing of your Codacy organization . Alternatively, delete your organization to remove all its repositories from Codacy and cancel your existing plan. Note If you're using GitHub Marketplace, update your billing details or cancel your plan directly on your GitHub Billing page . If you cancel your plan or switch to a different Enterprise plan, some repositories may show outdated information in the Codacy UI. To update this information, reanalyze the repositories or push new commits. If you're using Codacy Self-hosted # To help you understand how you're consuming your licensed Codacy seats, use codacy-usage-report to obtain details about the activity of the users in your Codacy Self-hosted instance. If you decide to cancel your plan, please contact support@codacy.com and we'll swiftly process the cancellation. See also # Changing your plan and billing", "title": "How can I change or cancel my plan?"}, {"location": "faq/general/how-can-i-change-or-cancel-my-plan/#how-can-i-change-or-cancel-my-plan", "text": "You can change or cancel your Codacy plan at any time. If you choose to cancel your annual subscription before the conclusion of the 12 months, your account will continue to work for the remainder of the annual billing period. Codacy values feedback and we thank you in advance for letting us know the primary reason behind your decision to leave, whether budgetary constraints or missing deal-breaker functionality.", "title": "How can I change or cancel my plan?"}, {"location": "faq/general/how-can-i-change-or-cancel-my-plan/#if-youre-using-codacy-cloud", "text": "If you're using Codacy Cloud see how to change the plan and billing of your Codacy organization . Alternatively, delete your organization to remove all its repositories from Codacy and cancel your existing plan. Note If you're using GitHub Marketplace, update your billing details or cancel your plan directly on your GitHub Billing page . If you cancel your plan or switch to a different Enterprise plan, some repositories may show outdated information in the Codacy UI. To update this information, reanalyze the repositories or push new commits.", "title": "If you're using Codacy Cloud"}, {"location": "faq/general/how-can-i-change-or-cancel-my-plan/#if-youre-using-codacy-self-hosted", "text": "To help you understand how you're consuming your licensed Codacy seats, use codacy-usage-report to obtain details about the activity of the users in your Codacy Self-hosted instance. If you decide to cancel your plan, please contact support@codacy.com and we'll swiftly process the cancellation.", "title": "If you're using Codacy Self-hosted"}, {"location": "faq/general/how-can-i-change-or-cancel-my-plan/#see-also", "text": "Changing your plan and billing", "title": "See also"}, {"location": "faq/general/how-do-i-allowlist-codacy-cloud-on-my-git-provider/", "text": "How do I allowlist Codacy Cloud on my Git provider? # This is a paid feature If you require an additional layer of security and control on your Git provider, you can configure an allowlist containing the specific IP addresses that are able to access your Git repositories and resources. To allowlist Codacy Cloud on your Git provider: Send an email to success@codacy.com or directly to your CSM asking us to enable static IP addresses for your organization. Note Enabling static IPs for an organization is a paid feature . After receiving a confirmation that static IP addresses are active for your Codacy Cloud organization, add the following IP addresses to the allowlist on your Git provider: 34.254.123.99 18.203.76.9 The following are the instructions on how to allow IP addresses to access resources on each Git provider: GitHub Cloud: Managing allowed IP addresses for your organization GitLab Cloud: Restrict group access by IP address Bitbucket Cloud: Allowlisting IP addresses", "title": "How do I allowlist Codacy Cloud on my Git provider?"}, {"location": "faq/general/how-do-i-allowlist-codacy-cloud-on-my-git-provider/#how-do-i-allowlist-codacy-cloud-on-my-git-provider", "text": "This is a paid feature If you require an additional layer of security and control on your Git provider, you can configure an allowlist containing the specific IP addresses that are able to access your Git repositories and resources. To allowlist Codacy Cloud on your Git provider: Send an email to success@codacy.com or directly to your CSM asking us to enable static IP addresses for your organization. Note Enabling static IPs for an organization is a paid feature . After receiving a confirmation that static IP addresses are active for your Codacy Cloud organization, add the following IP addresses to the allowlist on your Git provider: 34.254.123.99 18.203.76.9 The following are the instructions on how to allow IP addresses to access resources on each Git provider: GitHub Cloud: Managing allowed IP addresses for your organization GitLab Cloud: Restrict group access by IP address Bitbucket Cloud: Allowlisting IP addresses", "title": "How do I allowlist Codacy Cloud on my Git provider?"}, {"location": "faq/general/how-does-codacy-keep-my-data-secure/", "text": "How does Codacy keep my data secure? # Keeping our customers' data protected at all times is our highest priority. This security overview provides a high-level overview of the security practices put in place to achieve that objective. Have questions or feedback? Feel free to reach out to us at security@codacy.com .", "title": "How does Codacy keep my data secure?"}, {"location": "faq/general/how-does-codacy-keep-my-data-secure/#how-does-codacy-keep-my-data-secure", "text": "Keeping our customers' data protected at all times is our highest priority. This security overview provides a high-level overview of the security practices put in place to achieve that objective. Have questions or feedback? Feel free to reach out to us at security@codacy.com .", "title": "How does Codacy keep my data secure?"}, {"location": "faq/general/how-does-codacy-protect-my-privacy/", "text": "How does Codacy protect my privacy? # In May 2018 the new \"General Data Protection Regulation\" ( GDPR ) came into effect. This regulation contains the most significant changes to European data privacy legislation in the last 20 years and gives you more control over your personal data and greater transparency on how it's used. At Codacy, keeping your personal data safe has always been a top priority and we took GDPR as another opportunity for us to strengthen this commitment to you. We've changed our data processing policies, operations, activities, and documentation as a response to GDPR and have updated our Privacy Policy to incorporate said changes and specifically reflect the new regulation. Below are some highlights of the updated policy: Transparency: We've reworded our privacy policy for better navigation and to make it easier to read. Our policy outlines the type of personal data we collect, how we collect and process the data, and for what purposes. It also explains how we store, transfer, and share personal data, and our data retention practices Control: Our policy now further explains the control you have over information about you and your online activities. At any time, you can request information, correction, deletion, or changes to your personal data or/and make changes yourself GDPR: We've included additional language to discuss rights for users located in the European Union (EU) If you have any questions on this, please email us at privacy@codacy.com or reach out through our live chat option.", "title": "How does Codacy protect my privacy?"}, {"location": "faq/general/how-does-codacy-protect-my-privacy/#how-does-codacy-protect-my-privacy", "text": "In May 2018 the new \"General Data Protection Regulation\" ( GDPR ) came into effect. This regulation contains the most significant changes to European data privacy legislation in the last 20 years and gives you more control over your personal data and greater transparency on how it's used. At Codacy, keeping your personal data safe has always been a top priority and we took GDPR as another opportunity for us to strengthen this commitment to you. We've changed our data processing policies, operations, activities, and documentation as a response to GDPR and have updated our Privacy Policy to incorporate said changes and specifically reflect the new regulation. Below are some highlights of the updated policy: Transparency: We've reworded our privacy policy for better navigation and to make it easier to read. Our policy outlines the type of personal data we collect, how we collect and process the data, and for what purposes. It also explains how we store, transfer, and share personal data, and our data retention practices Control: Our policy now further explains the control you have over information about you and your online activities. At any time, you can request information, correction, deletion, or changes to your personal data or/and make changes yourself GDPR: We've included additional language to discuss rights for users located in the European Union (EU) If you have any questions on this, please email us at privacy@codacy.com or reach out through our live chat option.", "title": "How does Codacy protect my privacy?"}, {"location": "faq/general/how-does-codacy-support-bitbucket-cloud/", "text": "How does Codacy support Bitbucket Cloud? # When you use Bitbucket Cloud to sign up or log into Codacy, the Bitbucket teams that you belong to will be available to be added as Organizations on Codacy. After adding a team: Codacy displays the list of all repositories in that team so that you can add them to Codacy as repositories to be analyzed The members of the team will be able to join or request to join Codacy If you have repositories that don't belong to any team, you can still add those on Codacy directly under My Repositories . Limitations # Currently, the integration between Codacy and Bitbucket Cloud has the following limitations: Users that are deleted from Bitbucket Cloud are not automatically removed from Codacy. These users must be manually removed from Codacy, namely to ensure that Codacy only bills seats corresponding to active users. Deleted teams and repositories are not automatically deleted from Codacy. However, you can manually delete the corresponding Organizations or repositories from Codacy. Renamed Team workspace IDs aren't automatically renamed on Codacy, causing Codacy to stop analyzing the repositories in those teams. You must click the button Synchronize in the settings of the corresponding Organization on Codacy to synchronize the workspace ID and resume the analysis of the repositories. Repositories that are moved between teams are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. Codacy only sends commit and pull request notification emails to the authors of the commits and pull requests. Codacy doesn't analyze pull requests submitted from forked repositories. See also # What are organizations", "title": "How does Codacy support Bitbucket Cloud?"}, {"location": "faq/general/how-does-codacy-support-bitbucket-cloud/#how-does-codacy-support-bitbucket-cloud", "text": "When you use Bitbucket Cloud to sign up or log into Codacy, the Bitbucket teams that you belong to will be available to be added as Organizations on Codacy. After adding a team: Codacy displays the list of all repositories in that team so that you can add them to Codacy as repositories to be analyzed The members of the team will be able to join or request to join Codacy If you have repositories that don't belong to any team, you can still add those on Codacy directly under My Repositories .", "title": "How does Codacy support Bitbucket Cloud?"}, {"location": "faq/general/how-does-codacy-support-bitbucket-cloud/#limitations", "text": "Currently, the integration between Codacy and Bitbucket Cloud has the following limitations: Users that are deleted from Bitbucket Cloud are not automatically removed from Codacy. These users must be manually removed from Codacy, namely to ensure that Codacy only bills seats corresponding to active users. Deleted teams and repositories are not automatically deleted from Codacy. However, you can manually delete the corresponding Organizations or repositories from Codacy. Renamed Team workspace IDs aren't automatically renamed on Codacy, causing Codacy to stop analyzing the repositories in those teams. You must click the button Synchronize in the settings of the corresponding Organization on Codacy to synchronize the workspace ID and resume the analysis of the repositories. Repositories that are moved between teams are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. Codacy only sends commit and pull request notification emails to the authors of the commits and pull requests. Codacy doesn't analyze pull requests submitted from forked repositories.", "title": "Limitations"}, {"location": "faq/general/how-does-codacy-support-bitbucket-cloud/#see-also", "text": "What are organizations", "title": "See also"}, {"location": "faq/general/how-does-codacy-support-bitbucket-server/", "text": "How does Codacy support Bitbucket Server? # When you use Bitbucket Server to sign up or log into Codacy, the Bitbucket projects that you belong to will be available to be added as Organizations on Codacy. After adding a project: Codacy displays the list of all repositories that you own in that project so that you can add them to Codacy as repositories to be analyzed The members of the project will be able to join or request to join Codacy Limitations # Currently, the integration between Codacy and Bitbucket Server has the following limitations: Users that are deleted from Bitbucket Server are not automatically removed from Codacy. These users must be manually removed from Codacy, namely to ensure that Codacy only bills seats corresponding to active users. Renamed project keys aren't automatically renamed on Codacy, causing Codacy to stop analyzing the repositories in those projects. You must click the button Synchronize in the settings of the corresponding Organization on Codacy to synchronize the project key and resume the analysis of the repositories. Deleted projects and repositories are not automatically deleted from Codacy. However, you can manually delete the corresponding Organizations or repositories from Codacy. Repositories that are moved between teams are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. Personal repositories are not supported. You can only add repositories to Codacy if they belong to a project. Codacy only sends commit and pull request notification emails to the authors of the commits and pull requests. Pull request summaries aren't available The Repositories screen doesn't include the \"Last updated\" date for each repository. As such, the repositories are sorted alphabetically. Codacy doesn't analyze pull requests submitted from forked repositories. See also # What are organizations", "title": "How does Codacy support Bitbucket Server?"}, {"location": "faq/general/how-does-codacy-support-bitbucket-server/#how-does-codacy-support-bitbucket-server", "text": "When you use Bitbucket Server to sign up or log into Codacy, the Bitbucket projects that you belong to will be available to be added as Organizations on Codacy. After adding a project: Codacy displays the list of all repositories that you own in that project so that you can add them to Codacy as repositories to be analyzed The members of the project will be able to join or request to join Codacy", "title": "How does Codacy support Bitbucket Server?"}, {"location": "faq/general/how-does-codacy-support-bitbucket-server/#limitations", "text": "Currently, the integration between Codacy and Bitbucket Server has the following limitations: Users that are deleted from Bitbucket Server are not automatically removed from Codacy. These users must be manually removed from Codacy, namely to ensure that Codacy only bills seats corresponding to active users. Renamed project keys aren't automatically renamed on Codacy, causing Codacy to stop analyzing the repositories in those projects. You must click the button Synchronize in the settings of the corresponding Organization on Codacy to synchronize the project key and resume the analysis of the repositories. Deleted projects and repositories are not automatically deleted from Codacy. However, you can manually delete the corresponding Organizations or repositories from Codacy. Repositories that are moved between teams are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. Personal repositories are not supported. You can only add repositories to Codacy if they belong to a project. Codacy only sends commit and pull request notification emails to the authors of the commits and pull requests. Pull request summaries aren't available The Repositories screen doesn't include the \"Last updated\" date for each repository. As such, the repositories are sorted alphabetically. Codacy doesn't analyze pull requests submitted from forked repositories.", "title": "Limitations"}, {"location": "faq/general/how-does-codacy-support-bitbucket-server/#see-also", "text": "What are organizations", "title": "See also"}, {"location": "faq/general/how-does-codacy-support-gitlab-cloud/", "text": "How does Codacy support GitLab Cloud? # When you use GitLab Cloud to sign up or log into Codacy, the GitLab Groups that you belong to will be available to be added as Organizations on Codacy. After adding a Group: Codacy displays the list of all repositories that you own in that Group and Subgroups so that you can add them to Codacy as repositories to be analyzed The members of the Group will be able to join or request to join Codacy If you have repositories that don't belong to any Group, you can still add those on Codacy by choosing your \"personal\" organization . Limitations # Currently, the integration between Codacy and GitLab Cloud has the following limitations: Users that are deleted from GitLab are not automatically removed from Codacy. These users must be manually removed from Codacy, namely to ensure that Codacy only bills seats corresponding to active users. Renamed Group paths aren't automatically renamed on Codacy, causing Codacy to stop analyzing the repositories in those groups. You must click the button Synchronize in the settings of the corresponding Organization on Codacy to synchronize the Group path and resume the analysis of the repositories. Deleted Groups are not automatically deleted from Codacy. However, you can manually delete the corresponding Organizations from Codacy. Repositories that are moved between Groups are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. It is not possible to add repositories with the same name to the Codacy organization. Repositories having the same name but belonging to different GitLab Subgroups would collide if they were added to the same Codacy organization. Codacy doesn't analyze pull requests submitted from forked repositories. Share projects with other groups isn't fully supported on Codacy. Users from the \"other groups\" can join the Organization that owns the project on the Codacy side, and Codacy will analyze the commits from those users. However, those users won't be able to access the project on the Codacy UI. See also # What are organizations", "title": "How does Codacy support GitLab Cloud?"}, {"location": "faq/general/how-does-codacy-support-gitlab-cloud/#how-does-codacy-support-gitlab-cloud", "text": "When you use GitLab Cloud to sign up or log into Codacy, the GitLab Groups that you belong to will be available to be added as Organizations on Codacy. After adding a Group: Codacy displays the list of all repositories that you own in that Group and Subgroups so that you can add them to Codacy as repositories to be analyzed The members of the Group will be able to join or request to join Codacy If you have repositories that don't belong to any Group, you can still add those on Codacy by choosing your \"personal\" organization .", "title": "How does Codacy support GitLab Cloud?"}, {"location": "faq/general/how-does-codacy-support-gitlab-cloud/#limitations", "text": "Currently, the integration between Codacy and GitLab Cloud has the following limitations: Users that are deleted from GitLab are not automatically removed from Codacy. These users must be manually removed from Codacy, namely to ensure that Codacy only bills seats corresponding to active users. Renamed Group paths aren't automatically renamed on Codacy, causing Codacy to stop analyzing the repositories in those groups. You must click the button Synchronize in the settings of the corresponding Organization on Codacy to synchronize the Group path and resume the analysis of the repositories. Deleted Groups are not automatically deleted from Codacy. However, you can manually delete the corresponding Organizations from Codacy. Repositories that are moved between Groups are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. It is not possible to add repositories with the same name to the Codacy organization. Repositories having the same name but belonging to different GitLab Subgroups would collide if they were added to the same Codacy organization. Codacy doesn't analyze pull requests submitted from forked repositories. Share projects with other groups isn't fully supported on Codacy. Users from the \"other groups\" can join the Organization that owns the project on the Codacy side, and Codacy will analyze the commits from those users. However, those users won't be able to access the project on the Codacy UI.", "title": "Limitations"}, {"location": "faq/general/how-does-codacy-support-gitlab-cloud/#see-also", "text": "What are organizations", "title": "See also"}, {"location": "faq/general/how-does-codacy-support-gitlab-enterprise/", "text": "How does Codacy support GitLab Enterprise? # When you use GitLab Enterprise to sign up or log into Codacy, the GitLab Groups that you belong to will be available to be added as Organizations on Codacy. After adding a Group: Codacy displays the list of all repositories that you own in that Group and Subgroups so that you can add them to Codacy as repositories to be analyzed The members of the Group will be able to join or request to join Codacy If you have repositories that don't belong to any Group, you can still add those on Codacy by choosing your \"personal\" organization . Limitations # Currently, the integration between Codacy and GitLab Enterprise has the following limitations: Repositories that are moved between Groups are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. It is not possible to add repositories with the same name to the Codacy organization. Repositories having the same name but belonging to different GitLab Subgroups would collide if they were added to the same Codacy organization. Codacy doesn't analyze pull requests submitted from forked repositories. Share projects with other groups isn't fully supported on Codacy. Users from the \"other groups\" can join the Organization that owns the project on the Codacy side, and Codacy will analyze the commits from those users. However, those users won't be able to access the project on the Codacy UI. See also # What are organizations", "title": "How does Codacy support GitLab Enterprise?"}, {"location": "faq/general/how-does-codacy-support-gitlab-enterprise/#how-does-codacy-support-gitlab-enterprise", "text": "When you use GitLab Enterprise to sign up or log into Codacy, the GitLab Groups that you belong to will be available to be added as Organizations on Codacy. After adding a Group: Codacy displays the list of all repositories that you own in that Group and Subgroups so that you can add them to Codacy as repositories to be analyzed The members of the Group will be able to join or request to join Codacy If you have repositories that don't belong to any Group, you can still add those on Codacy by choosing your \"personal\" organization .", "title": "How does Codacy support GitLab Enterprise?"}, {"location": "faq/general/how-does-codacy-support-gitlab-enterprise/#limitations", "text": "Currently, the integration between Codacy and GitLab Enterprise has the following limitations: Repositories that are moved between Groups are not automatically transferred between Organizations on Codacy. You must manually delete these repositories from their source Organization and add them to their new Organization. It is not possible to add repositories with the same name to the Codacy organization. Repositories having the same name but belonging to different GitLab Subgroups would collide if they were added to the same Codacy organization. Codacy doesn't analyze pull requests submitted from forked repositories. Share projects with other groups isn't fully supported on Codacy. Users from the \"other groups\" can join the Organization that owns the project on the Codacy side, and Codacy will analyze the commits from those users. However, those users won't be able to access the project on the Codacy UI.", "title": "Limitations"}, {"location": "faq/general/how-does-codacy-support-gitlab-enterprise/#see-also", "text": "What are organizations", "title": "See also"}, {"location": "faq/general/which-platforms-and-technologies-does-codacy-support/", "text": "Which platforms and technologies does Codacy support? # This page includes information about software platforms and technologies compatible with Codacy. Supported version control systems and Git providers # Codacy supports repositories from the following Git providers: Hosting model Name used on Codacy Required Codacy version GitHub GitHub.com GitHub Cloud Codacy Cloud or Codacy Self-hosted GitHub Enterprise Server version 3.6.2 or later GitHub Enterprise Codacy Self-hosted GitLab GitLab SaaS GitLab Cloud Codacy Cloud or Codacy Self-hosted GitLab Self-managed version 14.8 or later GitLab Enterprise Codacy Self-hosted Bitbucket Bitbucket Cloud Bitbucket Cloud Codacy Cloud or Codacy Self-hosted Bitbucket Data Center Bitbucket Server version 6.6.0 or later Bitbucket Server Codacy Self-hosted Note Although older versions of the self-hosted Git providers may work with Codacy without loss of functionality, Codacy will only fix issues and ensure compatibility with the versions listed above. Supported browsers # Codacy runs on every modern browser supporting HTML5 and CSS3: Chrome 67+ Firefox 45+ Internet Explorer 11+ Microsoft Edge 13+ Supported character encodings # Codacy supports the UTF-8 character encoding standard.", "title": "Which platforms and technologies does Codacy support?"}, {"location": "faq/general/which-platforms-and-technologies-does-codacy-support/#which-platforms-and-technologies-does-codacy-support", "text": "This page includes information about software platforms and technologies compatible with Codacy.", "title": "Which platforms and technologies does Codacy support?"}, {"location": "faq/general/which-platforms-and-technologies-does-codacy-support/#supported-version-control-systems-and-git-providers", "text": "Codacy supports repositories from the following Git providers: Hosting model Name used on Codacy Required Codacy version GitHub GitHub.com GitHub Cloud Codacy Cloud or Codacy Self-hosted GitHub Enterprise Server version 3.6.2 or later GitHub Enterprise Codacy Self-hosted GitLab GitLab SaaS GitLab Cloud Codacy Cloud or Codacy Self-hosted GitLab Self-managed version 14.8 or later GitLab Enterprise Codacy Self-hosted Bitbucket Bitbucket Cloud Bitbucket Cloud Codacy Cloud or Codacy Self-hosted Bitbucket Data Center Bitbucket Server version 6.6.0 or later Bitbucket Server Codacy Self-hosted Note Although older versions of the self-hosted Git providers may work with Codacy without loss of functionality, Codacy will only fix issues and ensure compatibility with the versions listed above.", "title": "Supported version control systems and Git providers"}, {"location": "faq/general/which-platforms-and-technologies-does-codacy-support/#supported-browsers", "text": "Codacy runs on every modern browser supporting HTML5 and CSS3: Chrome 67+ Firefox 45+ Internet Explorer 11+ Microsoft Edge 13+", "title": "Supported browsers"}, {"location": "faq/general/which-platforms-and-technologies-does-codacy-support/#supported-character-encodings", "text": "Codacy supports the UTF-8 character encoding standard.", "title": "Supported character encodings"}, {"location": "faq/repositories/how-do-i-reanalyze-my-repository/", "text": "How do I reanalyze my repository? # Organization admins can manage access to this feature Reanalyze the last commit in your branch or pull request: To update the Codacy analysis results taking into account the most recent configurations for your repository without waiting for a new commit to trigger the analysis If the grade or Codacy badge for your branch is greyed out and displays an exclamation mark, which means that the analysis information isn't available for the last commit of the branch: Important If you have the setting Run analysis on your build server enabled in your repository Settings page so that you can run client-side tools , you can't trigger a new analysis from the Codacy UI. Instead, you must manually run the client-side tools or wait for them to report the results for a new commit. You can only reanalyze commits to branches or pull requests in your repository if the committer is part of your organization . Reanalyzing a branch # To reanalyze a branch in your repository: Open the Commits page for your repository and select the correct branch at the top of the page if you configured Codacy to analyze multiple branches . Then, select the most recent commit for that branch at the top of the list: Click the Reanalyze link to trigger a reanalysis. Codacy will display the status of the reanalysis request. Reanalyzing a pull request # To reanalyze a pull request in your repository: Open the Pull Requests page for your repository and select the pull request that you want to reanalyze. Click the Reanalyze button to trigger a reanalysis. Codacy will display the status of the reanalysis request. See also # Commit status Pull request status", "title": "How do I reanalyze my repository?"}, {"location": "faq/repositories/how-do-i-reanalyze-my-repository/#how-do-i-reanalyze-my-repository", "text": "Organization admins can manage access to this feature Reanalyze the last commit in your branch or pull request: To update the Codacy analysis results taking into account the most recent configurations for your repository without waiting for a new commit to trigger the analysis If the grade or Codacy badge for your branch is greyed out and displays an exclamation mark, which means that the analysis information isn't available for the last commit of the branch: Important If you have the setting Run analysis on your build server enabled in your repository Settings page so that you can run client-side tools , you can't trigger a new analysis from the Codacy UI. Instead, you must manually run the client-side tools or wait for them to report the results for a new commit. You can only reanalyze commits to branches or pull requests in your repository if the committer is part of your organization .", "title": "How do I reanalyze my repository?"}, {"location": "faq/repositories/how-do-i-reanalyze-my-repository/#reanalyzing-a-branch", "text": "To reanalyze a branch in your repository: Open the Commits page for your repository and select the correct branch at the top of the page if you configured Codacy to analyze multiple branches . Then, select the most recent commit for that branch at the top of the list: Click the Reanalyze link to trigger a reanalysis. Codacy will display the status of the reanalysis request.", "title": "Reanalyzing a branch"}, {"location": "faq/repositories/how-do-i-reanalyze-my-repository/#reanalyzing-a-pull-request", "text": "To reanalyze a pull request in your repository: Open the Pull Requests page for your repository and select the pull request that you want to reanalyze. Click the Reanalyze button to trigger a reanalysis. Codacy will display the status of the reanalysis request.", "title": "Reanalyzing a pull request"}, {"location": "faq/repositories/how-do-i-reanalyze-my-repository/#see-also", "text": "Commit status Pull request status", "title": "See also"}, {"location": "faq/repositories/i-moved-my-repository-on-the-git-provider/", "text": "I moved my repository on the Git provider # Currently, Codacy doesn't automatically detect moves of repositories between two organizations. To ensure that Codacy continues to analyze a repository that was moved to another organization on your Git provider: Delete the repository from the original organization on Codacy, taking note of the settings for this repository Add the repository to the new organization on Codacy and reconfigure the repository with the same settings as the original one If you can't find your repository in the original Codacy organization or if you need more help with this process, please contact us at support@codacy.com .", "title": "I moved my repository on the Git provider"}, {"location": "faq/repositories/i-moved-my-repository-on-the-git-provider/#i-moved-my-repository-on-the-git-provider", "text": "Currently, Codacy doesn't automatically detect moves of repositories between two organizations. To ensure that Codacy continues to analyze a repository that was moved to another organization on your Git provider: Delete the repository from the original organization on Codacy, taking note of the settings for this repository Add the repository to the new organization on Codacy and reconfigure the repository with the same settings as the original one If you can't find your repository in the original Codacy organization or if you need more help with this process, please contact us at support@codacy.com .", "title": "I moved my repository on the Git provider"}, {"location": "faq/repositories/i-renamed-my-repository-on-the-git-provider/", "text": "I renamed my repository on the Git provider # If you changed the name or URL of your repository on your Git provider, you can update the name and URL of the repository on Codacy to point to the new location. This ensures that you won't lose historical data about your repository on Codacy. To rename your repository on Codacy, open the page Settings and click the button Update repository .", "title": "I renamed my repository on the Git provider"}, {"location": "faq/repositories/i-renamed-my-repository-on-the-git-provider/#i-renamed-my-repository-on-the-git-provider", "text": "If you changed the name or URL of your repository on your Git provider, you can update the name and URL of the repository on Codacy to point to the new location. This ensures that you won't lose historical data about your repository on Codacy. To rename your repository on Codacy, open the page Settings and click the button Update repository .", "title": "I renamed my repository on the Git provider"}, {"location": "faq/troubleshooting/error-line-endings/", "text": "Error caused by incompatible line endings # Codacy executes the git diff command when analyzing new commits and pull requests to identify the lines of code that were changed. Codacy then uses this information to display the issues that were caused by the changes introduced by the commits or pull requests. If you have files in your repository that use the carriage return (CR) as the line end control character, the command git diff doesn't correctly identify line endings in the changed files. Because of this, Codacy is unable to use the output of the command and the Diff step of your commit or pull request analysis logs will display the message An error occurred during this step. Please, retry your analysis or contact support . The CR line end control character was used by older Classic Mac OS systems, and for the sake of interoperability it's recommended that you: Find the files in your repository that include CR line endings. Tip On *nix operating systems including macOS, you can use the command file to detect files in your repository that use CR line endings. For example, run the following command on the root of your repository: find . -type f -exec file {} \\; | grep \"CR line\" Update the line endings in your source code files to use either the control characters: LF, if primarily using Unix-like systems such as Linux or the newer macOS operating system CRLF, if primarily using the Microsoft Windows operating system Tip This article on Wikipedia includes examples on how to convert the line endings in your files. After converting the line endings in your source code files, you may also want to check the following resources for help on standardizing the line endings on your repositories and how to configure Git to correctly handle line endings: What's the recommended way to store files in Git? Customizing Git - Formatting and Whitespace Configuring Git to handle line endings Mind the End of Your Line", "title": "Error caused by incompatible line endings"}, {"location": "faq/troubleshooting/error-line-endings/#error-caused-by-incompatible-line-endings", "text": "Codacy executes the git diff command when analyzing new commits and pull requests to identify the lines of code that were changed. Codacy then uses this information to display the issues that were caused by the changes introduced by the commits or pull requests. If you have files in your repository that use the carriage return (CR) as the line end control character, the command git diff doesn't correctly identify line endings in the changed files. Because of this, Codacy is unable to use the output of the command and the Diff step of your commit or pull request analysis logs will display the message An error occurred during this step. Please, retry your analysis or contact support . The CR line end control character was used by older Classic Mac OS systems, and for the sake of interoperability it's recommended that you: Find the files in your repository that include CR line endings. Tip On *nix operating systems including macOS, you can use the command file to detect files in your repository that use CR line endings. For example, run the following command on the root of your repository: find . -type f -exec file {} \\; | grep \"CR line\" Update the line endings in your source code files to use either the control characters: LF, if primarily using Unix-like systems such as Linux or the newer macOS operating system CRLF, if primarily using the Microsoft Windows operating system Tip This article on Wikipedia includes examples on how to convert the line endings in your files. After converting the line endings in your source code files, you may also want to check the following resources for help on standardizing the line endings on your repositories and how to configure Git to correctly handle line endings: What's the recommended way to store files in Git? Customizing Git - Formatting and Whitespace Configuring Git to handle line endings Mind the End of Your Line", "title": "Error caused by incompatible line endings"}, {"location": "faq/troubleshooting/not-a-member-of-the-organization/", "text": "Not a member of the organization # This page applies only to Codacy Cloud When you see the message Not a member of the organization it means that Codacy Cloud can't analyze a commit because the associated email address doesn't belong to any member or committer of your Codacy organization . You can check which email address is associated with a commit by hovering the cursor on the name of the committer on the page for the commit: To verify which email addresses are associated with the Codacy Cloud account, the user must click on their avatar on the top right-hand corner, select Your account , and open the page Emails : There may be different reasons for this issue to happen: The user making the commit hasn't signed in to Codacy Cloud and joined the organization yet The user must join the organization or, if you're the organization admin, you can add the user instead. The commit email address isn't associated with the account of a Codacy Cloud user Make sure the user updates the email addresses associated with their Codacy account to include the missing commit email address. Git isn't configured with the correct email address Make sure the user sets the Git email address correctly.", "title": "Not a member of the organization"}, {"location": "faq/troubleshooting/not-a-member-of-the-organization/#not-a-member-of-the-organization", "text": "This page applies only to Codacy Cloud When you see the message Not a member of the organization it means that Codacy Cloud can't analyze a commit because the associated email address doesn't belong to any member or committer of your Codacy organization . You can check which email address is associated with a commit by hovering the cursor on the name of the committer on the page for the commit: To verify which email addresses are associated with the Codacy Cloud account, the user must click on their avatar on the top right-hand corner, select Your account , and open the page Emails : There may be different reasons for this issue to happen: The user making the commit hasn't signed in to Codacy Cloud and joined the organization yet The user must join the organization or, if you're the organization admin, you can add the user instead. The commit email address isn't associated with the account of a Codacy Cloud user Make sure the user updates the email addresses associated with their Codacy account to include the missing commit email address. Git isn't configured with the correct email address Make sure the user sets the Git email address correctly.", "title": "Not a member of the organization"}, {"location": "faq/troubleshooting/we-no-longer-have-access-to-this-repository/", "text": "We no longer have access to this repository, check your SSH keys # Some changes on your Git provider can prevent Codacy from cloning your private repository. When this happens, Codacy displays the error message \"We no longer have access to this repository\" on the Repository Dashboard page. The repository was renamed or moved # If you renamed the repository or moved it to a different account on the Git provider: On Codacy, open your Repository Settings , tab General . Click the button Update repository in the Synchronize with provider area. The user that configured the repository no longer has access # This section applies only to GitLab and Bitbucket On GitLab and Bitbucket organizations, Codacy uses SSH keys to clone your private repositories. Depending on the level of access that the user configuring the repository on Codacy has on the remote Git provider, an SSH key can be added either: Directly to the repository itself, if the user has permissions to add SSH keys to the repository To the user account, if the user only has read or commit permissions on the repository If the user that initially configured the repository on Codacy was using a user account SSH key but no longer has access to the repository on GitLab or Bitbucket: On Codacy, open your Repository Settings , tab General . Click the button Generate New Repository Key to add a new SSH key to your repository deployment keys. This is only possible if the user configuring the integration with the remote Git provider has administrator access to the repository. Otherwise, this operation will fail. Alternatively, you can do this process manually by copying the SSH key. Note If your repository is using submodules on Codacy , add a new SSH user key to your Git provider account instead. Open the tab Integrations , and refresh your GitLab or Bitbucket integration.", "title": "We no longer have access to this repository, check your SSH keys"}, {"location": "faq/troubleshooting/we-no-longer-have-access-to-this-repository/#we-no-longer-have-access-to-this-repository-check-your-ssh-keys", "text": "Some changes on your Git provider can prevent Codacy from cloning your private repository. When this happens, Codacy displays the error message \"We no longer have access to this repository\" on the Repository Dashboard page.", "title": "We no longer have access to this repository, check your SSH keys"}, {"location": "faq/troubleshooting/we-no-longer-have-access-to-this-repository/#the-repository-was-renamed-or-moved", "text": "If you renamed the repository or moved it to a different account on the Git provider: On Codacy, open your Repository Settings , tab General . Click the button Update repository in the Synchronize with provider area.", "title": "The repository was renamed or moved"}, {"location": "faq/troubleshooting/we-no-longer-have-access-to-this-repository/#the-user-that-configured-the-repository-no-longer-has-access", "text": "This section applies only to GitLab and Bitbucket On GitLab and Bitbucket organizations, Codacy uses SSH keys to clone your private repositories. Depending on the level of access that the user configuring the repository on Codacy has on the remote Git provider, an SSH key can be added either: Directly to the repository itself, if the user has permissions to add SSH keys to the repository To the user account, if the user only has read or commit permissions on the repository If the user that initially configured the repository on Codacy was using a user account SSH key but no longer has access to the repository on GitLab or Bitbucket: On Codacy, open your Repository Settings , tab General . Click the button Generate New Repository Key to add a new SSH key to your repository deployment keys. This is only possible if the user configuring the integration with the remote Git provider has administrator access to the repository. Otherwise, this operation will fail. Alternatively, you can do this process manually by copying the SSH key. Note If your repository is using submodules on Codacy , add a new SSH user key to your Git provider account instead. Open the tab Integrations , and refresh your GitLab or Bitbucket integration.", "title": "The user that configured the repository no longer has access"}, {"location": "faq/troubleshooting/why-arent-duplication-metrics-being-calculated/", "text": "Why aren't duplication metrics being calculated? # For performance reasons, Codacy skips the calculation of code duplication for programming languages that have more than 5000 source code files in a repository. Besides this, if Codacy fails to calculate code duplication for a specific programming language in a repository three times in a row (for example, because the tool calculating the analysis runs out of memory or times out), Codacy stops trying to analyze the metric for that language and repository. When this happens, Codacy doesn't display code duplication metrics for the affected language: The Files page on your repository displays a blank duplication value for files of the affected language. The Commits and Pull Request pages display an empty Duplication tab. The analysis logs for commits won't display a duplication analysis task for the tool corresponding to the affected language. As a workaround, if you're exceeding the maximum number of source code files: Use a Codacy configuration file to exclude source code files of the affected language from your project to decrease the number of files to be analyzed. For example, you may be able to exclude files that are automatically generated from your test suite or files belonging to dependencies that aren't maintained by your team, such as the node_modules folder for JavaScript projects. Reanalyze the last commit in the repository so that Codacy runs the code duplication analysis. If the analysis finishes but the code duplication metric wasn't calculated, follow the next steps: If you're using Codacy Self-hosted , open the Admin panel , Repositories , select the repository, tab Settings , and reset the code duplication analysis in Duplication settings . Then, reanalyze the last commit in the repository so that Codacy runs the code duplication analysis. If you're analyzing your repository locally with the Codacy Analysis CLI, consider using the flag --tool-timeout to specify a larger timeout for the execution of the tool. If you're using Codacy Cloud or if the steps above didn't solve the issue, please contact us at support@codacy.com .", "title": "Why aren't duplication metrics being calculated?"}, {"location": "faq/troubleshooting/why-arent-duplication-metrics-being-calculated/#why-arent-duplication-metrics-being-calculated", "text": "For performance reasons, Codacy skips the calculation of code duplication for programming languages that have more than 5000 source code files in a repository. Besides this, if Codacy fails to calculate code duplication for a specific programming language in a repository three times in a row (for example, because the tool calculating the analysis runs out of memory or times out), Codacy stops trying to analyze the metric for that language and repository. When this happens, Codacy doesn't display code duplication metrics for the affected language: The Files page on your repository displays a blank duplication value for files of the affected language. The Commits and Pull Request pages display an empty Duplication tab. The analysis logs for commits won't display a duplication analysis task for the tool corresponding to the affected language. As a workaround, if you're exceeding the maximum number of source code files: Use a Codacy configuration file to exclude source code files of the affected language from your project to decrease the number of files to be analyzed. For example, you may be able to exclude files that are automatically generated from your test suite or files belonging to dependencies that aren't maintained by your team, such as the node_modules folder for JavaScript projects. Reanalyze the last commit in the repository so that Codacy runs the code duplication analysis. If the analysis finishes but the code duplication metric wasn't calculated, follow the next steps: If you're using Codacy Self-hosted , open the Admin panel , Repositories , select the repository, tab Settings , and reset the code duplication analysis in Duplication settings . Then, reanalyze the last commit in the repository so that Codacy runs the code duplication analysis. If you're analyzing your repository locally with the Codacy Analysis CLI, consider using the flag --tool-timeout to specify a larger timeout for the execution of the tool. If you're using Codacy Cloud or if the steps above didn't solve the issue, please contact us at support@codacy.com .", "title": "Why aren't duplication metrics being calculated?"}, {"location": "faq/troubleshooting/why-cant-i-see-my-organization/", "text": "Why can't I see my organization? # If you can't add your organization to Codacy because it doesn't appear on the Organizations page, please try re-adding your Git provider by clicking Add provider on the Organizations page: If you still can't see your organization on Codacy, follow the steps below to check if the issue is solved: Re-add your Git provider by clicking Add provider on the Organizations page. Make sure that you have access to the organization on the Git provider using the account that you used to log in on Codacy. If you're using GitHub install and authorize Codacy on your organization . Revoke Codacy's OAuth integration with your Git provider and log in again to Codacy. If these steps don't solve the issue, please contact us at support@codacy.com .", "title": "Why can't I see my organization?"}, {"location": "faq/troubleshooting/why-cant-i-see-my-organization/#why-cant-i-see-my-organization", "text": "If you can't add your organization to Codacy because it doesn't appear on the Organizations page, please try re-adding your Git provider by clicking Add provider on the Organizations page: If you still can't see your organization on Codacy, follow the steps below to check if the issue is solved: Re-add your Git provider by clicking Add provider on the Organizations page. Make sure that you have access to the organization on the Git provider using the account that you used to log in on Codacy. If you're using GitHub install and authorize Codacy on your organization . Revoke Codacy's OAuth integration with your Git provider and log in again to Codacy. If these steps don't solve the issue, please contact us at support@codacy.com .", "title": "Why can't I see my organization?"}, {"location": "faq/troubleshooting/why-did-codacy-stop-commenting-on-pull-requests/", "text": "Why did Codacy stop commenting on pull requests? # Outdated app permissions # This section applies to Codacy Coverage on GitHub Coverage information is currently sent to GitHub by a new version of the Codacy Coverage engine, which depends on updated app permissions. If you stopped receiving coverage summaries on your pull requests, please review and accept the updated Codacy app permissions on GitHub . For more information on the rollout of the new Coverage engine, see the relevant release note . Outdated permissions or invalid SSH key # This section applies to GitLab and Bitbucket Different reasons can cause Codacy to stop analyzing and commenting on pull requests, but the most common is that the user who initially enabled the GitLab or Bitbucket integration no longer has permissions on the repository or that the SSH key is no longer valid. To fix this issue and avoid future disruptions, refresh the GitLab or Bitbucket integration on Codacy using a dedicated service account on your Git provider: Create a service account on your Git provider exclusively dedicated to integrating Codacy with your repositories. Note The service account must: Have administrator permissions on the repositories to integrate with Codacy Not be shared by other systems to ensure that Codacy doesn't hit the API rate limits of the Git provider when using this account Tip Using a dedicated service account also has the advantage of any pull request comments made by Codacy appearing as authored by the service account instead of by a regular organization member. You can name this account \"Codacy\" and use this Codacy logo as the account picture so that your pull request comments look like the following example: Log out of both your Git provider and of Codacy. Log in to Codacy using the new service account. Open your repository Settings , tab Integrations , and click the link Refresh connection to refresh the existing Git provider integration: Make sure the Git provider integration is configured as needed: Configuring the GitLab integration Configuring the Bitbucket integration See also # We no longer have access to this repository, check your SSH keys", "title": "Why did Codacy stop commenting on pull requests?"}, {"location": "faq/troubleshooting/why-did-codacy-stop-commenting-on-pull-requests/#why-did-codacy-stop-commenting-on-pull-requests", "text": "", "title": "Why did Codacy stop commenting on pull requests?"}, {"location": "faq/troubleshooting/why-did-codacy-stop-commenting-on-pull-requests/#outdated-app-permissions", "text": "This section applies to Codacy Coverage on GitHub Coverage information is currently sent to GitHub by a new version of the Codacy Coverage engine, which depends on updated app permissions. If you stopped receiving coverage summaries on your pull requests, please review and accept the updated Codacy app permissions on GitHub . For more information on the rollout of the new Coverage engine, see the relevant release note .", "title": "Outdated app permissions"}, {"location": "faq/troubleshooting/why-did-codacy-stop-commenting-on-pull-requests/#outdated-permissions", "text": "This section applies to GitLab and Bitbucket Different reasons can cause Codacy to stop analyzing and commenting on pull requests, but the most common is that the user who initially enabled the GitLab or Bitbucket integration no longer has permissions on the repository or that the SSH key is no longer valid. To fix this issue and avoid future disruptions, refresh the GitLab or Bitbucket integration on Codacy using a dedicated service account on your Git provider: Create a service account on your Git provider exclusively dedicated to integrating Codacy with your repositories. Note The service account must: Have administrator permissions on the repositories to integrate with Codacy Not be shared by other systems to ensure that Codacy doesn't hit the API rate limits of the Git provider when using this account Tip Using a dedicated service account also has the advantage of any pull request comments made by Codacy appearing as authored by the service account instead of by a regular organization member. You can name this account \"Codacy\" and use this Codacy logo as the account picture so that your pull request comments look like the following example: Log out of both your Git provider and of Codacy. Log in to Codacy using the new service account. Open your repository Settings , tab Integrations , and click the link Refresh connection to refresh the existing Git provider integration: Make sure the Git provider integration is configured as needed: Configuring the GitLab integration Configuring the Bitbucket integration", "title": "Outdated permissions or invalid SSH key"}, {"location": "faq/troubleshooting/why-did-codacy-stop-commenting-on-pull-requests/#see-also", "text": "We no longer have access to this repository, check your SSH keys", "title": "See also"}, {"location": "faq/troubleshooting/why-is-my-file-over-150-kb-missing/", "text": "Why is my file over 150 KB missing? # Codacy Cloud currently doesn't analyze files that are larger than 150 KB . Codacy doesn't display these files on the Files page , and doesn't take them into account when grading your repository. Why is there a limit? # As part of our performance improvement measures, we spent time breaking down the total time it takes to analyze a repository and found that a large percentage of time was spent on files that didn't add value to our users. Those files tend to be the biggest in the repository and are typically generated by or dependent on a third-party. It increased analysis time significantly due to the file size and even resulted in timeouts at some point, preventing the flagging of real issues. As a solution to this problem, we placed a size limit to the files that Codacy would analyze. This decreased the average analysis time and the number of timeouts, thus improving the overall performance for our users. What if I need to analyze a file that exceeds this limit? # While Codacy will ignore your file by default, you can still analyze it by running the analysis locally using the Codacy Analysis CLI . The Codacy Analysis CLI doesn't have any limitation on file size. What about Codacy Self-hosted? # By default, Codacy Self-hosted has the same limit of 150 KB as Codacy Cloud. However, in this case the limit is configurable because the resource allocation for on-premise instances is decided by each organization. To update the file size limit: Edit the value of global.workerManager.workers.config.analysis.maxFileSizeBytes in the values-production.yaml file that you used to install Codacy: global : workerManager : workers : config : analysis : maxFileSizeBytes : 150000 Apply the new configuration by performing a Helm upgrade and specifying the Codacy Self-hosted version currently installed. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "Why is my file over 150 KB missing?"}, {"location": "faq/troubleshooting/why-is-my-file-over-150-kb-missing/#why-is-my-file-over-150-kb-missing", "text": "Codacy Cloud currently doesn't analyze files that are larger than 150 KB . Codacy doesn't display these files on the Files page , and doesn't take them into account when grading your repository.", "title": "Why is my file over 150 KB missing?"}, {"location": "faq/troubleshooting/why-is-my-file-over-150-kb-missing/#why-is-there-a-limit", "text": "As part of our performance improvement measures, we spent time breaking down the total time it takes to analyze a repository and found that a large percentage of time was spent on files that didn't add value to our users. Those files tend to be the biggest in the repository and are typically generated by or dependent on a third-party. It increased analysis time significantly due to the file size and even resulted in timeouts at some point, preventing the flagging of real issues. As a solution to this problem, we placed a size limit to the files that Codacy would analyze. This decreased the average analysis time and the number of timeouts, thus improving the overall performance for our users.", "title": "Why is there a limit?"}, {"location": "faq/troubleshooting/why-is-my-file-over-150-kb-missing/#what-if-i-need-to-analyze-a-file-that-exceeds-this-limit", "text": "While Codacy will ignore your file by default, you can still analyze it by running the analysis locally using the Codacy Analysis CLI . The Codacy Analysis CLI doesn't have any limitation on file size.", "title": "What if I need to analyze a file that exceeds this limit?"}, {"location": "faq/troubleshooting/why-is-my-file-over-150-kb-missing/#what-about-codacy-self-hosted", "text": "By default, Codacy Self-hosted has the same limit of 150 KB as Codacy Cloud. However, in this case the limit is configurable because the resource allocation for on-premise instances is decided by each organization. To update the file size limit: Edit the value of global.workerManager.workers.config.analysis.maxFileSizeBytes in the values-production.yaml file that you used to install Codacy: global : workerManager : workers : config : analysis : maxFileSizeBytes : 150000 Apply the new configuration by performing a Helm upgrade and specifying the Codacy Self-hosted version currently installed. To do so execute the command used to install Codacy : Important If you're using MicroK8s you must use the file values-microk8s.yaml together with the file values-production.yaml . To do this, uncomment the last line before running the helm upgrade command below. helm upgrade ( ...options used to install Codacy... ) \\ --version \\ --values values-production.yaml \\ # --values values-microk8s.yaml", "title": "What about Codacy Self-hosted?"}, {"location": "faq/troubleshooting/why-isnt-my-public-repository-being-analyzed/", "text": "Why isn't my public repository being analyzed? # Codacy only analyzes open source repositories if the admin of the repository is a committer to that repository.", "title": "Why isn't my public repository being analyzed?"}, {"location": "faq/troubleshooting/why-isnt-my-public-repository-being-analyzed/#why-isnt-my-public-repository-being-analyzed", "text": "Codacy only analyzes open source repositories if the admin of the repository is a committer to that repository.", "title": "Why isn't my public repository being analyzed?"}, {"location": "getting-started/adding-a-codacy-badge/", "text": "Adding a Codacy badge # Add a Codacy badge to the README of your repository to display the current code quality grade or code coverage of your repository. To obtain your Codacy badge, open your repository Settings , tab General , select the markup language, and copy the generated code to your README file. You can also add a badge for your coverage if you have set up code coverage for your repository. To display the grade or code coverage information of a different branch analyzed by Codacy, append ?branch= to the URL of the badge. For example: https://app.codacy.com/project/badge/Grade/cba8fd0874ac4f569f4f880e473cbac9?branch=dev Fixing your Codacy badge # The Codacy badges for your repository may become unavailable or grayed out if the analysis or code coverage information for the last commit isn't available, or if you renamed or re-added your repository on Codacy: To fix each badge: Reanalyze the branch associated with the code quality badge Make sure that you're generating and uploading code coverage reports for all the commits in the branch associated with the coverage badge If these steps don't fix your Codacy badges it can mean that the badges are no longer valid. In this case, repeat the steps above to replace the existing badges with new ones.", "title": "Adding a Codacy badge"}, {"location": "getting-started/adding-a-codacy-badge/#adding-a-codacy-badge", "text": "Add a Codacy badge to the README of your repository to display the current code quality grade or code coverage of your repository. To obtain your Codacy badge, open your repository Settings , tab General , select the markup language, and copy the generated code to your README file. You can also add a badge for your coverage if you have set up code coverage for your repository. To display the grade or code coverage information of a different branch analyzed by Codacy, append ?branch= to the URL of the badge. For example: https://app.codacy.com/project/badge/Grade/cba8fd0874ac4f569f4f880e473cbac9?branch=dev", "title": "Adding a Codacy badge"}, {"location": "getting-started/adding-a-codacy-badge/#fixing-your-codacy-badge", "text": "The Codacy badges for your repository may become unavailable or grayed out if the analysis or code coverage information for the last commit isn't available, or if you renamed or re-added your repository on Codacy: To fix each badge: Reanalyze the branch associated with the code quality badge Make sure that you're generating and uploading code coverage reports for all the commits in the branch associated with the coverage badge If these steps don't fix your Codacy badges it can mean that the badges are no longer valid. In this case, repeat the steps above to replace the existing badges with new ones.", "title": "Fixing your Codacy badge"}, {"location": "getting-started/codacy-quickstart/", "text": "Codacy quickstart (5 min) # Codacy is an automated code quality and coverage platform that analyzes your source code and identifies issues as you go, helping your team ship robust software by scanning over 40 programming languages, such as JavaScript, Python, Java, C#, and PHP. Check out our product demo for an overview of Codacy's main features (recorded on May 13, 2024): By integrating with your Git provider, Codacy keeps track of your team\u2019s work, analyzes relevant commits, highlights problems, suggests improvements, and protects your codebase from unwelcome changes. From organization and repository level to individual files, pull requests, and commits, Codacy monitors the following metrics across your projects: Issues : violations of a given rule, standard, convention, or best practice, from inconsistent code formatting to security risks Complexity : a measure of the number of execution paths through a program's source code Duplication : the amount of duplicated portions of code Coverage : the percentage of lines of code covered by automated tests Adding your first repository # This page is part of the following guided path: Adding your first repository Configuring your repository Integrating Codacy with your Git workflow To get started, head to codacy.com and click Start free . Then, follow these steps: Signing up Choosing an organization Adding repositories 1. Signing up # Sign up with a Git provider such as GitHub, GitLab, or Bitbucket. This links your Codacy user with your Git provider user, making it easier to add repositories to Codacy and invite your teammates. Codacy will request access to your Git provider during the authorization flow. Check the permissions that Codacy requires and why . 2. Choosing an organization # Now, you'll need to add or join the organizations that contain your repositories. The organization with the same name as your Git provider username contains your personal repositories. Read more about organizations on Codacy . To start adding your repositories, select one of the organizations. Note If you can't see the organization you're looking for, follow these troubleshooting instructions . 3. Adding repositories # Next, add the repositories that you wish to analyze. Codacy begins an initial analysis as soon as you add a repository and sets everything up to ensure your next commits on that repository are analyzed. Note You can only add repositories on Codacy if you have the necessary permissions on your Git provider . Click the repository name to navigate to the repository dashboard and see the code quality overview of your repository as soon as the initial analysis is complete: Congratulations, your new repository is ready! To explore the initial analysis results, check the Issues page . Next steps # The first analysis is based on default tool and pattern configurations. It's now important that you configure your repository to integrate code analysis seamlessly into your existing pipeline. See how to configure your repository to match the use cases of your team .", "title": "Codacy quickstart (5 min)"}, {"location": "getting-started/codacy-quickstart/#codacy-quickstart-5-min", "text": "Codacy is an automated code quality and coverage platform that analyzes your source code and identifies issues as you go, helping your team ship robust software by scanning over 40 programming languages, such as JavaScript, Python, Java, C#, and PHP. Check out our product demo for an overview of Codacy's main features (recorded on May 13, 2024): By integrating with your Git provider, Codacy keeps track of your team\u2019s work, analyzes relevant commits, highlights problems, suggests improvements, and protects your codebase from unwelcome changes. From organization and repository level to individual files, pull requests, and commits, Codacy monitors the following metrics across your projects: Issues : violations of a given rule, standard, convention, or best practice, from inconsistent code formatting to security risks Complexity : a measure of the number of execution paths through a program's source code Duplication : the amount of duplicated portions of code Coverage : the percentage of lines of code covered by automated tests", "title": "Codacy quickstart (5 min)"}, {"location": "getting-started/codacy-quickstart/#adding-your-first-repository", "text": "This page is part of the following guided path: Adding your first repository Configuring your repository Integrating Codacy with your Git workflow To get started, head to codacy.com and click Start free . Then, follow these steps: Signing up Choosing an organization Adding repositories", "title": "Adding your first repository"}, {"location": "getting-started/codacy-quickstart/#signing-up", "text": "Sign up with a Git provider such as GitHub, GitLab, or Bitbucket. This links your Codacy user with your Git provider user, making it easier to add repositories to Codacy and invite your teammates. Codacy will request access to your Git provider during the authorization flow. Check the permissions that Codacy requires and why .", "title": "1. Signing up"}, {"location": "getting-started/codacy-quickstart/#choosing-organization", "text": "Now, you'll need to add or join the organizations that contain your repositories. The organization with the same name as your Git provider username contains your personal repositories. Read more about organizations on Codacy . To start adding your repositories, select one of the organizations. Note If you can't see the organization you're looking for, follow these troubleshooting instructions .", "title": "2. Choosing an organization"}, {"location": "getting-started/codacy-quickstart/#adding-repositories", "text": "Next, add the repositories that you wish to analyze. Codacy begins an initial analysis as soon as you add a repository and sets everything up to ensure your next commits on that repository are analyzed. Note You can only add repositories on Codacy if you have the necessary permissions on your Git provider . Click the repository name to navigate to the repository dashboard and see the code quality overview of your repository as soon as the initial analysis is complete: Congratulations, your new repository is ready! To explore the initial analysis results, check the Issues page .", "title": "3. Adding repositories"}, {"location": "getting-started/codacy-quickstart/#next-steps", "text": "The first analysis is based on default tool and pattern configurations. It's now important that you configure your repository to integrate code analysis seamlessly into your existing pipeline. See how to configure your repository to match the use cases of your team .", "title": "Next steps"}, {"location": "getting-started/configuring-your-repository/", "text": "Configuring your repository # This page is part of the following guided path: Adding your first repository Configuring your repository Integrating Codacy with your Git workflow Once you've added your first repository, it's important that you configure Codacy's analysis tools to match the use cases of your team, such as configuring any coding conventions and best practices that your team may already be following or that you want to promote. It's also critical to review the configurations to avoid reporting false positives or any other issues that don't bring value to your team, which can introduce unwanted delays to the development process. You can optionally add coverage reports to detail how much of your code is covered by tests and unify your quality and coverage pipelines. You can generate coverage reports and upload them to Codacy using a range of options, such as CI/CD integration, CLI, Docker, GitHub action, and more. To configure your repository, follow these steps: Ignoring files Configuring code patterns Adding coverage reports (optional) 1. Ignoring files # Ignore any files and directories that aren't relevant for the Codacy analysis, such as generated code or any third-party libraries included in your repositories. 2. Configuring code patterns # Configure the tools and code patterns that Codacy uses to analyze your repository. If security is important for your team, review the security and risk management dashboard to ensure that your configuration detects potential security issues. Tip To ensure that multiple repositories consistently follow the same global tool and code pattern configurations, use an organization coding standard . 3. Adding coverage to your repository (optional) # If you want to use code coverage to block merging pull requests that don't meet your quality standards, make sure that you add coverage to your repository . It's important that you set up coverage beforehand because Codacy can only report the coverage status for pull requests after receiving reports for the last commits on both the pull request branch and the target branch . Next steps # Once you\u2019re satisfied with your setup, integrate Codacy with your Git workflow to flag potential issues, block problematic pull requests, and display other useful suggestions directly on your Git provider. Tip To showcase the current code quality grade and coverage, add a Codacy badge to your repository .", "title": "Configuring your repository"}, {"location": "getting-started/configuring-your-repository/#configuring-your-repository", "text": "This page is part of the following guided path: Adding your first repository Configuring your repository Integrating Codacy with your Git workflow Once you've added your first repository, it's important that you configure Codacy's analysis tools to match the use cases of your team, such as configuring any coding conventions and best practices that your team may already be following or that you want to promote. It's also critical to review the configurations to avoid reporting false positives or any other issues that don't bring value to your team, which can introduce unwanted delays to the development process. You can optionally add coverage reports to detail how much of your code is covered by tests and unify your quality and coverage pipelines. You can generate coverage reports and upload them to Codacy using a range of options, such as CI/CD integration, CLI, Docker, GitHub action, and more. To configure your repository, follow these steps: Ignoring files Configuring code patterns Adding coverage reports (optional)", "title": "Configuring your repository"}, {"location": "getting-started/configuring-your-repository/#ignoring-files", "text": "Ignore any files and directories that aren't relevant for the Codacy analysis, such as generated code or any third-party libraries included in your repositories.", "title": "1. Ignoring files"}, {"location": "getting-started/configuring-your-repository/#configuring-code-patterns", "text": "Configure the tools and code patterns that Codacy uses to analyze your repository. If security is important for your team, review the security and risk management dashboard to ensure that your configuration detects potential security issues. Tip To ensure that multiple repositories consistently follow the same global tool and code pattern configurations, use an organization coding standard .", "title": "2. Configuring code patterns"}, {"location": "getting-started/configuring-your-repository/#adding-coverage", "text": "If you want to use code coverage to block merging pull requests that don't meet your quality standards, make sure that you add coverage to your repository . It's important that you set up coverage beforehand because Codacy can only report the coverage status for pull requests after receiving reports for the last commits on both the pull request branch and the target branch .", "title": "3. Adding coverage to your repository (optional)"}, {"location": "getting-started/configuring-your-repository/#next-steps", "text": "Once you\u2019re satisfied with your setup, integrate Codacy with your Git workflow to flag potential issues, block problematic pull requests, and display other useful suggestions directly on your Git provider. Tip To showcase the current code quality grade and coverage, add a Codacy badge to your repository .", "title": "Next steps"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/", "text": "Integrating Codacy with IntelliJ IDEs # The Codacy IntelliJ plugin is an open-source plugin for IntelliJ IDEs that lets you review the result of the Codacy analysis for a pull request, get the full list of problems found, and navigate to any Quality issue that you want to review and fix. To use this plugin you need a Codacy account Interface overview # The main view of the Codacy IntelliJ plugin provides a summary of the code quality and coverage changes introduced by the pull request of the currently checked-out branch. In the main view, you can find the following information: The Quality status of the pull request, either up to standards or not up to standards, based on the Quality gates set for the repository. Any Quality issues introduced or fixed by the pull request. These are the same issues you find in the Quality Issues tabs in the Codacy app and are also visible in IntelliJ's Problems tab. When this item is expanded, the number next to each file name is the total number of Quality issues that the pull request adds to that file. The diff coverage introduced by the pull request. This is the same value you find in the Pull request coverage overview panel in the Codacy app. The percentage next to each file name is the coverage variation for that file. Sequences of duplicate code (clones) introduced by the pull request. These are the same ones you find in the Quality Duplication tabs in the Codacy app. Variations in code complexity introduced by the pull request. Installing the Codacy IntelliJ plugin # The Codacy IntelliJ plugin is compatible with IntelliJ IDEA (Ultimate, Community), Android Studio, and Aqua. Make sure that the repository you\u2019re working on is analyzed by Codacy and that you have a repository read role or higher. Tip If this is your first time using Codacy, see how to add and analyze your first repository . Install the plugin from the JetBrains Marketplace or through the plugin settings panel in your IntelliJ IDE. Getting pull request quality and coverage data # To see Codacy quality and coverage data for an open pull request, follow these steps: Open the repository directory in your IntelliJ IDE. Note If the repository isn't on Codacy yet, add it to Codacy first. Open the main view by clicking the Codacy logo in the left tool window bar. If you\u2019re not signed in, click the Sign in button to authorize IntelliJ on Codacy. Check out the pull request of interest. After completing these steps, the main view shows the result of the latest Codacy analysis for the pull request. Reviewing pull request issues # In the Problems tool window , Codacy displays the same Quality issues you find in the main view and lets you navigate to the exact line of code where the issue was found. Note Code coverage, duplicates, and complexity aren't currently shown in the Problems tool window. To review Quality issues: Open the file you want to review. You can find the list of files with issues in the main view of the Codacy plugin. Double-click the file name to open it in the editor. Open the Problems tool window (use Ctrl+6 on Windows/Linux or Cmd+6 on macOS) and select the File tab. Click the name of the issue you want to review. Hover over a highlighted issue in the code editor to view available actions and suggested quick fixes, if available. For a list of tools that support suggested fixes, see Supported languages and tools . Once you've addressed the problems in your code, push your changes to the Git provider so that Codacy analyzes the updated code. When the analysis is complete, the Codacy plugin automatically refreshes the pull request analysis result. You can also refresh the pull request data manually by clicking the Refresh Pull Request button in the main view. See also # Troubleshooting the Codacy IntelliJ plugin", "title": "Integrating Codacy with IntelliJ IDEs"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/#integrating-codacy-with-intellij-ides", "text": "The Codacy IntelliJ plugin is an open-source plugin for IntelliJ IDEs that lets you review the result of the Codacy analysis for a pull request, get the full list of problems found, and navigate to any Quality issue that you want to review and fix. To use this plugin you need a Codacy account", "title": "Integrating Codacy with IntelliJ IDEs"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/#interface-overview", "text": "The main view of the Codacy IntelliJ plugin provides a summary of the code quality and coverage changes introduced by the pull request of the currently checked-out branch. In the main view, you can find the following information: The Quality status of the pull request, either up to standards or not up to standards, based on the Quality gates set for the repository. Any Quality issues introduced or fixed by the pull request. These are the same issues you find in the Quality Issues tabs in the Codacy app and are also visible in IntelliJ's Problems tab. When this item is expanded, the number next to each file name is the total number of Quality issues that the pull request adds to that file. The diff coverage introduced by the pull request. This is the same value you find in the Pull request coverage overview panel in the Codacy app. The percentage next to each file name is the coverage variation for that file. Sequences of duplicate code (clones) introduced by the pull request. These are the same ones you find in the Quality Duplication tabs in the Codacy app. Variations in code complexity introduced by the pull request.", "title": "Interface overview"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/#installing-the-codacy-intellij-plugin", "text": "The Codacy IntelliJ plugin is compatible with IntelliJ IDEA (Ultimate, Community), Android Studio, and Aqua. Make sure that the repository you\u2019re working on is analyzed by Codacy and that you have a repository read role or higher. Tip If this is your first time using Codacy, see how to add and analyze your first repository . Install the plugin from the JetBrains Marketplace or through the plugin settings panel in your IntelliJ IDE.", "title": "Installing the Codacy IntelliJ plugin"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/#getting-pull-request-quality-and-coverage-data", "text": "To see Codacy quality and coverage data for an open pull request, follow these steps: Open the repository directory in your IntelliJ IDE. Note If the repository isn't on Codacy yet, add it to Codacy first. Open the main view by clicking the Codacy logo in the left tool window bar. If you\u2019re not signed in, click the Sign in button to authorize IntelliJ on Codacy. Check out the pull request of interest. After completing these steps, the main view shows the result of the latest Codacy analysis for the pull request.", "title": "Getting pull request quality and coverage data"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/#reviewing-pull-request-issues", "text": "In the Problems tool window , Codacy displays the same Quality issues you find in the main view and lets you navigate to the exact line of code where the issue was found. Note Code coverage, duplicates, and complexity aren't currently shown in the Problems tool window. To review Quality issues: Open the file you want to review. You can find the list of files with issues in the main view of the Codacy plugin. Double-click the file name to open it in the editor. Open the Problems tool window (use Ctrl+6 on Windows/Linux or Cmd+6 on macOS) and select the File tab. Click the name of the issue you want to review. Hover over a highlighted issue in the code editor to view available actions and suggested quick fixes, if available. For a list of tools that support suggested fixes, see Supported languages and tools . Once you've addressed the problems in your code, push your changes to the Git provider so that Codacy analyzes the updated code. When the analysis is complete, the Codacy plugin automatically refreshes the pull request analysis result. You can also refresh the pull request data manually by clicking the Refresh Pull Request button in the main view.", "title": "Reviewing pull request issues"}, {"location": "getting-started/integrating-codacy-with-intellij-ides/#see-also", "text": "Troubleshooting the Codacy IntelliJ plugin", "title": "See also"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/", "text": "Integrating Codacy with Visual Studio Code # The Codacy Visual Studio Code extension is an open-source project that enables developers to review directly in VS Code the result of Codacy analysis for the pull requests they\u2019re working on. Use this extension to get the full list of problems found by Codacy for a pull request and navigate to any Quality issue that you want to review and fix. To use this extension you need a Codacy account Interface overview # The main view of the extension displays information about the code quality and coverage changes introduced by the pull requests you're working on, as well as the quality status of analyzed branches. This information is grouped into three panels: Pull request status Open pull requests Analyzed branch Status tab # The Pull request status tab displays the following information for the pull request of the currently checked-out branch: The Quality status of the pull request, either up to standards or not up to standards, based on the Quality gates set for the repository. Any Quality issues introduced or fixed by the pull request. These are the same issues you find in the Quality Issues tabs in the Codacy app and are also visible in VS Code's Problems tab. When this item is expanded, the number next to each file name is the total number of Quality issues that the pull request adds to or removes from that file. The number farther to the right, added by VS Code, is the total number of problems in that file, which may or may not be Quality issues from Codacy. If there are any Medium or Critical Quality issues, the file name is also highlighted in yellow (Medium) or red (Critical). The diff coverage and coverage variation introduced by the pull request. These are the same values you find in the Pull request coverage overview panel in the Codacy app. When this item is expanded, the percentage next to each file name is the coverage variation for that file. You can toggle on/off the inline coverage to see/hide the line-by-line diff coverage and a comparison of the old and new file content for each modified file - uncovered lines (red), covered lines with its test coverage count (green), and non-coverable lines (no background). These are the same details you find in the coverage Diff tab of the pull request in the Codacy app. Sequences of duplicate code (clones) introduced by the pull request. These are the same ones you find in the Quality Duplication tabs in the Codacy app. Variations in code complexity introduced by the pull request. Open pull requests tab # The Open Pull Requests tab lists all open pull requests for the repository, including the following information for each: The status of the pull request, which is visible on hover: Analyzing, if Codacy is analyzing the branch. Up to standards or not up to standards, based on the Quality gates set for the repository. The author of the pull request. The source and target branches of the pull request. Any Quality issues introduced or fixed by the pull request. These are the same issues you find in the Quality Issues tabs in the Codacy app. Sequences of duplicate code (clones) introduced by the pull request. These are the same ones you find in the Quality Duplication tabs in the Codacy app. Variations in code complexity introduced by the pull request. This is the same value you find on the Pull request quality overview in the Codacy app. Analyzed branch tab # The Analyzed Branch tab appears if you switch to an analyzed branch that doesn't have an open pull request, such as the main or master branch. This tab shows an overview of the Quality issues found in that branch, grouped by recently added, introduced by the current user, issue category, and issue severity. See how to manage the analysis of your repository's branches . Installing the Codacy VS Code extension # Make sure that the repository you\u2019re working on is analyzed by Codacy and that you have a repository read role or higher. Tip If this is your first time using Codacy, see how to add and analyze your first repository . Install the extension from the Visual Studio Marketplace or through the Extensions view in VS Code . Alternatively, you can install it manually by downloading the latest release as a VSIX package . Getting pull request quality and coverage data # To see Codacy quality and coverage data for an open pull request, follow these steps: Open the repository directory in VS Code. Note If the repository isn't on Codacy yet, add it to Codacy first. Open the main view by clicking the Codacy logo in the activity bar or the Codacy tab in the status bar. If you\u2019re not signed in, click the Sign in button to authorize VS Code on Codacy. Tip To access a complete list of Codacy commands, open the VS Code command palette ( Ctrl+Shift+P on Windows/Linux or Cmd+Shift+P on macOS) and type \"Codacy\". Check out the pull request of interest. You can do it either manually or from the Open Pull Requests tab, by clicking the arrow button or using the contextual right-click menu. After completing these steps, the main view shows the result of the latest Codacy analysis for the pull request. The VS Code Problems tab lists the Quality issues found. Reviewing pull request issues # In the Problems tab , Codacy displays the same Quality issues you find in the Status tab and lets you navigate to the exact line of code where the issue was found. Note Code coverage, duplicates, and complexity aren't currently shown in the Problems tab. To review Quality issues: Open the Problems tab (use Ctrl+Shift+M on Windows/Linux or Cmd+Shift+M on macOS). Click the name of the issue you want to review. Hover over a highlighted issue in the code editor to view available actions and suggested quick fixes (if available). For a list of tools that support quick fixes, see Supported languages and tools . Once you've addressed the problems in your code, push your changes to the Git provider so that Codacy analyzes the updated code. When the analysis is complete, the Codacy extension automatically refreshes the pull request analysis result. You can also refresh the pull request data manually by clicking the Refresh Pull Request button in the main view. See also # Troubleshooting the Codacy VS Code extension", "title": "Integrating Codacy with Visual Studio Code"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/#integrating-codacy-with-visual-studio-code", "text": "The Codacy Visual Studio Code extension is an open-source project that enables developers to review directly in VS Code the result of Codacy analysis for the pull requests they\u2019re working on. Use this extension to get the full list of problems found by Codacy for a pull request and navigate to any Quality issue that you want to review and fix. To use this extension you need a Codacy account", "title": "Integrating Codacy with Visual Studio Code"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/#interface-overview", "text": "The main view of the extension displays information about the code quality and coverage changes introduced by the pull requests you're working on, as well as the quality status of analyzed branches. This information is grouped into three panels: Pull request status Open pull requests Analyzed branch", "title": "Interface overview"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/#installing-the-codacy-vs-code-extension", "text": "Make sure that the repository you\u2019re working on is analyzed by Codacy and that you have a repository read role or higher. Tip If this is your first time using Codacy, see how to add and analyze your first repository . Install the extension from the Visual Studio Marketplace or through the Extensions view in VS Code . Alternatively, you can install it manually by downloading the latest release as a VSIX package .", "title": "Installing the Codacy VS Code extension"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/#getting-pull-request-quality-and-coverage-data", "text": "To see Codacy quality and coverage data for an open pull request, follow these steps: Open the repository directory in VS Code. Note If the repository isn't on Codacy yet, add it to Codacy first. Open the main view by clicking the Codacy logo in the activity bar or the Codacy tab in the status bar. If you\u2019re not signed in, click the Sign in button to authorize VS Code on Codacy. Tip To access a complete list of Codacy commands, open the VS Code command palette ( Ctrl+Shift+P on Windows/Linux or Cmd+Shift+P on macOS) and type \"Codacy\". Check out the pull request of interest. You can do it either manually or from the Open Pull Requests tab, by clicking the arrow button or using the contextual right-click menu. After completing these steps, the main view shows the result of the latest Codacy analysis for the pull request. The VS Code Problems tab lists the Quality issues found.", "title": "Getting pull request quality and coverage data"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/#reviewing-pull-request-issues", "text": "In the Problems tab , Codacy displays the same Quality issues you find in the Status tab and lets you navigate to the exact line of code where the issue was found. Note Code coverage, duplicates, and complexity aren't currently shown in the Problems tab. To review Quality issues: Open the Problems tab (use Ctrl+Shift+M on Windows/Linux or Cmd+Shift+M on macOS). Click the name of the issue you want to review. Hover over a highlighted issue in the code editor to view available actions and suggested quick fixes (if available). For a list of tools that support quick fixes, see Supported languages and tools . Once you've addressed the problems in your code, push your changes to the Git provider so that Codacy analyzes the updated code. When the analysis is complete, the Codacy extension automatically refreshes the pull request analysis result. You can also refresh the pull request data manually by clicking the Refresh Pull Request button in the main view.", "title": "Reviewing pull request issues"}, {"location": "getting-started/integrating-codacy-with-visual-studio-code/#see-also", "text": "Troubleshooting the Codacy VS Code extension", "title": "See also"}, {"location": "getting-started/integrating-codacy-with-your-git-workflow/", "text": "Integrating Codacy with your Git workflow # This page is part of the following guided path: Adding your first repository Configuring your repository Integrating Codacy with your Git workflow Once you've configured your repository to best match your use case, integrate Codacy with your Git workflow to display analysis results and code coverage as status checks on your pull requests. In particular, you can configure quality gates to block merging pull requests that don't meet the quality standards of your team. This ensures the quality of the changes to your codebase, preventing the introduction of security issues and untested code. To integrate Codacy with your Git workflow, follow these steps: Configuring the quality gate rules Configuring the Git provider integration Blocking merging pull requests (optional) 1. Configuring the quality gate rules # Review and adjust the quality gates of your repository to decide which pull requests should fail the Codacy quality gate. Tip The default quality gate rules are designed to help maintain the current code quality of your repository. In particular, the default value for the coverage rule might be demanding. Depending on factors such as the current code quality of your repository and the maturity of your team practices, consider the balance between implementing stricter quality gates and the possibility of delaying or blocking the development progress. Codacy generally recommends that on a first stage you configure rules that focus on stopping new critical issues from entering your code base, such as: High severity issues Security issues Considerable drops in code coverage Important If you want to use code coverage to block merging pull requests that don't meet your standards, make sure that you enable the rule Diff coverage is under or Coverage variation is under . This is required for Codacy to report the coverage status directly on your pull requests. 2. Configuring the Git provider integration # Make sure you enable the option Status checks ( GitHub ) or Pull request status ( GitLab and Bitbucket ). Tip Configure the default Git provider integration settings that Codacy applies to new repositories to help ensure that all new repositories have the same settings. 3. Blocking merging pull requests (optional) # Once you've tested out Codacy for a while and you're happy with the level of feedback provided, you can decide to enforce the quality gates and use Codacy to block merging pull requests on your Git provider. This is the best way to protect your code from unwelcome changes and fully integrates code quality and coverage analysis into your development pipeline. Important To eliminate any false positives that could inadvertently block the work of your team, it's important that before activating this feature you: Validate that Codacy is reporting the intended status on your pull requests Double check you repository's tool and code pattern settings and quality gate settings Follow the instructions from your Git provider to block merging pull requests if they don't pass the Codacy status check: GitHub: set Codacy as a required status check GitLab: only allow merge requests to be merged if the pipeline succeeds Bitbucket: configure Bitbucket to prevent a merge with unresolved merge checks You're all set! \ud83c\udf89 # Congratulations! You've successfully integrated and set up your first repository.", "title": "Integrating Codacy with your Git workflow"}, {"location": "getting-started/integrating-codacy-with-your-git-workflow/#integrating-codacy-with-your-git-workflow", "text": "This page is part of the following guided path: Adding your first repository Configuring your repository Integrating Codacy with your Git workflow Once you've configured your repository to best match your use case, integrate Codacy with your Git workflow to display analysis results and code coverage as status checks on your pull requests. In particular, you can configure quality gates to block merging pull requests that don't meet the quality standards of your team. This ensures the quality of the changes to your codebase, preventing the introduction of security issues and untested code. To integrate Codacy with your Git workflow, follow these steps: Configuring the quality gate rules Configuring the Git provider integration Blocking merging pull requests (optional)", "title": "Integrating Codacy with your Git workflow"}, {"location": "getting-started/integrating-codacy-with-your-git-workflow/#configuring-gate", "text": "Review and adjust the quality gates of your repository to decide which pull requests should fail the Codacy quality gate. Tip The default quality gate rules are designed to help maintain the current code quality of your repository. In particular, the default value for the coverage rule might be demanding. Depending on factors such as the current code quality of your repository and the maturity of your team practices, consider the balance between implementing stricter quality gates and the possibility of delaying or blocking the development progress. Codacy generally recommends that on a first stage you configure rules that focus on stopping new critical issues from entering your code base, such as: High severity issues Security issues Considerable drops in code coverage Important If you want to use code coverage to block merging pull requests that don't meet your standards, make sure that you enable the rule Diff coverage is under or Coverage variation is under . This is required for Codacy to report the coverage status directly on your pull requests.", "title": "1. Configuring the quality gate rules"}, {"location": "getting-started/integrating-codacy-with-your-git-workflow/#git-provider-integration", "text": "Make sure you enable the option Status checks ( GitHub ) or Pull request status ( GitLab and Bitbucket ). Tip Configure the default Git provider integration settings that Codacy applies to new repositories to help ensure that all new repositories have the same settings.", "title": "2. Configuring the Git provider integration"}, {"location": "getting-started/integrating-codacy-with-your-git-workflow/#blocking-pull-requests", "text": "Once you've tested out Codacy for a while and you're happy with the level of feedback provided, you can decide to enforce the quality gates and use Codacy to block merging pull requests on your Git provider. This is the best way to protect your code from unwelcome changes and fully integrates code quality and coverage analysis into your development pipeline. Important To eliminate any false positives that could inadvertently block the work of your team, it's important that before activating this feature you: Validate that Codacy is reporting the intended status on your pull requests Double check you repository's tool and code pattern settings and quality gate settings Follow the instructions from your Git provider to block merging pull requests if they don't pass the Codacy status check: GitHub: set Codacy as a required status check GitLab: only allow merge requests to be merged if the pipeline succeeds Bitbucket: configure Bitbucket to prevent a merge with unresolved merge checks", "title": "3. Blocking merging pull requests (optional)"}, {"location": "getting-started/integrating-codacy-with-your-git-workflow/#youre-all-set", "text": "Congratulations! You've successfully integrated and set up your first repository.", "title": "You're all set! \ud83c\udf89"}, {"location": "getting-started/supported-languages-and-tools/", "text": "Supported languages and tools # Codacy uses industry-leading tools to perform automatic static code analysis over 40 supported languages: For programming languages , Codacy provides static analysis as well as code duplication, code complexity, secret detection, dependency vulnerability scanning, and code coverage metrics for key languages. For cloud infrastructure-as-code platforms , Codacy provides static analysis and secret detection to enforce security and compliance best practices. The table below lists all languages that Codacy supports and the corresponding tools that Codacy uses to analyze your source code. Besides this, Codacy uses cloc to calculate the source lines of code for all supported languages and supports multiple code coverage report formats . Important Codacy runs security and other analysis tools when code changes are pushed to your repositories. These tools don't scan code for issues continuously. Language Static analysis Suggested fixes Secret detection Dependency vulnerability scanning Duplication Complexity Apex PMD , Semgrep 1 - Semgrep - - - AsyncAPI Spectral - - - - - AWS CloudFormation Checkov - Checkov , Semgrep 2 , Trivy 2 - - - Azure Resource Manager Templates Checkov - - - - - C Clang-Tidy 3 , Cppcheck , Flawfinder , Semgrep 1 Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans conan.lock (Conan) PMD CPD - C++ Clang-Tidy 3 , Cppcheck 4 , Flawfinder , Semgrep 1 - Semgrep , Trivy Trivy , scans conan.lock (Conan) PMD CPD - C# Semgrep 1 , SonarC# Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans .deps.json (.Net), packages.lock.json (NuGet) PMD CPD SonarC# CoffeeScript CoffeeLint - - - jscpd - Crystal Ameba - - - - - CSS Stylelint - - - - - Dart dartanalyzer 5 - Trivy Trivy , scans pubspec.lock jscpd - Dockerfile Hadolint , Semgrep 1 Semgrep \ud83d\udd27 Semgrep , Trivy - - - Elixir Credo , Semgrep 1 - Trivy Trivy , scans mix.lock (Mix) jscpd - GitHub Actions Semgrep 1 - Semgrep , Trivy - - - Go aligncheck 3 , deadcode 3 , Gosec 3 , Revive , Semgrep 1 , Staticcheck 3 Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans go.mod PMD CPD Gocyclo Groovy CodeNarc - - - jscpd - Helm - - Semgrep 2 , Trivy 2 - - - Java Checkstyle , PMD , Semgrep 1 , SpotBugs 3 Semgrep \ud83d\udd27 PMD , Semgrep , Trivy Trivy , scans pom.xml and gradle.lockfile PMD CPD PMD 6 JavaScript ESLint , PMD , Semgrep 1 ESLint \ud83d\udd27 Semgrep , Trivy Trivy , scans package.json and package-lock.json (npm), yarn.lock (Yarn) PMD CPD ESLint 6 JSON Jackson Linter - Checkov , Trivy - - - JSP PMD - - - - - Kotlin detekt , Semgrep 1 - Semgrep Trivy , scans pom.xml and gradle.lockfile jscpd detekt Kubernetes Checkov , Semgrep 2 Semgrep \ud83d\udd27 Checkov , Semgrep 2 , Trivy 2 - - - Less Stylelint - - - - - Markdown remark-lint , markdownlint markdownlint \ud83d\udd27 - - - - Objective-C Clang-Tidy 3 - - - jscpd - OpenAPI Spectral - - - - - PHP PHP_CodeSniffer , PHP Mess Detector , Semgrep 1 - Semgrep , Trivy Trivy , scans composer.lock (Composer) PHPCPD PHP Depend PL/SQL PMD - - - - - PostgreSQL SQLint - - - - - PowerShell PSScriptAnalyser - - - - - Python Bandit , Prospector , Pylint , Semgrep 1 Semgrep \ud83d\udd27 Bandit , Prospector , Semgrep , Trivy Trivy , scans requirements.txt (pip), Pipfile.lock (pipenv), poetry.lock (Poetry) PMD CPD Radon Ruby Brakeman 7 , RuboCop , Semgrep 1 Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans Gemfile.lock (Bundler) Flay RuboCop 6 Rust Semgrep 1 - Semgrep , Trivy Trivy , scans Cargo.lock (Cargo) jscpd - Sass Stylelint - - - - - Scala Codacy Scalameta Pro , Scalastyle , Semgrep 1 , SpotBugs 3 - Semgrep , Trivy Trivy , scans build.sbt.lock (sbt) 9 PMD CPD Scalastyle , Scala 2 compiler and standard library Serverless Framework Checkov - - - - - Shell ShellCheck , Semgrep 1 - Semgrep - - - Swift Semgrep 1 , SwiftLint - Semgrep , Trivy Trivy , scans Package.resolved (SwiftPM) PMD CPD SwiftLint 6 8 Terraform Checkov , Semgrep 1 - Checkov , Semgrep , Trivy - - - Transact-SQL TSQLLint - - - - - TypeScript ESLint , Semgrep 1 ESLint \ud83d\udd27 Semgrep , Trivy Trivy , scans package.json and package-lock.json (npm), yarn.lock (Yarn) jscpd ESLint 6 Unity Unity Roslyn Analyzers 3 - - - - - Velocity PMD - - - - - Visual Basic SonarVB - - - jscpd - Visualforce PMD - - - - - XML PMD - Trivy - - - XSL PMD - - - - - YAML - - Trivy - - - Docker images of supported tools # Codacy adds support for new languages and tools by using a Docker image to run each tool . The following table lists the Codacy GitHub repositories corresponding to each supported tool. Use these repositories to check the extra plugins supported by each tool or to submit GitHub issues related to each tool. To learn more about the tool versions used by Codacy, see the latest release notes . Tool name Codacy GitHub repository aligncheck 3 codacy/codacy-aligncheck Ameba codacy/codacy-ameba Bandit codacy/codacy-bandit Brakeman 7 codacy/codacy-brakeman Checkov codacy/codacy-checkov Checkstyle codacy/codacy-checkstyle Clang-Tidy 3 codacy/codacy-clang-tidy Codacy Scalameta Pro codacy/codacy-scalameta CodeNarc codacy/codacy-codenarc CoffeeLint codacy/codacy-coffeelint Cppcheck 4 codacy/codacy-cppcheck Credo codacy/codacy-credo dartanalyzer 5 codacy/codacy-dartanalyzer deadcode 3 codacy/codacy-deadcode detekt codacy/codacy-detekt ESLint 6 codacy/codacy-eslint Flawfinder codacy/codacy-flawfinder Gosec 3 codacy/codacy-gosec Hadolint codacy/codacy-hadolint Jackson Linter codacy/codacy-jackson-linter markdownlint codacy/codacy-markdownlint PHP_CodeSniffer codacy/codacy-codesniffer PHP Mess Detector codacy/codacy-phpmd PMD 6 codacy/codacy-pmd Prospector codacy/codacy-prospector PSScriptAnalyser codacy/codacy-psscriptanalyzer Pylint codacy/codacy-pylint-python3 remark-lint codacy/codacy-remark-lint Revive codacy/codacy-gorevive RuboCop 6 codacy/codacy-rubocop Scalastyle codacy/codacy-scalastyle Semgrep 1 codacy/codacy-semgrep ShellCheck codacy/codacy-shellcheck SonarC# codacy/codacy-sonar-csharp SonarVB codacy/codacy-sonar-visual-basic Spectral codacy/codacy-spectral SpotBugs 3 codacy/codacy-spotbugs SQLint codacy/codacy-sqlint Staticcheck 3 codacy/codacy-staticcheck Stylelint codacy/codacy-stylelint SwiftLint 6 8 codacy/codacy-swiftlint Trivy codacy/codacy-trivy TSQLLint codacy/codacy-tsqllint Unity Roslyn Analyzers 3 codacy/codacy-roslyn 1 : Semgrep supports additional security rules when signing up for Semgrep Pro . This tool doesn't support custom file extensions . 2 : Currently, only YAML file scanning is supported on this platform. 3 : Supported as a client-side tool . 4 : Currently, Cppcheck only supports checking the MISRA guidelines for C . 5 : Currently, Codacy only supports including the packages lints and flutter_lints on dartanalyzer configuration files. 6 : Doesn't calculate the number of methods and the complexity per method for each file. 7 : Due to licensing limitations, Codacy doesn't support the latest version of Brakeman. To analyze your Ruby code for the latest security vulnerabilities, use Semgrep , which provides comprehensive and up-to-date security scanning. 8 : Supports reporting warnings or errors on functions above specific complexity thresholds. Enable the rule Cyclomatic Complexity on the Code patterns page , or use a configuration file to customize the thresholds. 9 : Requires the sbt-dependency-lock plugin for generating the lockfile. \ud83d\udd27 : Supports suggesting fixes for identified issues. See also # Codacy quickstart (5 min) Client-side tools Which metrics does Codacy calculate?", "title": "Supported languages and tools"}, {"location": "getting-started/supported-languages-and-tools/#supported-languages-and-tools", "text": "Codacy uses industry-leading tools to perform automatic static code analysis over 40 supported languages: For programming languages , Codacy provides static analysis as well as code duplication, code complexity, secret detection, dependency vulnerability scanning, and code coverage metrics for key languages. For cloud infrastructure-as-code platforms , Codacy provides static analysis and secret detection to enforce security and compliance best practices. The table below lists all languages that Codacy supports and the corresponding tools that Codacy uses to analyze your source code. Besides this, Codacy uses cloc to calculate the source lines of code for all supported languages and supports multiple code coverage report formats . Important Codacy runs security and other analysis tools when code changes are pushed to your repositories. These tools don't scan code for issues continuously. Language Static analysis Suggested fixes Secret detection Dependency vulnerability scanning Duplication Complexity Apex PMD , Semgrep 1 - Semgrep - - - AsyncAPI Spectral - - - - - AWS CloudFormation Checkov - Checkov , Semgrep 2 , Trivy 2 - - - Azure Resource Manager Templates Checkov - - - - - C Clang-Tidy 3 , Cppcheck , Flawfinder , Semgrep 1 Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans conan.lock (Conan) PMD CPD - C++ Clang-Tidy 3 , Cppcheck 4 , Flawfinder , Semgrep 1 - Semgrep , Trivy Trivy , scans conan.lock (Conan) PMD CPD - C# Semgrep 1 , SonarC# Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans .deps.json (.Net), packages.lock.json (NuGet) PMD CPD SonarC# CoffeeScript CoffeeLint - - - jscpd - Crystal Ameba - - - - - CSS Stylelint - - - - - Dart dartanalyzer 5 - Trivy Trivy , scans pubspec.lock jscpd - Dockerfile Hadolint , Semgrep 1 Semgrep \ud83d\udd27 Semgrep , Trivy - - - Elixir Credo , Semgrep 1 - Trivy Trivy , scans mix.lock (Mix) jscpd - GitHub Actions Semgrep 1 - Semgrep , Trivy - - - Go aligncheck 3 , deadcode 3 , Gosec 3 , Revive , Semgrep 1 , Staticcheck 3 Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans go.mod PMD CPD Gocyclo Groovy CodeNarc - - - jscpd - Helm - - Semgrep 2 , Trivy 2 - - - Java Checkstyle , PMD , Semgrep 1 , SpotBugs 3 Semgrep \ud83d\udd27 PMD , Semgrep , Trivy Trivy , scans pom.xml and gradle.lockfile PMD CPD PMD 6 JavaScript ESLint , PMD , Semgrep 1 ESLint \ud83d\udd27 Semgrep , Trivy Trivy , scans package.json and package-lock.json (npm), yarn.lock (Yarn) PMD CPD ESLint 6 JSON Jackson Linter - Checkov , Trivy - - - JSP PMD - - - - - Kotlin detekt , Semgrep 1 - Semgrep Trivy , scans pom.xml and gradle.lockfile jscpd detekt Kubernetes Checkov , Semgrep 2 Semgrep \ud83d\udd27 Checkov , Semgrep 2 , Trivy 2 - - - Less Stylelint - - - - - Markdown remark-lint , markdownlint markdownlint \ud83d\udd27 - - - - Objective-C Clang-Tidy 3 - - - jscpd - OpenAPI Spectral - - - - - PHP PHP_CodeSniffer , PHP Mess Detector , Semgrep 1 - Semgrep , Trivy Trivy , scans composer.lock (Composer) PHPCPD PHP Depend PL/SQL PMD - - - - - PostgreSQL SQLint - - - - - PowerShell PSScriptAnalyser - - - - - Python Bandit , Prospector , Pylint , Semgrep 1 Semgrep \ud83d\udd27 Bandit , Prospector , Semgrep , Trivy Trivy , scans requirements.txt (pip), Pipfile.lock (pipenv), poetry.lock (Poetry) PMD CPD Radon Ruby Brakeman 7 , RuboCop , Semgrep 1 Semgrep \ud83d\udd27 Semgrep , Trivy Trivy , scans Gemfile.lock (Bundler) Flay RuboCop 6 Rust Semgrep 1 - Semgrep , Trivy Trivy , scans Cargo.lock (Cargo) jscpd - Sass Stylelint - - - - - Scala Codacy Scalameta Pro , Scalastyle , Semgrep 1 , SpotBugs 3 - Semgrep , Trivy Trivy , scans build.sbt.lock (sbt) 9 PMD CPD Scalastyle , Scala 2 compiler and standard library Serverless Framework Checkov - - - - - Shell ShellCheck , Semgrep 1 - Semgrep - - - Swift Semgrep 1 , SwiftLint - Semgrep , Trivy Trivy , scans Package.resolved (SwiftPM) PMD CPD SwiftLint 6 8 Terraform Checkov , Semgrep 1 - Checkov , Semgrep , Trivy - - - Transact-SQL TSQLLint - - - - - TypeScript ESLint , Semgrep 1 ESLint \ud83d\udd27 Semgrep , Trivy Trivy , scans package.json and package-lock.json (npm), yarn.lock (Yarn) jscpd ESLint 6 Unity Unity Roslyn Analyzers 3 - - - - - Velocity PMD - - - - - Visual Basic SonarVB - - - jscpd - Visualforce PMD - - - - - XML PMD - Trivy - - - XSL PMD - - - - - YAML - - Trivy - - -", "title": "Supported languages and tools"}, {"location": "getting-started/supported-languages-and-tools/#docker-images-of-supported-tools", "text": "Codacy adds support for new languages and tools by using a Docker image to run each tool . The following table lists the Codacy GitHub repositories corresponding to each supported tool. Use these repositories to check the extra plugins supported by each tool or to submit GitHub issues related to each tool. To learn more about the tool versions used by Codacy, see the latest release notes . Tool name Codacy GitHub repository aligncheck 3 codacy/codacy-aligncheck Ameba codacy/codacy-ameba Bandit codacy/codacy-bandit Brakeman 7 codacy/codacy-brakeman Checkov codacy/codacy-checkov Checkstyle codacy/codacy-checkstyle Clang-Tidy 3 codacy/codacy-clang-tidy Codacy Scalameta Pro codacy/codacy-scalameta CodeNarc codacy/codacy-codenarc CoffeeLint codacy/codacy-coffeelint Cppcheck 4 codacy/codacy-cppcheck Credo codacy/codacy-credo dartanalyzer 5 codacy/codacy-dartanalyzer deadcode 3 codacy/codacy-deadcode detekt codacy/codacy-detekt ESLint 6 codacy/codacy-eslint Flawfinder codacy/codacy-flawfinder Gosec 3 codacy/codacy-gosec Hadolint codacy/codacy-hadolint Jackson Linter codacy/codacy-jackson-linter markdownlint codacy/codacy-markdownlint PHP_CodeSniffer codacy/codacy-codesniffer PHP Mess Detector codacy/codacy-phpmd PMD 6 codacy/codacy-pmd Prospector codacy/codacy-prospector PSScriptAnalyser codacy/codacy-psscriptanalyzer Pylint codacy/codacy-pylint-python3 remark-lint codacy/codacy-remark-lint Revive codacy/codacy-gorevive RuboCop 6 codacy/codacy-rubocop Scalastyle codacy/codacy-scalastyle Semgrep 1 codacy/codacy-semgrep ShellCheck codacy/codacy-shellcheck SonarC# codacy/codacy-sonar-csharp SonarVB codacy/codacy-sonar-visual-basic Spectral codacy/codacy-spectral SpotBugs 3 codacy/codacy-spotbugs SQLint codacy/codacy-sqlint Staticcheck 3 codacy/codacy-staticcheck Stylelint codacy/codacy-stylelint SwiftLint 6 8 codacy/codacy-swiftlint Trivy codacy/codacy-trivy TSQLLint codacy/codacy-tsqllint Unity Roslyn Analyzers 3 codacy/codacy-roslyn 1 : Semgrep supports additional security rules when signing up for Semgrep Pro . This tool doesn't support custom file extensions . 2 : Currently, only YAML file scanning is supported on this platform. 3 : Supported as a client-side tool . 4 : Currently, Cppcheck only supports checking the MISRA guidelines for C . 5 : Currently, Codacy only supports including the packages lints and flutter_lints on dartanalyzer configuration files. 6 : Doesn't calculate the number of methods and the complexity per method for each file. 7 : Due to licensing limitations, Codacy doesn't support the latest version of Brakeman. To analyze your Ruby code for the latest security vulnerabilities, use Semgrep , which provides comprehensive and up-to-date security scanning. 8 : Supports reporting warnings or errors on functions above specific complexity thresholds. Enable the rule Cyclomatic Complexity on the Code patterns page , or use a configuration file to customize the thresholds. 9 : Requires the sbt-dependency-lock plugin for generating the lockfile. \ud83d\udd27 : Supports suggesting fixes for identified issues.", "title": "Docker images of supported tools"}, {"location": "getting-started/supported-languages-and-tools/#see-also", "text": "Codacy quickstart (5 min) Client-side tools Which metrics does Codacy calculate?", "title": "See also"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/", "text": "Which permissions does Codacy need from my account? # Codacy Cloud uses the OAuth protocol to handle logins and supports the following providers: GitHub Cloud GitLab Cloud Bitbucket Cloud Codacy requests only the necessary permissions from your Git provider to analyze your code and keeps your information secure . See the sections below for the detailed list of permissions that Codacy asks for depending on the provider. GitHub Cloud # If you log in with GitHub, Codacy requires the following app permissions : Scope Permissions Description Repository permissions: Checks Read & Write Codacy creates and updates check runs with the results of code analysis. Issues Read & Write Codacy can create GitHub issues from issues found during code analysis. Metadata Read-Only Codacy retrieves repository metadata, such as name, languages, collaborators and commit information. Pull requests Read & Write Codacy retrieves pull request information to display on its side. Codacy might also create comments and suggestions on the pull request, according to the results of code analysis. Webhooks Read & Write Codacy creates webhooks for code pushes and pull request events (created, merged, etc.). These events might trigger code analysis. Commit statuses Read & Write Codacy sets the status of commits according to the result of code analysis. Contents Read-Only Codacy retrieves repository contents to get installation access tokens when integrating with your repositories and clone them, and for code coverage analysis. Codacy requests this permission since September 2023. Make sure an organization owner approves Codacy GitHub App updated permissions on your GitHub organization. Organization permissions: Webhooks Read & Write Codacy creates webhooks for organization and repository events (creation, deletion, member added, etc.). Members Read-Only Codacy retrieves information about organization members and teams to enforce permissions and user management. User permissions: These permissions are granted on an individual user basis as part of the user authorization flow. They will be also be displayed during account installation for transparency. Email addresses Read-Only Codacy retrieves the user's email addresses to enforce which commits are eligible for analysis. GitLab Cloud # If you sign up with GitLab Cloud, Codacy requires the following permissions/scopes : Scope Description api Codacy uses GitLab's API to read and update pull requests, create webhooks for code push events, list commits, repositories, groups, members and permissions. read_user Codacy retrieves the user's email addresses to enforce which commits are eligible for analysis. read_repository Codacy retrieves repository metadata, such as name, languages and collaborators. openid Codacy uses this permission for authentication using OpenID Connect . Bitbucket Cloud # If you log in with Bitbucket, Codacy requires the following permissions/scopes : Scope and permissions Description account:write Codacy retrieves the user's email addresses to enforce which commits are eligible for analysis. repository:admin Codacy retrieves repository metadata, such as name, languages and collaborators, and commit information. Codacy creates an SSH key on the repository to allow cloning and integrating with your repository. pullrequest:write Codacy retrieves pull request information to display on its side. Codacy might also create comments on the pull request, according to the results of code analysis. issue:write Codacy can create Bitbucket issues from issues found during code analysis. webhook Codacy creates webhooks for code pushes and pull request events (created, merged, etc.). These events might trigger code analysis. team Codacy uses your group/team membership information to enforce permissions. Read your workspace's project settings and read repositories contained within your workspace's projects. Revoking access to integrations # To revoke the access from Codacy to one or more of the OAuth providers: Click on your avatar on the top right-hand corner and select Your Account , tab Access Management . The Access Management page lists all current integrations with Git providers that you used to sign in or log in to Codacy. To revoke access to an integration, click the button Revoke access for the intended integration. To ensure that the integration is removed not only on Codacy but also on the integration side, it's important that you revoke the Codacy OAuth application access on your provider: GitHub Cloud GitLab Cloud Bitbucket Cloud After revoking an integration, Codacy will no longer be able to access or manipulate resources that require API calls, such as detecting new pull requests or adding comments to pull requests. However, Codacy will still be able to perform operations that only require using the Git protocol either via SSH or HTTPS, such as detecting new commits and calculating diffs. To remove your repositories from Codacy and stop the analysis you must delete them from your Codacy account . If you need to use an integration that you have previously revoked, log in again to Codacy with that integration so that Codacy can request the required permissions from the provider. Why does Codacy ask for permission to create SSH keys? # This section applies only to GitLab and Bitbucket On GitLab and Bitbucket organizations, when you add a private repository to Codacy, Codacy uses the integration with your Git provider to create a new SSH key on the repository. Codacy then uses that SSH key every time it needs to clone the repository. Codacy only adds read-only SSH keys and can't access any of your existing SSH keys. You have full control over which organizations and repositories Codacy is authorized to access. Codacy doesn't change the contents or member privileges of any repository you authorize it to analyze. We understand the desire for security and privacy and find that the SSH protocol is preferable to HTTPS as it separates Codacy's access rights from the one of the users. Tip You can revoke the keys created by Codacy at any time. See GitLab or Bitbucket documentation for further details.", "title": "Which permissions does Codacy need from my account?"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/#which-permissions-does-codacy-need-from-my-account", "text": "Codacy Cloud uses the OAuth protocol to handle logins and supports the following providers: GitHub Cloud GitLab Cloud Bitbucket Cloud Codacy requests only the necessary permissions from your Git provider to analyze your code and keeps your information secure . See the sections below for the detailed list of permissions that Codacy asks for depending on the provider.", "title": "Which permissions does Codacy need from my account?"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/#github-cloud", "text": "If you log in with GitHub, Codacy requires the following app permissions : Scope Permissions Description Repository permissions: Checks Read & Write Codacy creates and updates check runs with the results of code analysis. Issues Read & Write Codacy can create GitHub issues from issues found during code analysis. Metadata Read-Only Codacy retrieves repository metadata, such as name, languages, collaborators and commit information. Pull requests Read & Write Codacy retrieves pull request information to display on its side. Codacy might also create comments and suggestions on the pull request, according to the results of code analysis. Webhooks Read & Write Codacy creates webhooks for code pushes and pull request events (created, merged, etc.). These events might trigger code analysis. Commit statuses Read & Write Codacy sets the status of commits according to the result of code analysis. Contents Read-Only Codacy retrieves repository contents to get installation access tokens when integrating with your repositories and clone them, and for code coverage analysis. Codacy requests this permission since September 2023. Make sure an organization owner approves Codacy GitHub App updated permissions on your GitHub organization. Organization permissions: Webhooks Read & Write Codacy creates webhooks for organization and repository events (creation, deletion, member added, etc.). Members Read-Only Codacy retrieves information about organization members and teams to enforce permissions and user management. User permissions: These permissions are granted on an individual user basis as part of the user authorization flow. They will be also be displayed during account installation for transparency. Email addresses Read-Only Codacy retrieves the user's email addresses to enforce which commits are eligible for analysis.", "title": "GitHub Cloud"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/#gitlab-cloud", "text": "If you sign up with GitLab Cloud, Codacy requires the following permissions/scopes : Scope Description api Codacy uses GitLab's API to read and update pull requests, create webhooks for code push events, list commits, repositories, groups, members and permissions. read_user Codacy retrieves the user's email addresses to enforce which commits are eligible for analysis. read_repository Codacy retrieves repository metadata, such as name, languages and collaborators. openid Codacy uses this permission for authentication using OpenID Connect .", "title": "GitLab Cloud"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/#bitbucket-cloud", "text": "If you log in with Bitbucket, Codacy requires the following permissions/scopes : Scope and permissions Description account:write Codacy retrieves the user's email addresses to enforce which commits are eligible for analysis. repository:admin Codacy retrieves repository metadata, such as name, languages and collaborators, and commit information. Codacy creates an SSH key on the repository to allow cloning and integrating with your repository. pullrequest:write Codacy retrieves pull request information to display on its side. Codacy might also create comments on the pull request, according to the results of code analysis. issue:write Codacy can create Bitbucket issues from issues found during code analysis. webhook Codacy creates webhooks for code pushes and pull request events (created, merged, etc.). These events might trigger code analysis. team Codacy uses your group/team membership information to enforce permissions. Read your workspace's project settings and read repositories contained within your workspace's projects.", "title": "Bitbucket Cloud"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/#revoking-access-to-integrations", "text": "To revoke the access from Codacy to one or more of the OAuth providers: Click on your avatar on the top right-hand corner and select Your Account , tab Access Management . The Access Management page lists all current integrations with Git providers that you used to sign in or log in to Codacy. To revoke access to an integration, click the button Revoke access for the intended integration. To ensure that the integration is removed not only on Codacy but also on the integration side, it's important that you revoke the Codacy OAuth application access on your provider: GitHub Cloud GitLab Cloud Bitbucket Cloud After revoking an integration, Codacy will no longer be able to access or manipulate resources that require API calls, such as detecting new pull requests or adding comments to pull requests. However, Codacy will still be able to perform operations that only require using the Git protocol either via SSH or HTTPS, such as detecting new commits and calculating diffs. To remove your repositories from Codacy and stop the analysis you must delete them from your Codacy account . If you need to use an integration that you have previously revoked, log in again to Codacy with that integration so that Codacy can request the required permissions from the provider.", "title": "Revoking access to integrations"}, {"location": "getting-started/which-permissions-does-codacy-need-from-my-account/#why-does-codacy-ask-for-permission-to-create-ssh-keys", "text": "This section applies only to GitLab and Bitbucket On GitLab and Bitbucket organizations, when you add a private repository to Codacy, Codacy uses the integration with your Git provider to create a new SSH key on the repository. Codacy then uses that SSH key every time it needs to clone the repository. Codacy only adds read-only SSH keys and can't access any of your existing SSH keys. You have full control over which organizations and repositories Codacy is authorized to access. Codacy doesn't change the contents or member privileges of any repository you authorize it to analyze. We understand the desire for security and privacy and find that the SSH protocol is preferable to HTTPS as it separates Codacy's access rights from the one of the users. Tip You can revoke the keys created by Codacy at any time. See GitLab or Bitbucket documentation for further details.", "title": "Why does Codacy ask for permission to create SSH keys?"}, {"location": "organizations/audit-logs-for-organizations/", "text": "Audit logs for organizations # This feature is only available on Business plan Codacy logs important events in your organization, reflecting when your team members execute specific operations. This enables the generation of comprehensive reports to assist you with the audit process. For example, you can track who added a repository to Codacy, or changed the settings of a coding standard. Organization admins and organization managers can obtain the audit log data of the organization events using the Codacy API endpoint listAuditLogsForOrganization . The retention period of audit logs for organization events is one year. Audit log events # Each audit log tracks when a Codacy user executed a specific operation in your organization using the Codacy app or the Codacy API . Each operation is identified by an action . For the detailed content of each audit log, see the Codacy API reference . The sections below list the events that Codacy logs for your organization at user, organization, and repository levels. User # Event Description Action Log in User logged in to Codacy user.login Create account API token New account API token created user.tokens.create Read account API token List of account API tokens retrieved user.tokens.read Delete account API token Account API token deleted user.tokens.delete Organization # Event Description Action Add organization Organization added to Codacy organizations.create Add people to organization New people added to the organization organizations.people.create Join organization User joined the organization organizations.join Update repository management permissions Repository management permissions updated organizations.analysisconfigurationminimumpermission.update Assign organization manager role Organization manager role assigned to a team member organizations.security.managers.create Revoke organization manager role Organization manager role revoked from a team member organizations.security.managers.delete Update default Git provider configuration Default Git provider configuration for the organization updated organizations.integrations.providersettings.update Apply default Git provider configuration to all repositories Default Git provider configuration applied to all repositories of the organization organizations.integrations.providersettings.apply Create new organization hook New organization webhook created organizations.settings.hooks.create Create new gate policy New gate policy created organizations.gatepolicies.create Update gate policy Quality gate definition updated organizations.gatepolicies.update Apply gate policy to repositories Gate policy applied to a list of repositories organizations.gatepolicies.repositories.apply Make gate policy default Gate policy was made the default for the organization organizations.gatepolicies.setdefault Make Codacy gate policy default Built-in Codacy gate policy was made the default for the organization organizations.gatepolicies.setcodacydefault Delete gate policy Gate policy deleted organizations.gatepolicies.delete Create new coding standard using preset sensitivity levels New coding standard created organizations.presetsstandards.create Create new coding standard draft using individual language and code pattern settings New coding standard draft created organizations.codingstandards.create Create new coding standard from draft New coding standard created organizations.codingstandards.promote Update coding standard from draft Coding standard updated organizations.codingstandards.promote Apply coding standard to repositories Coding standard applied to a list of repositories organizations.codingstandards.repositories.apply Make coding standard default Coding standard was made the default organizations.codingstandards.setdefault Delete coding standard Coding standard deleted organizations.codingstandards.delete Repository # Event Description Action Create new post-commit hook New repository hook created repositories.integrations.postcommithook Create repository API token New repository API token created repositories.tokens.create Read repository API token List of repository API tokens retrieved repositories.tokens.read Delete repository API token Repository API token deleted repositories.tokens.delete Update Git provider integration settings ( GitHub , Bitbucket , or GitLab ) Git provider integration settings for the repository updated repositories.integrations.providersettings.update Refresh Git provider integration (applies only to Bitbucket and GitLab ) Git provider integration for the repository refreshed repositories.integrations.refreshprovider", "title": "Audit logs for organizations"}, {"location": "organizations/audit-logs-for-organizations/#audit-logs-for-organizations", "text": "This feature is only available on Business plan Codacy logs important events in your organization, reflecting when your team members execute specific operations. This enables the generation of comprehensive reports to assist you with the audit process. For example, you can track who added a repository to Codacy, or changed the settings of a coding standard. Organization admins and organization managers can obtain the audit log data of the organization events using the Codacy API endpoint listAuditLogsForOrganization . The retention period of audit logs for organization events is one year.", "title": "Audit logs for organizations"}, {"location": "organizations/audit-logs-for-organizations/#audit-log-events", "text": "Each audit log tracks when a Codacy user executed a specific operation in your organization using the Codacy app or the Codacy API . Each operation is identified by an action . For the detailed content of each audit log, see the Codacy API reference . The sections below list the events that Codacy logs for your organization at user, organization, and repository levels.", "title": "Audit log events"}, {"location": "organizations/changing-your-plan-and-billing/", "text": "Changing your plan and billing # Each organization on Codacy has a dedicated plan and associated billing. To make changes to the plan and billing of an organization, open your organization Settings , page Plan and billing . Note If you're using GitHub Marketplace, update your billing details or cancel your plan directly on your GitHub Billing page . If you cancel your plan or switch to a different Enterprise plan, some repositories may show outdated information in the Codacy UI. To update this information, reanalyze the repositories or push new commits. To upgrade to the Pro plan click Choose plan , choose between monthly or yearly billing, and provide your payment and invoice details To make changes to your Pro plan or invoice details click Edit plan details or click Edit invoice details If you have any questions or need help with your account, please contact support@codacy.com . Allowing new people to join your organization # On Codacy Cloud , organization admins control if team members need an approval before joining their organization. Codacy updates your seats automatically when new users join an organization. Note If you're using GitHub Marketplace, this configuration isn't available and team members must always wait for an organization owner to manually approve their requests to join the organization. In some Enterprise plans , Codacy automatically adds to the organization new people that commit to your private repositories. However, they still need to join the organization on the Codacy app if they want to use the UI. Choose one of the following options in your organization Settings , page Plan and billing : Allow new people to join immediately: people with access to the organization on the Git provider can join the organization on the Codacy app immediately, as long as there are seats available. Review join requests from new people: when people with access to the organization on the Git provider join the organization on Codacy app, an organization admin must manually approve their requests to join on the page People . Your teammates that have already been invited to join or were added to the organization are automatically approved, and you can also skip the approval process for organization admins.", "title": "Changing your plan and billing"}, {"location": "organizations/changing-your-plan-and-billing/#changing-your-plan-and-billing", "text": "Each organization on Codacy has a dedicated plan and associated billing. To make changes to the plan and billing of an organization, open your organization Settings , page Plan and billing . Note If you're using GitHub Marketplace, update your billing details or cancel your plan directly on your GitHub Billing page . If you cancel your plan or switch to a different Enterprise plan, some repositories may show outdated information in the Codacy UI. To update this information, reanalyze the repositories or push new commits. To upgrade to the Pro plan click Choose plan , choose between monthly or yearly billing, and provide your payment and invoice details To make changes to your Pro plan or invoice details click Edit plan details or click Edit invoice details If you have any questions or need help with your account, please contact support@codacy.com .", "title": "Changing your plan and billing"}, {"location": "organizations/changing-your-plan-and-billing/#allowing-new-people-to-join-your-organization", "text": "On Codacy Cloud , organization admins control if team members need an approval before joining their organization. Codacy updates your seats automatically when new users join an organization. Note If you're using GitHub Marketplace, this configuration isn't available and team members must always wait for an organization owner to manually approve their requests to join the organization. In some Enterprise plans , Codacy automatically adds to the organization new people that commit to your private repositories. However, they still need to join the organization on the Codacy app if they want to use the UI. Choose one of the following options in your organization Settings , page Plan and billing : Allow new people to join immediately: people with access to the organization on the Git provider can join the organization on the Codacy app immediately, as long as there are seats available. Review join requests from new people: when people with access to the organization on the Git provider join the organization on Codacy app, an organization admin must manually approve their requests to join on the page People . Your teammates that have already been invited to join or were added to the organization are automatically approved, and you can also skip the approval process for organization admins.", "title": "Allowing new people to join your organization"}, {"location": "organizations/managing-people/", "text": "Managing people # People signing up to the Codacy app and joining an organization become members of that organization. Members of a Codacy organization can see the dashboards and details of the organization repositories. Depending on their permissions on the Git provider, members can also manage the organization and repository settings on Codacy. For private repositories , Codacy only analyzes commits from people in your Codacy organization. To make sure that Codacy analyzes all relevant commits, add to your Codacy organization the committers that aren't members of the organization yet. Important Make sure that you invite or ask your teammates to join your organization on Codacy so that Codacy analyzes their commits to private repositories. Committers who aren't part of your Git provider organization can't join your organization on Codacy app, but you should still add them to your Codacy organization to analyze their commits to private repositories. To list and manage the people in your organization, open your organization Settings , page People . This page also shows their last activity on Codacy. Note In some Enterprise plans, Codacy automatically assigns a seat to any person with at least one analyzed commit to your private repositories over the past 90 days and frees up the seat after 90 days of code analysis inactivity. Joining an organization # To become a member of an organization on Codacy app you must sign up to Codacy using your Git provider and follow the instructions to either join an existing organization or add a new one. To join or add an organization after completing the sign-up process, click Organizations on the top right-hand menu under your avatar: Note On Codacy Cloud , organization admins control if team members need an approval before joining their organizations. Adding people to your organization # On Codacy Cloud , organization admins can also add teammates to their organization on Codacy. This is useful to allow Codacy to analyze commits to private repositories by committers who haven't signed up to Codacy or joined the organization yet. Tip You can also use the Codacy API to add people to your Codacy organization . This is useful while adding a large amount of people or to automatically add new members of your Git provider organization to Codacy. To add people to your organization: Open your organization Settings , page People , and click the button Add people . Note For Enterprise plans where Codacy automatically adds new committers to your organization, you can invite them to join the organization on the Codacy app by clicking the Invite people button. Select people from the list displaying pending requests to join the organization, as well as recent committers to the private repositories in your organization. Alternatively, click Add people using email addresses to manually enter the list of email addresses of the people you wish to add. Important To prevent the same person from occupying more than one seat in your organization, make sure your teammates update the email addresses associated with their Codacy account . On GitHub and Bitbucket organizations , Codacy automatically reduces seat duplication when commits are pushed by associating all the commit email addresses from the same Git provider user with a single Codacy committer. This mechanism requires that all developers committing to your private repositories set their Git email address and add all their email addresses to their GitHub account or Bitbucket account . Confirm the updated billing details displayed at the bottom of the window and click the button Add people . Codacy emails the newly added people inviting them to log in. Removing people from your organization # Members of an organization on Codacy can remove themselves from the organization, and organization admins can also remove other members and committers. When a member or committer leaves an organization: Codacy stops analyzing their commits to private repositories in the organization On GitLab and Bitbucket organizations Codacy stops analyzing repositories that were added by the member Organizations must have at least one admin, so when the last organization admin leaves the organization they must either add someone else as admin or delete the organization To remove people from your organization open your organization Settings , page People , click the icon next to the member or committer you wish to remove, and select Remove from organization . Note For Enterprise plans where Codacy automatically manages seat usage for your organization, you can't remove people who had their commits analyzed within the last 90 days because their are still active within the billing period. However, if you remove them from the organization on your Git provider, they no longer have permissions to your repositories on Codacy. See also # Adding people to Codacy programmatically Roles and permissions for organizations", "title": "Managing people"}, {"location": "organizations/managing-people/#managing-people", "text": "People signing up to the Codacy app and joining an organization become members of that organization. Members of a Codacy organization can see the dashboards and details of the organization repositories. Depending on their permissions on the Git provider, members can also manage the organization and repository settings on Codacy. For private repositories , Codacy only analyzes commits from people in your Codacy organization. To make sure that Codacy analyzes all relevant commits, add to your Codacy organization the committers that aren't members of the organization yet. Important Make sure that you invite or ask your teammates to join your organization on Codacy so that Codacy analyzes their commits to private repositories. Committers who aren't part of your Git provider organization can't join your organization on Codacy app, but you should still add them to your Codacy organization to analyze their commits to private repositories. To list and manage the people in your organization, open your organization Settings , page People . This page also shows their last activity on Codacy. Note In some Enterprise plans, Codacy automatically assigns a seat to any person with at least one analyzed commit to your private repositories over the past 90 days and frees up the seat after 90 days of code analysis inactivity.", "title": "Managing people"}, {"location": "organizations/managing-people/#joining", "text": "To become a member of an organization on Codacy app you must sign up to Codacy using your Git provider and follow the instructions to either join an existing organization or add a new one. To join or add an organization after completing the sign-up process, click Organizations on the top right-hand menu under your avatar: Note On Codacy Cloud , organization admins control if team members need an approval before joining their organizations.", "title": "Joining an organization"}, {"location": "organizations/managing-people/#adding-people", "text": "On Codacy Cloud , organization admins can also add teammates to their organization on Codacy. This is useful to allow Codacy to analyze commits to private repositories by committers who haven't signed up to Codacy or joined the organization yet. Tip You can also use the Codacy API to add people to your Codacy organization . This is useful while adding a large amount of people or to automatically add new members of your Git provider organization to Codacy. To add people to your organization: Open your organization Settings , page People , and click the button Add people . Note For Enterprise plans where Codacy automatically adds new committers to your organization, you can invite them to join the organization on the Codacy app by clicking the Invite people button. Select people from the list displaying pending requests to join the organization, as well as recent committers to the private repositories in your organization. Alternatively, click Add people using email addresses to manually enter the list of email addresses of the people you wish to add. Important To prevent the same person from occupying more than one seat in your organization, make sure your teammates update the email addresses associated with their Codacy account . On GitHub and Bitbucket organizations , Codacy automatically reduces seat duplication when commits are pushed by associating all the commit email addresses from the same Git provider user with a single Codacy committer. This mechanism requires that all developers committing to your private repositories set their Git email address and add all their email addresses to their GitHub account or Bitbucket account . Confirm the updated billing details displayed at the bottom of the window and click the button Add people . Codacy emails the newly added people inviting them to log in.", "title": "Adding people to your organization"}, {"location": "organizations/managing-people/#removing-people", "text": "Members of an organization on Codacy can remove themselves from the organization, and organization admins can also remove other members and committers. When a member or committer leaves an organization: Codacy stops analyzing their commits to private repositories in the organization On GitLab and Bitbucket organizations Codacy stops analyzing repositories that were added by the member Organizations must have at least one admin, so when the last organization admin leaves the organization they must either add someone else as admin or delete the organization To remove people from your organization open your organization Settings , page People , click the icon next to the member or committer you wish to remove, and select Remove from organization . Note For Enterprise plans where Codacy automatically manages seat usage for your organization, you can't remove people who had their commits analyzed within the last 90 days because their are still active within the billing period. However, if you remove them from the organization on your Git provider, they no longer have permissions to your repositories on Codacy.", "title": "Removing people from your organization"}, {"location": "organizations/managing-people/#see-also", "text": "Adding people to Codacy programmatically Roles and permissions for organizations", "title": "See also"}, {"location": "organizations/managing-repositories/", "text": "Managing repositories # Users with the necessary permissions on your Git provider can add repositories to Codacy to start analyzing them. The remaining organization members with access to the added repositories can then follow on Codacy the repositories of their interest. Important To see your repositories on Codacy, make sure that you have the necessary permissions over the repositories on the Git provider and that Codacy has the necessary permissions to access the repositories. To see all the repositories that you follow on Codacy, open the page Repositories under your organization. Organization admins also see the total number of repositories that have already been added to the organization . Across the application, Codacy calculates and displays data for the repositories on this list. This page lists the repositories that you follow on Codacy sorted by last updated date , and allows you to compare the repositories on the list according to the following metrics: Grade Issues Complexity Duplication Coverage The list also displays error and warning messages for repositories that have issues, such as when there are no committers added to the organization or when Codacy stopped having access to the repository. Hover the mouse cursor over the warning icons or open the repository to see more details. If you follow many repositories, you can use the search field above the list to quickly find a specific repository. Adding a repository # Analyzing private repositories is only available on paid plans Users with the necessary permissions can add a repository to Codacy to start analyzing it. Note When a user adds a new repository to Codacy, all organization admins start following it automatically. To add new repositories to Codacy: Click the button Manage repositories at the top right-hand corner of the page. This opens a window listing your organization repositories. Click Add next to the repositories you want to add. If you have many repositories, you can use the search field above the list to quickly find a specific repository. When you're done, close the window to return to your repositories list. Although Codacy immediately starts analyzing newly added repositories, they display empty metrics until the first analysis returns results. Following or unfollowing a repository # Users with no permission to add a repository to Codacy, can follow that repository after it has been added to Codacy, and stop following it at any time. To follow or unfollow repositories on Codacy: Click the button Manage repositories at the top right-hand corner of the page. This opens a window listing your organization repositories. Click Follow or Unfollow next to the repositories you want to follow or unfollow. If you have many repositories, you can use the search field above the list to quickly find a specific repository. When you're done, close the window to return to your repositories list. Note You automatically start following a repository as soon as you access any page from that repository. For example, when you access the repository using a direct link on your Git provider UI. Conversely, you automatically stop following a repository as soon as you try accessing any page from that repository but you don't have permissions to see that repository anymore. See also # Which metrics does Codacy calculate?", "title": "Managing repositories"}, {"location": "organizations/managing-repositories/#managing-repositories", "text": "Users with the necessary permissions on your Git provider can add repositories to Codacy to start analyzing them. The remaining organization members with access to the added repositories can then follow on Codacy the repositories of their interest. Important To see your repositories on Codacy, make sure that you have the necessary permissions over the repositories on the Git provider and that Codacy has the necessary permissions to access the repositories. To see all the repositories that you follow on Codacy, open the page Repositories under your organization. Organization admins also see the total number of repositories that have already been added to the organization . Across the application, Codacy calculates and displays data for the repositories on this list. This page lists the repositories that you follow on Codacy sorted by last updated date , and allows you to compare the repositories on the list according to the following metrics: Grade Issues Complexity Duplication Coverage The list also displays error and warning messages for repositories that have issues, such as when there are no committers added to the organization or when Codacy stopped having access to the repository. Hover the mouse cursor over the warning icons or open the repository to see more details. If you follow many repositories, you can use the search field above the list to quickly find a specific repository.", "title": "Managing repositories"}, {"location": "organizations/managing-repositories/#adding-a-repository", "text": "Analyzing private repositories is only available on paid plans Users with the necessary permissions can add a repository to Codacy to start analyzing it. Note When a user adds a new repository to Codacy, all organization admins start following it automatically. To add new repositories to Codacy: Click the button Manage repositories at the top right-hand corner of the page. This opens a window listing your organization repositories. Click Add next to the repositories you want to add. If you have many repositories, you can use the search field above the list to quickly find a specific repository. When you're done, close the window to return to your repositories list. Although Codacy immediately starts analyzing newly added repositories, they display empty metrics until the first analysis returns results.", "title": "Adding a repository"}, {"location": "organizations/managing-repositories/#follow-unfollow", "text": "Users with no permission to add a repository to Codacy, can follow that repository after it has been added to Codacy, and stop following it at any time. To follow or unfollow repositories on Codacy: Click the button Manage repositories at the top right-hand corner of the page. This opens a window listing your organization repositories. Click Follow or Unfollow next to the repositories you want to follow or unfollow. If you have many repositories, you can use the search field above the list to quickly find a specific repository. When you're done, close the window to return to your repositories list. Note You automatically start following a repository as soon as you access any page from that repository. For example, when you access the repository using a direct link on your Git provider UI. Conversely, you automatically stop following a repository as soon as you try accessing any page from that repository but you don't have permissions to see that repository anymore.", "title": "Following or unfollowing a repository"}, {"location": "organizations/managing-repositories/#see-also", "text": "Which metrics does Codacy calculate?", "title": "See also"}, {"location": "organizations/managing-security-and-risk/", "text": "Managing security and risk # The Security and risk management feature helps you quickly identify, track, and address security across your organization by automatically opening time-bound, prioritized findings whenever security problems are detected in your organization repositories, in your connected Jira instance , or as a result of penetration testing . Under Security and risk management, you can find the following pages to help you monitor the security of your repositories: Overview Findings In addition, on these pages, you can share filtered views of findings , export findings as a CSV file , and review severity rules and integration settings Overview # The Security and risk management overview page provides a high-level view of the security posture of your organization, including the number of open findings, the distribution of open findings by severity, the history of finding resolution, and a breakdown of the most high-risk repositories and most detected security categories. Use this page to assess your organization's security posture and its progress over time, identify areas for improvement, and share findings with stakeholders. To access the overview page, select an organization from the top navigation bar and select Security and risk on the left navigation sidebar. The overview page includes six panels: Open findings overview Open findings distribution Open findings history Activity history Top 10 high-risk repositories Top 10 common security categories To limit the information displayed in each panel to a specific set of repositories, use the filter drop-down above the main area. Open findings overview # The Open findings overview panel displays the total number of open security findings and the number of findings of each severity, helping you quickly assess the overall security posture of your organization and quickly review findings that are critical or overdue. To access the findings page with the corresponding filter applied, click on a number. Open findings distribution # The Open findings distribution panel shows the relative distribution of open findings by scan type, severity, or status, helping you evaluate the distribution of risk across different criteria and identify areas that may need immediate attention. To select the desired distribution, use the drop-down in the top right-hand corner of the panel. To access the findings page with the corresponding filter applied, click on a number. Open findings history # The Open findings history graph shows the open findings trends over the past three months, grouped by week and severity. It details the progression of your organization's risk and security posture over time and can, for example, help you understand if the right issues are being addressed. For a detailed view of the distribution on a specific week, hover over the graph. Activity history # The Activity history graph shows weekly counts of open and closed findings over the past three months, overlaid on the overall open findings trend. It complements the Open findings history graph with more information, such as the volume of findings addressed each week and a visual representation of the new/closed ratio. To filter the graph by finding severity, use the drop-down in the top right-hand corner of the panel. For a detailed view of the counts on a specific week, hover over the graph. Top 10 high-risk repositories # The Top 10 high-risk repositories list shows the repositories with the highest number of open findings, ordered by severity. Note This panel may list fewer than ten repositories if there are fewer than ten repositories with open findings in the organization or if fewer than ten repositories are selected in the dropdown Repository filter. Top 10 common security categories # The Top 10 common security categories list shows the most common security categories of open findings, ordered by count. To access the findings page with the corresponding filter applied, click on a category. Findings # The Security and risk management findings page displays a filtered list of findings. By default, this list is sorted by status, and you can click the First detected column name to sort the findings by the detection date. Use this page to review and prioritize findings and track the progress of your security efforts. To access the findings page, access the overview page and click the Findings tab. When viewing the findings, you can update the filtering criteria by clicking the Severity , Status , Repository , Security category , or Scan type drop-downs above the list. The Details column offers a quick overview of each finding in the list, including its title, source platform , scan type , security category , and related information such as the repository name, Jira issue key, or penetration testing report URL. To find out more, click this overview to navigate to the finding details on the source platform. Sharing a filtered view of findings # To share the current view of the overview or findings page, click the Copy URL button in the top right-hand corner of the page. This action copies the URL with the current filters applied to the clipboard. Exporting findings # This feature is available only to organization admins and organization managers To export a list of findings as a CSV file, click the options menu in the top right-hand corner of the page and select Export findings (.csv) . The exported list always includes all findings, ignoring any applied filters. Reviewing severity rules and integration settings # To review the severity assignment rules or manage the integration with Jira or Slack , click the options menu in the top right-hand corner of the page and select respectively See severity rules or View integrations . How Codacy manages findings # Important To open and close findings, Codacy must detect when the associated issues are introduced and fixed. The detection logic is platform-dependent and is described below. Codacy opens a new finding whenever a source platform detects a new security issue. The new finding is automatically assigned a severity and a status: The priority of the issue on the source platform sets the severity of the finding . In turn, the severity of the finding defines a deadline to close the finding. The time to the deadline sets the status of the finding . The finding then moves through different statuses as the deadline is approached, met, or missed. Codacy closes a finding when the source platform stops detecting the associated security issue. The following section details when Codacy opens and closes findings for each supported platform. How Codacy manages findings detected on Git repositories # Note To make sure that Codacy detects security issues correctly: Enable code patterns belonging to the Security category. These patterns are enabled by default, but may not be on custom configurations. Alternatively, apply a coding standard that includes patterns belonging to the Security category. Confirm that the latest commits to the default branches of your repositories are analyzed. Codacy opens a new finding when it detects a new security issue on the default branch of a repository. Codacy closes a finding in either of the following cases: Codacy detects that the associated issue isn't present in the most recent analyzed commit and therefore is fixed You ignore the associated issue You disable the tool that found the associated issue Important Deleting a repository deletes all open findings belonging to that repository. How Codacy manages findings detected on Jira # Note For Codacy to detect Jira issues, you must integrate Jira with Security and risk management . Codacy retrieves updates from Jira once a day. If an issue is opened and closed on the same day, Codacy may not detect it. To make sure that Codacy detects Jira issues correctly, assign the security label when creating the issue or immediately after. Codacy opens a new finding when it detects a new Jira issue with a security label (case-insensitive). Codacy closes a finding when it detects that the associated Jira issue is marked as Closed. How Codacy manages findings detected during penetration testing # Note Penetration testing is available upon request and is provided by a third-party partner. See how to request penetration testing for your organization . Codacy opens a finding for each security issue detected during a penetration test. Codacy closes a finding when a subsequent penetration test doesn't detect the underlying security issue. How Codacy manages findings detected during application scanning (DAST) # Note To view application scanning findings, also known as DAST (Dynamic Application Security Testing) findings, you must first generate a DAST report and upload it to Codacy . Codacy opens a finding for each security issue detected in the DAST report. If subsequent reports identify the same issue, Codacy updates the existing finding. Codacy closes a finding when it's not detected in a subsequent DAST report. If a previously closed issue reappears in a later report, Codacy reopens the finding. Finding severities and deadlines # Note Currently, Codacy doesn't support customizing the severity rules for security findings. The following table defines finding severities and the number of days to the deadline to fix the associated security issue, based on the importance of the underlying issue: Finding severity Days to deadline Underlying Codacy issue severity Underlying Jira issue priority 1 Critical 30 Critical Highest High 60 - High Medium 90 Medium Medium Low 120 Minor Low and other/custom 1 Those listed are the default Jira priority names. If you rename a default Jira priority, it keeps the correct mapping. Finding statuses # The following table describes how finding statuses map to deadlines: Status category Finding status Deadline Open Overdue The deadline has been missed Due soon Fewer than 15 days to the deadline On track 15 days or more to the deadline Closed Closed late Closed after the deadline Closed on time Closed before the deadline Supported security categories # Note Due to a recent update, some issues may be temporarily assigned the Not yet categorized category. To categorize these issues, you can reanalyze the default branch of the relevant repository . For a list of repositories that have issues with this category, use the Security category filter on the Findings page. Each Codacy issue reported by Security and risk management belongs to one of the following security categories: Security category Description Android Android-specific security issues. Authentication Broken authentication and authorization attacks consist in gaining access to accounts that allow disclosing sensitive information or performing operations that could compromise the system. Command Injection Command injection attacks aim to execute arbitrary commands on the host operating system. Cookies Security issues related to insecure cookies. Cryptography Cryptography attacks exploit failures related to cryptography (or lack thereof), potentially leading to exposure of sensitive data. CSRF Cross-Site Request Forgery (CSRF) attacks force an end user to execute unwanted actions on a web application in which they're currently authenticated. Denial of Service Denial of Service (DoS) attacks make a resource (site, application, server) unavailable for legitimate users, typically by flooding the resource with requests or exploiting a vulnerability to trigger a crash. File Access File access security issues may allow an attacker to access arbitrary files and directories stored on the file system such as application source code, configuration, and critical system files. HTTP Headers Insecure HTTP headers are a common attack vector for malicious users. Input Validation Client input should always be validated to prevent malformed or malicious data from entering the workflow of an information system. Insecure Modules and Libraries Security issues related to modules or libraries that can potentially include vulnerabilities. Insecure Storage Security issues related to insecure storage of sensitive data. Malicious Code Security issues related to code patterns that are potentially unsafe. Mass Assignment Unprotected mass assignments are a Rails feature that could allow an attacker to update sensitive model attributes. Regex Regular expressions can be used in Denial of Service attacks, exploiting the fact that in most regular expression implementations the computational load grows exponentially with input size. Routes Badly configured routes can give unintended access to an attacker. SQL Injection SQL injection attacks insert or \"inject\" malicious SQL queries into the application via the client input data. SSL Security issues related with old SSL versions or configurations that have known cryptographic weaknesses and should no longer be used. Unexpected Behaviour Security issues related to potentially insecure system API calls. Visibility Logging should always be included for security events to better allow attack detection and help defend against vulnerabilities. XSS Cross-Site Scripting (XSS) attacks inject malicious client-side scripts into trusted websites that are visited by the end users. Other Other language-specific security issues. Scan types # Security and risk management classifies each finding with a Scan type , indicating the specific source or method used to detect the finding. This information helps you understand the origin of the finding and the context in which the underlying issue was detected. The following table lists the available scan types and their descriptions: Scan type Description Code Scanning Analysis of source code for vulnerabilities without execution. Also known as Static Application Security Testing ( SAST ). Software Composition Analysis Analysis of external libraries and packages for vulnerabilities or outdated versions. Exposed Secrets Detection of sensitive information, such as passwords or API keys, inadvertently included in the code. Infrastructure as Code Detection of configuration issues within infrastructure-as-code (IaC) files that could pose risks. Penetration Testing Results from penetration testing to find security vulnerabilities in running code. App Scanning Simulated attacks on live applications to find vulnerabilities. Also known as Dynamic Application Security Testing ( DAST ). Languages checked for security issues # Security and risk management supports checking the languages and infrastructure-as-code platforms below for any Codacy security issues reported by the corresponding tools: Language Tools that report security issues Apex PMD , Semgrep 1 AWS CloudFormation Checkov , Trivy 2 C Clang-Tidy 3 , Cppcheck , Flawfinder , Semgrep 1 , Trivy C# SonarC# , Semgrep 1 , Trivy C++ Clang-Tidy 3 , Cppcheck , Flawfinder , Semgrep 1 , Trivy Dart Trivy Dockerfile Hadolint , Semgrep 1 , Trivy Elixir Credo , Trivy GitHub Actions Semgrep 1 Go Gosec 3 , Semgrep 1 , Trivy Groovy CodeNarc Helm Trivy 2 Java Semgrep 1 , SpotBugs 3 4 , Trivy JavaScript ESLint 5 , Semgrep 1 , Trivy JSON Trivy Kotlin Semgrep 1 Kubernetes Trivy 2 Objective-C Clang-Tidy 3 PHP PHP_CodeSniffer , PHP Mess Detector , Semgrep 1 , Trivy PowerShell PSScriptAnalyser Python Bandit , Prospector , Pylint , Semgrep 1 , Trivy Ruby Brakeman , RuboCop , Semgrep 1 , Trivy Rust Semgrep 1 , Trivy Scala Codacy Scalameta Pro , Semgrep 1 , SpotBugs 3 4 Swift Semgrep 1 Shell ShellCheck Semgrep 1 Terraform Semgrep 1 , Trivy Transact-SQL TSQLLint TypeScript ESLint 5 , Semgrep 1 , Trivy Visual Basic SonarVB 1 : Semgrep supports additional security rules when signing up for Semgrep Pro . 2 : Currently, Trivy only supports scanning YAML files on this platform. 3 : Supported as a client-side tool . 4 : Includes the plugin Find Security Bugs . 5 : Includes the plugins no-unsanitized , security , security-node , and xss .", "title": "Managing security and risk"}, {"location": "organizations/managing-security-and-risk/#managing-security-and-risk", "text": "The Security and risk management feature helps you quickly identify, track, and address security across your organization by automatically opening time-bound, prioritized findings whenever security problems are detected in your organization repositories, in your connected Jira instance , or as a result of penetration testing . Under Security and risk management, you can find the following pages to help you monitor the security of your repositories: Overview Findings In addition, on these pages, you can share filtered views of findings , export findings as a CSV file , and review severity rules and integration settings", "title": "Managing security and risk"}, {"location": "organizations/managing-security-and-risk/#dashboard", "text": "The Security and risk management overview page provides a high-level view of the security posture of your organization, including the number of open findings, the distribution of open findings by severity, the history of finding resolution, and a breakdown of the most high-risk repositories and most detected security categories. Use this page to assess your organization's security posture and its progress over time, identify areas for improvement, and share findings with stakeholders. To access the overview page, select an organization from the top navigation bar and select Security and risk on the left navigation sidebar. The overview page includes six panels: Open findings overview Open findings distribution Open findings history Activity history Top 10 high-risk repositories Top 10 common security categories To limit the information displayed in each panel to a specific set of repositories, use the filter drop-down above the main area.", "title": "Overview"}, {"location": "organizations/managing-security-and-risk/#item-list", "text": "The Security and risk management findings page displays a filtered list of findings. By default, this list is sorted by status, and you can click the First detected column name to sort the findings by the detection date. Use this page to review and prioritize findings and track the progress of your security efforts. To access the findings page, access the overview page and click the Findings tab. When viewing the findings, you can update the filtering criteria by clicking the Severity , Status , Repository , Security category , or Scan type drop-downs above the list. The Details column offers a quick overview of each finding in the list, including its title, source platform , scan type , security category , and related information such as the repository name, Jira issue key, or penetration testing report URL. To find out more, click this overview to navigate to the finding details on the source platform.", "title": "Findings"}, {"location": "organizations/managing-security-and-risk/#sharing-filtered-view", "text": "To share the current view of the overview or findings page, click the Copy URL button in the top right-hand corner of the page. This action copies the URL with the current filters applied to the clipboard.", "title": "Sharing a filtered view of findings"}, {"location": "organizations/managing-security-and-risk/#exporting-the-security-item-list", "text": "This feature is available only to organization admins and organization managers To export a list of findings as a CSV file, click the options menu in the top right-hand corner of the page and select Export findings (.csv) . The exported list always includes all findings, ignoring any applied filters.", "title": "Exporting findings"}, {"location": "organizations/managing-security-and-risk/#reviewing-settings", "text": "To review the severity assignment rules or manage the integration with Jira or Slack , click the options menu in the top right-hand corner of the page and select respectively See severity rules or View integrations .", "title": "Reviewing severity rules and integration settings"}, {"location": "organizations/managing-security-and-risk/#opening-and-closing-items", "text": "Important To open and close findings, Codacy must detect when the associated issues are introduced and fixed. The detection logic is platform-dependent and is described below. Codacy opens a new finding whenever a source platform detects a new security issue. The new finding is automatically assigned a severity and a status: The priority of the issue on the source platform sets the severity of the finding . In turn, the severity of the finding defines a deadline to close the finding. The time to the deadline sets the status of the finding . The finding then moves through different statuses as the deadline is approached, met, or missed. Codacy closes a finding when the source platform stops detecting the associated security issue. The following section details when Codacy opens and closes findings for each supported platform.", "title": "How Codacy manages findings"}, {"location": "organizations/managing-security-and-risk/#item-severities-and-deadlines", "text": "Note Currently, Codacy doesn't support customizing the severity rules for security findings. The following table defines finding severities and the number of days to the deadline to fix the associated security issue, based on the importance of the underlying issue: Finding severity Days to deadline Underlying Codacy issue severity Underlying Jira issue priority 1 Critical 30 Critical Highest High 60 - High Medium 90 Medium Medium Low 120 Minor Low and other/custom 1 Those listed are the default Jira priority names. If you rename a default Jira priority, it keeps the correct mapping.", "title": "Finding severities and deadlines"}, {"location": "organizations/managing-security-and-risk/#item-statuses", "text": "The following table describes how finding statuses map to deadlines: Status category Finding status Deadline Open Overdue The deadline has been missed Due soon Fewer than 15 days to the deadline On track 15 days or more to the deadline Closed Closed late Closed after the deadline Closed on time Closed before the deadline", "title": "Finding statuses"}, {"location": "organizations/managing-security-and-risk/#supported-security-categories", "text": "Note Due to a recent update, some issues may be temporarily assigned the Not yet categorized category. To categorize these issues, you can reanalyze the default branch of the relevant repository . For a list of repositories that have issues with this category, use the Security category filter on the Findings page. Each Codacy issue reported by Security and risk management belongs to one of the following security categories: Security category Description Android Android-specific security issues. Authentication Broken authentication and authorization attacks consist in gaining access to accounts that allow disclosing sensitive information or performing operations that could compromise the system. Command Injection Command injection attacks aim to execute arbitrary commands on the host operating system. Cookies Security issues related to insecure cookies. Cryptography Cryptography attacks exploit failures related to cryptography (or lack thereof), potentially leading to exposure of sensitive data. CSRF Cross-Site Request Forgery (CSRF) attacks force an end user to execute unwanted actions on a web application in which they're currently authenticated. Denial of Service Denial of Service (DoS) attacks make a resource (site, application, server) unavailable for legitimate users, typically by flooding the resource with requests or exploiting a vulnerability to trigger a crash. File Access File access security issues may allow an attacker to access arbitrary files and directories stored on the file system such as application source code, configuration, and critical system files. HTTP Headers Insecure HTTP headers are a common attack vector for malicious users. Input Validation Client input should always be validated to prevent malformed or malicious data from entering the workflow of an information system. Insecure Modules and Libraries Security issues related to modules or libraries that can potentially include vulnerabilities. Insecure Storage Security issues related to insecure storage of sensitive data. Malicious Code Security issues related to code patterns that are potentially unsafe. Mass Assignment Unprotected mass assignments are a Rails feature that could allow an attacker to update sensitive model attributes. Regex Regular expressions can be used in Denial of Service attacks, exploiting the fact that in most regular expression implementations the computational load grows exponentially with input size. Routes Badly configured routes can give unintended access to an attacker. SQL Injection SQL injection attacks insert or \"inject\" malicious SQL queries into the application via the client input data. SSL Security issues related with old SSL versions or configurations that have known cryptographic weaknesses and should no longer be used. Unexpected Behaviour Security issues related to potentially insecure system API calls. Visibility Logging should always be included for security events to better allow attack detection and help defend against vulnerabilities. XSS Cross-Site Scripting (XSS) attacks inject malicious client-side scripts into trusted websites that are visited by the end users. Other Other language-specific security issues.", "title": "Supported security categories"}, {"location": "organizations/managing-security-and-risk/#scan-types", "text": "Security and risk management classifies each finding with a Scan type , indicating the specific source or method used to detect the finding. This information helps you understand the origin of the finding and the context in which the underlying issue was detected. The following table lists the available scan types and their descriptions: Scan type Description Code Scanning Analysis of source code for vulnerabilities without execution. Also known as Static Application Security Testing ( SAST ). Software Composition Analysis Analysis of external libraries and packages for vulnerabilities or outdated versions. Exposed Secrets Detection of sensitive information, such as passwords or API keys, inadvertently included in the code. Infrastructure as Code Detection of configuration issues within infrastructure-as-code (IaC) files that could pose risks. Penetration Testing Results from penetration testing to find security vulnerabilities in running code. App Scanning Simulated attacks on live applications to find vulnerabilities. Also known as Dynamic Application Security Testing ( DAST ).", "title": "Scan types"}, {"location": "organizations/managing-security-and-risk/#languages-checked-for-security-issues", "text": "Security and risk management supports checking the languages and infrastructure-as-code platforms below for any Codacy security issues reported by the corresponding tools: Language Tools that report security issues Apex PMD , Semgrep 1 AWS CloudFormation Checkov , Trivy 2 C Clang-Tidy 3 , Cppcheck , Flawfinder , Semgrep 1 , Trivy C# SonarC# , Semgrep 1 , Trivy C++ Clang-Tidy 3 , Cppcheck , Flawfinder , Semgrep 1 , Trivy Dart Trivy Dockerfile Hadolint , Semgrep 1 , Trivy Elixir Credo , Trivy GitHub Actions Semgrep 1 Go Gosec 3 , Semgrep 1 , Trivy Groovy CodeNarc Helm Trivy 2 Java Semgrep 1 , SpotBugs 3 4 , Trivy JavaScript ESLint 5 , Semgrep 1 , Trivy JSON Trivy Kotlin Semgrep 1 Kubernetes Trivy 2 Objective-C Clang-Tidy 3 PHP PHP_CodeSniffer , PHP Mess Detector , Semgrep 1 , Trivy PowerShell PSScriptAnalyser Python Bandit , Prospector , Pylint , Semgrep 1 , Trivy Ruby Brakeman , RuboCop , Semgrep 1 , Trivy Rust Semgrep 1 , Trivy Scala Codacy Scalameta Pro , Semgrep 1 , SpotBugs 3 4 Swift Semgrep 1 Shell ShellCheck Semgrep 1 Terraform Semgrep 1 , Trivy Transact-SQL TSQLLint TypeScript ESLint 5 , Semgrep 1 , Trivy Visual Basic SonarVB 1 : Semgrep supports additional security rules when signing up for Semgrep Pro . 2 : Currently, Trivy only supports scanning YAML files on this platform. 3 : Supported as a client-side tool . 4 : Includes the plugin Find Security Bugs . 5 : Includes the plugins no-unsanitized , security , security-node , and xss .", "title": "Languages checked for security issues"}, {"location": "organizations/organization-overview/", "text": "Organization overview # The Organization overview provides an overview of the repositories belonging to your Git provider organization that you follow on Codacy . Here you can compare their statuses and check for items that require your attention. To access your Organization overview, select an organization from the top navigation bar and select Overview on the left navigation sidebar. Important The Organization overview calculates metrics and displays data only for the repositories that you follow on Codacy. This means that depending on their list of followed repositories, two users can see different results on their Organization overview. The Organization overview displays information for at most the last 100 updated repositories . Use the drop-down list at the top of the page to filter the information displayed on all dashboard areas based on the repositories that you select. For example, you can use the filter to monitor the quality of the repositories maintained by specific teams or that include certain programming languages, or to ignore legacy repositories that are no longer maintained. The selected repositories are stored in your browser so that the same filter is applied between your visits to the Organization overview page. You can use the language filter to help you narrow down the list of repositories in the drop-down list: On the Organization overview you have the following areas to help you monitor your repositories: Overall quality chart Open pull requests Last updated repositories On this page, you can also see the Organization setup area, which provides you with a checklist of items that you should complete to ensure that your organization is set up correctly and that you're getting the most out of Codacy. The following sections provide a detailed description of the repository-related dashboard areas. Note You can use the Codacy API to generate reports or obtain information about the code quality of your repositories in a more flexible way. For more information see the list of available API endpoints and the following examples: Obtaining current issues in repositories Obtaining code quality metrics for files Overall quality chart # The Overall quality chart compares the repositories that you follow regarding grade , issues , complex files , duplication , and code coverage . Each tab displays the average value for the corresponding metric across your repositories. Hover the mouse pointer over the bars to see the metrics for the corresponding repositories. Click the bars to navigate directly to the corresponding repository. If you have over 8 repositories, the chart displays your repositories grouped by grade or percentage intervals. Click the bars to see and navigate directly to the corresponding repositories. Tip If you don't have coverage set up for any of your repositories yet, the coverage tab provides you with instructions on how to add coverage for your repositories . Open pull requests # The Most problematic tab displays a short list of the open pull requests that aren't up to standards and have the most potential to negatively affect your code quality. The Last updated tab displays open pull requests sorted by the date of update with one of the following status: Not up to standards Up to standards Analysis failed (something went wrong during the analysis) Analyzing (intermediate status while Codacy is analyzing the pull request) Click a pull request to see the details of that pull request . Last updated repositories # The Last updated repositories list displays the last updated repositories, sorted by reverse date of the last update. Each item displays the date of the last update and the current grade of the repository. Click See all to see all the repositories that you follow on Codacy. Note The exact value of the last updated date of the repositories depends on your Git provider: GitHub: date of the last commit to any branch of the repository (value of pushed_at from the GitHub Repositories API ). GitLab: date when the project was last updated (value of last_activity_at from the GitLab Groups API ). Note that this value is only updated at most once per hour ). Bitbucket: date when the repository was last updated (value of updated_on from the Bitbucket Repositories API ). On Bitbucket Server Codacy can't obtain this information and the list displays the repositories in alphabetical order. See also # Which metrics does Codacy calculate? Using the Codacy API to obtain current issues in repositories Using the Codacy API to obtain code quality metrics for files", "title": "Organization overview"}, {"location": "organizations/organization-overview/#organization-overview", "text": "The Organization overview provides an overview of the repositories belonging to your Git provider organization that you follow on Codacy . Here you can compare their statuses and check for items that require your attention. To access your Organization overview, select an organization from the top navigation bar and select Overview on the left navigation sidebar. Important The Organization overview calculates metrics and displays data only for the repositories that you follow on Codacy. This means that depending on their list of followed repositories, two users can see different results on their Organization overview. The Organization overview displays information for at most the last 100 updated repositories . Use the drop-down list at the top of the page to filter the information displayed on all dashboard areas based on the repositories that you select. For example, you can use the filter to monitor the quality of the repositories maintained by specific teams or that include certain programming languages, or to ignore legacy repositories that are no longer maintained. The selected repositories are stored in your browser so that the same filter is applied between your visits to the Organization overview page. You can use the language filter to help you narrow down the list of repositories in the drop-down list: On the Organization overview you have the following areas to help you monitor your repositories: Overall quality chart Open pull requests Last updated repositories On this page, you can also see the Organization setup area, which provides you with a checklist of items that you should complete to ensure that your organization is set up correctly and that you're getting the most out of Codacy. The following sections provide a detailed description of the repository-related dashboard areas. Note You can use the Codacy API to generate reports or obtain information about the code quality of your repositories in a more flexible way. For more information see the list of available API endpoints and the following examples: Obtaining current issues in repositories Obtaining code quality metrics for files", "title": "Organization overview"}, {"location": "organizations/organization-overview/#overall-quality-chart", "text": "The Overall quality chart compares the repositories that you follow regarding grade , issues , complex files , duplication , and code coverage . Each tab displays the average value for the corresponding metric across your repositories. Hover the mouse pointer over the bars to see the metrics for the corresponding repositories. Click the bars to navigate directly to the corresponding repository. If you have over 8 repositories, the chart displays your repositories grouped by grade or percentage intervals. Click the bars to see and navigate directly to the corresponding repositories. Tip If you don't have coverage set up for any of your repositories yet, the coverage tab provides you with instructions on how to add coverage for your repositories .", "title": "Overall quality chart"}, {"location": "organizations/organization-overview/#open-pull-requests", "text": "The Most problematic tab displays a short list of the open pull requests that aren't up to standards and have the most potential to negatively affect your code quality. The Last updated tab displays open pull requests sorted by the date of update with one of the following status: Not up to standards Up to standards Analysis failed (something went wrong during the analysis) Analyzing (intermediate status while Codacy is analyzing the pull request) Click a pull request to see the details of that pull request .", "title": "Open pull requests"}, {"location": "organizations/organization-overview/#last-updated-repositories", "text": "The Last updated repositories list displays the last updated repositories, sorted by reverse date of the last update. Each item displays the date of the last update and the current grade of the repository. Click See all to see all the repositories that you follow on Codacy. Note The exact value of the last updated date of the repositories depends on your Git provider: GitHub: date of the last commit to any branch of the repository (value of pushed_at from the GitHub Repositories API ). GitLab: date when the project was last updated (value of last_activity_at from the GitLab Groups API ). Note that this value is only updated at most once per hour ). Bitbucket: date when the repository was last updated (value of updated_on from the Bitbucket Repositories API ). On Bitbucket Server Codacy can't obtain this information and the list displays the repositories in alphabetical order.", "title": "Last updated repositories"}, {"location": "organizations/organization-overview/#see-also", "text": "Which metrics does Codacy calculate? Using the Codacy API to obtain current issues in repositories Using the Codacy API to obtain code quality metrics for files", "title": "See also"}, {"location": "organizations/roles-and-permissions-for-organizations/", "text": "Roles and permissions for organizations # By default, Codacy assigns each organization member a role corresponding to that member's role on your Git provider. Each Codacy role, from most restrictive (repository read) to most capable (organization admin), corresponds to a set of permissions that determine what each member can do on Codacy. To update a member's role on Codacy, update that member's role on your Git provider. When next logging in to Codacy, the member is assigned the new role. Organization admins can also grant additional permissions: To roles, by configuring repository management permissions To individual members, by assigning the organization manager role To review the permissions granted by each role, see the tables for each Git provider: Permissions for GitHub Permissions for GitLab Permissions for Bitbucket To list and manage the members of your Codacy organization, see the Managing people page. Configuring repository management permissions # Only organization admins can update this setting By default, only users with the Codacy role repository write can change analysis configurations. To change this, open your organization Settings , page Roles and permissions , and choose the Codacy roles that can perform the following operations on the repositories of your organization: Ignore issues Ignore files Configure code patterns Configure languages Manage branches Reanalyze branches and pull requests Managing the organization manager role # Only organization admins can update this setting To grant an organization member additional permissions, you can assign that member the organization manager role. This role isn't influenced by a member's Git provider role. To review the additional permissions granted by the organization manager role, see the tables for each Git provider ( GitHub , GitLab , Bitbucket ). Note Organization managers can access the Policies and Integrations settings sections of your organization and can therefore impact some repository settings for all repositories of your organization, even repositories that they can't access on the Git provider. However, they can't access the repositories themselves and can only see the repository names. Assigning the organization manager role # To assign the organization manager role: Open your organization Settings , page Roles and permissions . In the Organization managers area, use the search field to find the relevant organization member and click the member's name. Note You can only assign the organization manager role to members of your organization . Revoking the organization manager role # To revoke the organization manager role: Open your organization Settings , page Roles and permissions . In the Organization managers area, scroll the list to find the relevant user. Click the Revoke role icon to the right of the user's name and confirm. Permissions for GitHub # The table below maps the GitHub Cloud and GitHub Enterprise roles to the corresponding Codacy roles and the operations that they're allowed to perform: GitHub role Outside collaborator 1 Repository read Repository triage Repository write Repository maintain Repository admin - Organization Owner Codacy role - Repository read Repository write Repository admin Organization manager Organization admin Join organization No Yes 2 Yes 2 Yes 2 Yes Yes 2 View and follow private repository No Yes Yes Yes Yes Yes Access Security and risk management No Yes 3 Yes 3 Yes 3 Yes Yes Ignore issues and files, configure code patterns and languages, manage branches, reanalyze branches and pull requests No Configurable Configurable Yes Inherits original permission Yes Upload coverage using an account API token, see the coverage report logs No No Yes Yes Inherits original permission Yes Configure repository Git provider integration settings No No No Yes Inherits original permission Yes Configure repository quality gates and goals No No No Yes Inherits original permission Yes Enable repository analysis to run on a local build server, manage repository API tokens No No No Yes Inherits original permission Yes Add and remove repository No No No Yes 4 Inherits original permission Yes Manage organization gate policies and coding standards No No No No Yes Yes Configure organization default settings for Git provider integration No No No No Yes Yes Obtain audit logs for organization events 5 No No No No Yes Yes Invite and accept members, modify billing No No No No No Yes Assign and revoke the organization manager role No No No No No Yes 1 : Outside collaborators aren't supported as members of organizations on Codacy. You can still add outside collaborators to Codacy so that Codacy analyzes their commits to private repositories, but they won't be able to join your Codacy organization. 2 : Joining an organization may need an approval depending on your setting for accepting new people . 3 : These users can only see security items originating from Codacy repositories that they follow. 4 : Requires that an organization owner has given the Codacy GitHub App access to the repositories to add or remove. 5 : Audit logs are available only on Business plan . Permissions for GitLab # The table below maps the GitLab Cloud and GitLab Enterprise roles to the corresponding Codacy roles and the operations that they're allowed to perform: GitLab role External user 1 Project guest Project reporter Project developer Project maintainer Project owner - Group owner Administrator Codacy role - Repository read Repository write Repository admin Organization manager Organization admin Join organization No Yes 2 Yes 2 Yes 2 Yes Yes 2 View and follow private repository No Yes Yes Yes Yes Yes Access Security and risk management No Yes 3 Yes 3 Yes 3 Yes Yes Ignore issues and files, configure code patterns and languages, manage branches, reanalyze branches and pull requests No Configurable Configurable Yes Inherits original permission Yes Upload coverage using an account API token, see the coverage report logs No No Yes Yes Inherits original permission Yes Configure repository Git provider integration settings No No No Yes Inherits original permission Yes Configure repository quality gates and goals No No No Yes Inherits original permission Yes Configure repository to run analysis on local build server, manage repository API tokens No No No Yes Inherits original permission Yes Add and remove repository No No No Yes Inherits original permission Yes Manage organization gate policies and coding standards No No No No Yes Yes Configure organization default settings for Git provider integration No No No No Yes Yes Obtain audit logs for organization events 4 No No No No Yes Yes Invite and accept members, modify billing No No No No No Yes Assign and revoke the organization manager role No No No No No Yes 1 : External users aren't supported as members of organizations on Codacy. You can still add external users to Codacy so that Codacy analyzes their commits to private repositories, but they won't be able to join your Codacy organization. 2 : Joining an organization may need an approval depending on your setting for accepting new people . 3 : These users can only see security items originating from Codacy repositories that they follow. 4 : Audit logs are available only on Business plan . Permissions for Bitbucket # The table below maps the Bitbucket Cloud and Bitbucket Server roles to the corresponding Codacy roles and the operations that they're allowed to perform: Bitbucket role Read Write 1 - Admin Codacy role Repository read Organization manager Organization admin Join organization Yes 2 Yes Yes 2 View and follow private repository Yes Yes Yes Access Security and risk management Yes 3 Yes Yes Ignore issues and files, configure code patterns and languages, manage branches, reanalyze branches and pull requests Configurable Inherits original permission Yes Upload coverage using an account API token, see the coverage report logs No Inherits original permission Yes Configure repository Git provider integration settings No Inherits original permission Yes Configure repository quality gates and goals No Inherits original permission Yes Configure repository to run analysis on local build server, manage repository API tokens No Inherits original permission Yes Add and remove repository No Inherits original permission Yes Manage organization gate policies and coding standards No Yes Yes Configure organization default settings for Git provider integration No Yes Yes Obtain audit logs for organization events 4 No Yes Yes Invite and accept members, modify billing No No Yes Assign and revoke the organization manager role No No Yes 1 : Codacy can't distinguish the Bitbucket roles Read and Write because of a limitation on the Bitbucket API. 2 : Joining an organization may need an approval depending on your setting for accepting new people . 3 : These users can only see security items originating from Codacy repositories that they follow. 4 : Audit logs are available only on Business plan . See also # Managing people Accepting new people to your organization /*Center text in all cells except the first column*/ td:not(:first-child), th:not(:first-child) { text-align: center !important; } /*Background color for row containing the Codacy permission levels*/ table:not(data-exclude) tr:nth-child(1) td { background-color: #EBF1FF; } /*Add vertical borders and disable horizontal borders*/ td { border-left: 1px solid var(--md-default-fg-color--lightest); border-top: 1px solid var(--md-default-fg-color--lightest); } td:nth-child(1) { border-left: 0; } /*Background for cells marking various operations*/ .yes { background-color: #E6F4EA; } .no { background-color: #FFF1EB; } .maybe { background-color: #F2F9FC; }", "title": "Roles and permissions for organizations"}, {"location": "organizations/roles-and-permissions-for-organizations/#roles-and-permissions-for-organizations", "text": "By default, Codacy assigns each organization member a role corresponding to that member's role on your Git provider. Each Codacy role, from most restrictive (repository read) to most capable (organization admin), corresponds to a set of permissions that determine what each member can do on Codacy. To update a member's role on Codacy, update that member's role on your Git provider. When next logging in to Codacy, the member is assigned the new role. Organization admins can also grant additional permissions: To roles, by configuring repository management permissions To individual members, by assigning the organization manager role To review the permissions granted by each role, see the tables for each Git provider: Permissions for GitHub Permissions for GitLab Permissions for Bitbucket To list and manage the members of your Codacy organization, see the Managing people page.", "title": "Roles and permissions for organizations"}, {"location": "organizations/roles-and-permissions-for-organizations/#change-analysis-configuration", "text": "Only organization admins can update this setting By default, only users with the Codacy role repository write can change analysis configurations. To change this, open your organization Settings , page Roles and permissions , and choose the Codacy roles that can perform the following operations on the repositories of your organization: Ignore issues Ignore files Configure code patterns Configure languages Manage branches Reanalyze branches and pull requests", "title": "Configuring repository management permissions"}, {"location": "organizations/roles-and-permissions-for-organizations/#managing-the-organization-manager-role", "text": "Only organization admins can update this setting To grant an organization member additional permissions, you can assign that member the organization manager role. This role isn't influenced by a member's Git provider role. To review the additional permissions granted by the organization manager role, see the tables for each Git provider ( GitHub , GitLab , Bitbucket ). Note Organization managers can access the Policies and Integrations settings sections of your organization and can therefore impact some repository settings for all repositories of your organization, even repositories that they can't access on the Git provider. However, they can't access the repositories themselves and can only see the repository names.", "title": "Managing the organization manager role"}, {"location": "organizations/roles-and-permissions-for-organizations/#permissions-for-github", "text": "The table below maps the GitHub Cloud and GitHub Enterprise roles to the corresponding Codacy roles and the operations that they're allowed to perform: GitHub role Outside collaborator 1 Repository read Repository triage Repository write Repository maintain Repository admin - Organization Owner Codacy role - Repository read Repository write Repository admin Organization manager Organization admin Join organization No Yes 2 Yes 2 Yes 2 Yes Yes 2 View and follow private repository No Yes Yes Yes Yes Yes Access Security and risk management No Yes 3 Yes 3 Yes 3 Yes Yes Ignore issues and files, configure code patterns and languages, manage branches, reanalyze branches and pull requests No Configurable Configurable Yes Inherits original permission Yes Upload coverage using an account API token, see the coverage report logs No No Yes Yes Inherits original permission Yes Configure repository Git provider integration settings No No No Yes Inherits original permission Yes Configure repository quality gates and goals No No No Yes Inherits original permission Yes Enable repository analysis to run on a local build server, manage repository API tokens No No No Yes Inherits original permission Yes Add and remove repository No No No Yes 4 Inherits original permission Yes Manage organization gate policies and coding standards No No No No Yes Yes Configure organization default settings for Git provider integration No No No No Yes Yes Obtain audit logs for organization events 5 No No No No Yes Yes Invite and accept members, modify billing No No No No No Yes Assign and revoke the organization manager role No No No No No Yes 1 : Outside collaborators aren't supported as members of organizations on Codacy. You can still add outside collaborators to Codacy so that Codacy analyzes their commits to private repositories, but they won't be able to join your Codacy organization. 2 : Joining an organization may need an approval depending on your setting for accepting new people . 3 : These users can only see security items originating from Codacy repositories that they follow. 4 : Requires that an organization owner has given the Codacy GitHub App access to the repositories to add or remove. 5 : Audit logs are available only on Business plan .", "title": "Permissions for GitHub"}, {"location": "organizations/roles-and-permissions-for-organizations/#permissions-for-gitlab", "text": "The table below maps the GitLab Cloud and GitLab Enterprise roles to the corresponding Codacy roles and the operations that they're allowed to perform: GitLab role External user 1 Project guest Project reporter Project developer Project maintainer Project owner - Group owner Administrator Codacy role - Repository read Repository write Repository admin Organization manager Organization admin Join organization No Yes 2 Yes 2 Yes 2 Yes Yes 2 View and follow private repository No Yes Yes Yes Yes Yes Access Security and risk management No Yes 3 Yes 3 Yes 3 Yes Yes Ignore issues and files, configure code patterns and languages, manage branches, reanalyze branches and pull requests No Configurable Configurable Yes Inherits original permission Yes Upload coverage using an account API token, see the coverage report logs No No Yes Yes Inherits original permission Yes Configure repository Git provider integration settings No No No Yes Inherits original permission Yes Configure repository quality gates and goals No No No Yes Inherits original permission Yes Configure repository to run analysis on local build server, manage repository API tokens No No No Yes Inherits original permission Yes Add and remove repository No No No Yes Inherits original permission Yes Manage organization gate policies and coding standards No No No No Yes Yes Configure organization default settings for Git provider integration No No No No Yes Yes Obtain audit logs for organization events 4 No No No No Yes Yes Invite and accept members, modify billing No No No No No Yes Assign and revoke the organization manager role No No No No No Yes 1 : External users aren't supported as members of organizations on Codacy. You can still add external users to Codacy so that Codacy analyzes their commits to private repositories, but they won't be able to join your Codacy organization. 2 : Joining an organization may need an approval depending on your setting for accepting new people . 3 : These users can only see security items originating from Codacy repositories that they follow. 4 : Audit logs are available only on Business plan .", "title": "Permissions for GitLab"}, {"location": "organizations/roles-and-permissions-for-organizations/#permissions-for-bitbucket", "text": "The table below maps the Bitbucket Cloud and Bitbucket Server roles to the corresponding Codacy roles and the operations that they're allowed to perform: Bitbucket role Read Write 1 - Admin Codacy role Repository read Organization manager Organization admin Join organization Yes 2 Yes Yes 2 View and follow private repository Yes Yes Yes Access Security and risk management Yes 3 Yes Yes Ignore issues and files, configure code patterns and languages, manage branches, reanalyze branches and pull requests Configurable Inherits original permission Yes Upload coverage using an account API token, see the coverage report logs No Inherits original permission Yes Configure repository Git provider integration settings No Inherits original permission Yes Configure repository quality gates and goals No Inherits original permission Yes Configure repository to run analysis on local build server, manage repository API tokens No Inherits original permission Yes Add and remove repository No Inherits original permission Yes Manage organization gate policies and coding standards No Yes Yes Configure organization default settings for Git provider integration No Yes Yes Obtain audit logs for organization events 4 No Yes Yes Invite and accept members, modify billing No No Yes Assign and revoke the organization manager role No No Yes 1 : Codacy can't distinguish the Bitbucket roles Read and Write because of a limitation on the Bitbucket API. 2 : Joining an organization may need an approval depending on your setting for accepting new people . 3 : These users can only see security items originating from Codacy repositories that they follow. 4 : Audit logs are available only on Business plan .", "title": "Permissions for Bitbucket"}, {"location": "organizations/roles-and-permissions-for-organizations/#see-also", "text": "Managing people Accepting new people to your organization /*Center text in all cells except the first column*/ td:not(:first-child), th:not(:first-child) { text-align: center !important; } /*Background color for row containing the Codacy permission levels*/ table:not(data-exclude) tr:nth-child(1) td { background-color: #EBF1FF; } /*Add vertical borders and disable horizontal borders*/ td { border-left: 1px solid var(--md-default-fg-color--lightest); border-top: 1px solid var(--md-default-fg-color--lightest); } td:nth-child(1) { border-left: 0; } /*Background for cells marking various operations*/ .yes { background-color: #E6F4EA; } .no { background-color: #FFF1EB; } .maybe { background-color: #F2F9FC; }", "title": "See also"}, {"location": "organizations/using-coding-standards/", "text": "Using coding standards # Coding standards enable the analysis of multiple repositories with the same tool and code pattern configurations, ensuring consistent code quality across your organization. Multiple coding standards can be applied to the same repository. For example, you can use coding standards to ensure that a group of repositories follow the same security rules or coding conventions. This page covers the following topics: Creating a coding standard Configuring a coding standard (guided setup) Configuring a coding standard (advanced setup) Defining default coding standards Editing a coding standard Deleting a coding standard Using a coding standard alongside tool configuration files Using multiple coding standards Creating a coding standard # Note Codacy currently supports up to 10 coding standards per organization. To create a coding standard for your organization: Open your organization Policies page, tab Coding standards . Click the button Create new standard at the top right-hand corner of the page. This opens the coding standard creation form. Enter a unique name for the new coding standard. Optionally, check Apply to new repositories to set the new coding standard as one of your organization's default coding standards , so it applies automatically to new repositories. Choose whether to create the coding standard using a guided or advanced setup: The guided setup lets you choose preset sensitivity levels for each issue type, turning on relevant patterns in bulk. It's ideal for quickly setting up a coding standard with minimal effort. You can always fine-tune the coding standard by editing it later using the advanced setup. The advanced setup lets you choose individual languages and code patterns to activate. It's ideal for fine-tuning the coding standard to your organization's specific needs, offering more control over the tools and code patterns used. With the advanced setup, you can optionally select a repository as the baseline for the new coding standard. This is useful if you already have a well-configured repository that you wish to use as a template. Click Create coding standard to proceed to the guided setup or advanced setup , depending on your choice. Configuring a coding standard (guided setup) # If you selected Guided setup when creating a new coding standard , follow these steps: Adjust the sensitivity of the coding standard from Essential to Comprehensive for each issue category group: Essential : Focuses on the most important issues by including the most critical code patterns. Ideal for initial integration, to prevent overwhelming developers, and to speed up analysis times. Comprehensive : Detects all issues by including all code patterns, capturing the complete severity spectrum. Ideal for detailed code quality reviews, while reducing emphasis on critical issues. It may increase analysis times. Tip Initially, set the sensitivity to Essential for most category groups to focus on critical code patterns. It helps streamline the integration process with Codacy without overwhelming developers with too many reported issues. You can gradually include more patterns as needed. Click Next: Select and apply to repositories . Select existing repositories that should follow the new coding standard and click Save and apply coding standard . Codacy will start using the new coding standard on the next analysis of each selected repository. Configuring a coding standard (advanced setup) # If you selected Advanced setup when creating a new coding standard or are editing an existing coding standard, follow these steps: Select the programming languages that the new coding standard should include. Important The coding standard will only control tools that can analyze one or more of the languages selected in this step. If a language is omitted in this step, Codacy uses repository-level tool configurations if present or global Codacy defaults otherwise, and may analyze the omitted language. To prevent this: In this step select all languages, so that the coding standard controls all tools. In the next step, explicitly disable the tools that you don't want to use. Click Next: Tools and patterns . Configure the tools and patterns of the coding standard: Toggle the tools to run when Codacy analyzes your code. For each enabled tool, configure the code patterns to use. Tip Use the filters to find the relevant tools and code patterns. The recommended configurations are manually curated by Codacy or based on tool defaults and are marked with the icon . To toggle multiple code patterns at once, click the checkbox of the first pattern and Shift+click the checkbox of the last pattern in a range. To toggle all the code patterns visible on the list, click the checkbox on the header of the code patterns list. If there are more code patterns to load on the list, you can click the link Enable/Disable all patterns to toggle all patterns matching the current filters. Proceed with the remaining wizard steps to finish creating or editing your coding standard. Defining default coding standards # For ease of management, you can define multiple default coding standards that automatically apply to new repositories. In the absence of default coding standards, Codacy applies global defaults to all new repositories. Note When Codacy introduces new tools, those are automatically added to the global Codacy defaults but need to be manually added to a default coding standard. You can mark a new coding standard as default when creating one. To mark an existing coding standard as default: Open your organization Policies page, tab Coding standards . Toggle Apply to new repositories on the relevant coding standard card. Editing a coding standard # Note Any edits to the configurations of a coding standard are automatically applied on the next analysis of each associated repository. To edit an existing coding standard or change the repositories that follow that coding standard: Open your organization Policies page, tab Coding standards . Click the edit icon on the coding standard card. Edit the current coding standard configurations and click the button Next to advance to the following configuration pages : Note When editing an existing coding standard, the advanced setup is the default view. Select languages : the programming languages that the coding standard applies to. On this page, you can rename the coding standard by clicking the edit icon next to the name of the coding standard. Choose tools and patterns : the tool and code pattern configurations of the coding standard. Select and apply to repositories : the repositories that follow the coding standard. Click the button Save and apply coding standard on the repository selection page to save your changes to the coding standard. Codacy will start using the updated coding standard on the next analysis of each selected repository. Deleting a coding standard # To delete a coding standard: Open your organization Policies page, tab Coding standards . Click the trash can icon on the coding standard card and confirm. Using a coding standard alongside tool configuration files # When using a tool configuration file alongside a coding standard, the configuration file controls the code patterns, while the coding standard controls whether the tool is enabled or disabled. Using multiple coding standards # When Codacy analyzes your code using multiple coding standards, it merges the tools and patterns from each standard. Enabled tools and patterns in any applied standard will be enforced. Important If the same pattern appears in multiple standards, the version from the most recently applied standard (with its parameters) takes precedence. See also # Configuring code patterns on each repository How to implement Google JavaScript style guide with Codacy", "title": "Using coding standards"}, {"location": "organizations/using-coding-standards/#using-coding-standards", "text": "Coding standards enable the analysis of multiple repositories with the same tool and code pattern configurations, ensuring consistent code quality across your organization. Multiple coding standards can be applied to the same repository. For example, you can use coding standards to ensure that a group of repositories follow the same security rules or coding conventions. This page covers the following topics: Creating a coding standard Configuring a coding standard (guided setup) Configuring a coding standard (advanced setup) Defining default coding standards Editing a coding standard Deleting a coding standard Using a coding standard alongside tool configuration files Using multiple coding standards", "title": "Using coding standards"}, {"location": "organizations/using-coding-standards/#creating", "text": "Note Codacy currently supports up to 10 coding standards per organization. To create a coding standard for your organization: Open your organization Policies page, tab Coding standards . Click the button Create new standard at the top right-hand corner of the page. This opens the coding standard creation form. Enter a unique name for the new coding standard. Optionally, check Apply to new repositories to set the new coding standard as one of your organization's default coding standards , so it applies automatically to new repositories. Choose whether to create the coding standard using a guided or advanced setup: The guided setup lets you choose preset sensitivity levels for each issue type, turning on relevant patterns in bulk. It's ideal for quickly setting up a coding standard with minimal effort. You can always fine-tune the coding standard by editing it later using the advanced setup. The advanced setup lets you choose individual languages and code patterns to activate. It's ideal for fine-tuning the coding standard to your organization's specific needs, offering more control over the tools and code patterns used. With the advanced setup, you can optionally select a repository as the baseline for the new coding standard. This is useful if you already have a well-configured repository that you wish to use as a template. Click Create coding standard to proceed to the guided setup or advanced setup , depending on your choice.", "title": "Creating a coding standard"}, {"location": "organizations/using-coding-standards/#guided-setup", "text": "If you selected Guided setup when creating a new coding standard , follow these steps: Adjust the sensitivity of the coding standard from Essential to Comprehensive for each issue category group: Essential : Focuses on the most important issues by including the most critical code patterns. Ideal for initial integration, to prevent overwhelming developers, and to speed up analysis times. Comprehensive : Detects all issues by including all code patterns, capturing the complete severity spectrum. Ideal for detailed code quality reviews, while reducing emphasis on critical issues. It may increase analysis times. Tip Initially, set the sensitivity to Essential for most category groups to focus on critical code patterns. It helps streamline the integration process with Codacy without overwhelming developers with too many reported issues. You can gradually include more patterns as needed. Click Next: Select and apply to repositories . Select existing repositories that should follow the new coding standard and click Save and apply coding standard . Codacy will start using the new coding standard on the next analysis of each selected repository.", "title": "Configuring a coding standard (guided setup)"}, {"location": "organizations/using-coding-standards/#advanced-settings", "text": "If you selected Advanced setup when creating a new coding standard or are editing an existing coding standard, follow these steps: Select the programming languages that the new coding standard should include. Important The coding standard will only control tools that can analyze one or more of the languages selected in this step. If a language is omitted in this step, Codacy uses repository-level tool configurations if present or global Codacy defaults otherwise, and may analyze the omitted language. To prevent this: In this step select all languages, so that the coding standard controls all tools. In the next step, explicitly disable the tools that you don't want to use. Click Next: Tools and patterns . Configure the tools and patterns of the coding standard: Toggle the tools to run when Codacy analyzes your code. For each enabled tool, configure the code patterns to use. Tip Use the filters to find the relevant tools and code patterns. The recommended configurations are manually curated by Codacy or based on tool defaults and are marked with the icon . To toggle multiple code patterns at once, click the checkbox of the first pattern and Shift+click the checkbox of the last pattern in a range. To toggle all the code patterns visible on the list, click the checkbox on the header of the code patterns list. If there are more code patterns to load on the list, you can click the link Enable/Disable all patterns to toggle all patterns matching the current filters. Proceed with the remaining wizard steps to finish creating or editing your coding standard.", "title": "Configuring a coding standard (advanced setup)"}, {"location": "organizations/using-coding-standards/#set-default", "text": "For ease of management, you can define multiple default coding standards that automatically apply to new repositories. In the absence of default coding standards, Codacy applies global defaults to all new repositories. Note When Codacy introduces new tools, those are automatically added to the global Codacy defaults but need to be manually added to a default coding standard. You can mark a new coding standard as default when creating one. To mark an existing coding standard as default: Open your organization Policies page, tab Coding standards . Toggle Apply to new repositories on the relevant coding standard card.", "title": "Defining default coding standards"}, {"location": "organizations/using-coding-standards/#editing", "text": "Note Any edits to the configurations of a coding standard are automatically applied on the next analysis of each associated repository. To edit an existing coding standard or change the repositories that follow that coding standard: Open your organization Policies page, tab Coding standards . Click the edit icon on the coding standard card. Edit the current coding standard configurations and click the button Next to advance to the following configuration pages : Note When editing an existing coding standard, the advanced setup is the default view. Select languages : the programming languages that the coding standard applies to. On this page, you can rename the coding standard by clicking the edit icon next to the name of the coding standard. Choose tools and patterns : the tool and code pattern configurations of the coding standard. Select and apply to repositories : the repositories that follow the coding standard. Click the button Save and apply coding standard on the repository selection page to save your changes to the coding standard. Codacy will start using the updated coding standard on the next analysis of each selected repository.", "title": "Editing a coding standard"}, {"location": "organizations/using-coding-standards/#deleting", "text": "To delete a coding standard: Open your organization Policies page, tab Coding standards . Click the trash can icon on the coding standard card and confirm.", "title": "Deleting a coding standard"}, {"location": "organizations/using-coding-standards/#using-with-tool-configuration", "text": "When using a tool configuration file alongside a coding standard, the configuration file controls the code patterns, while the coding standard controls whether the tool is enabled or disabled.", "title": "Using a coding standard alongside tool configuration files"}, {"location": "organizations/using-coding-standards/#using-multiple", "text": "When Codacy analyzes your code using multiple coding standards, it merges the tools and patterns from each standard. Enabled tools and patterns in any applied standard will be enforced. Important If the same pattern appears in multiple standards, the version from the most recently applied standard (with its parameters) takes precedence.", "title": "Using multiple coding standards"}, {"location": "organizations/using-coding-standards/#see-also", "text": "Configuring code patterns on each repository How to implement Google JavaScript style guide with Codacy", "title": "See also"}, {"location": "organizations/using-gate-policies/", "text": "Using gate policies # Gate policies help you ensure that Codacy uses the same quality gates across your organization repositories. Codacy provides a built-in gate policy, Codacy Gate Policy , which sets minimum quality levels for pull requests and commits. The following screenshot displays the default configuration values: By default, Codacy applies the Codacy Gate Policy automatically to newly added repositories. You can then create new gate policies with different quality gates and make them the default for your organization. Creating a new gate policy # To create a new gate policy for your organization: Open your organization Policies page, tab Gate policies . Click the button Create new gate policy at the top right-hand corner of the page. This opens a window with the gate policy creation form. Enter a unique name and click Create gate policy . Set the values for the quality gates and click Next: Select and apply to repositories . Select existing repositories that should follow the gate policy and click Save and apply gate policy . Codacy will start using the new gate policy on the next analysis of each selected repository. Setting a gate policy as default # To set a gate policy as default: Open your organization Policies page, tab Gate policies . Toggle Make default on the relevant gate policy card. Note Only one gate policy at a time can be the default gate policy. Codacy will start applying the default gate policy to newly added repositories. Editing a gate policy # To edit the quality gates of an existing gate policy or change the repositories that follow that gate policy: Open your organization Policies page, tab Gate policies . Click the edit icon on the gate policy card. Edit the current quality gate values and click the button Next: Select and apply to repositories . Note You can't change the quality gate values of the built-in Codacy Gate Policy . Edit the list of repositories that follow the gate policy. Click the button Save and apply gate policy to save your changes to the gate policy. Codacy will start using the updated gate policy on the next analysis of each selected repository. If you stop applying a gate policy to a repository, Codacy restores the previous quality gates of that repository. Deleting a gate policy # Note You can't delete the built-in Codacy Gate Policy . To delete an organization gate policy: Open your organization Policies page, tab Gate policies . Click the trash can icon on the gate policy card and confirm. When you delete a gate policy: Codacy restores the previous quality gates of each repository following that gate policy. If the deleted gate policy was the default for your organization, Codacy makes the built-in Codacy Gate Policy the default.", "title": "Using gate policies"}, {"location": "organizations/using-gate-policies/#using-gate-policies", "text": "Gate policies help you ensure that Codacy uses the same quality gates across your organization repositories. Codacy provides a built-in gate policy, Codacy Gate Policy , which sets minimum quality levels for pull requests and commits. The following screenshot displays the default configuration values: By default, Codacy applies the Codacy Gate Policy automatically to newly added repositories. You can then create new gate policies with different quality gates and make them the default for your organization.", "title": "Using gate policies"}, {"location": "organizations/using-gate-policies/#creating", "text": "To create a new gate policy for your organization: Open your organization Policies page, tab Gate policies . Click the button Create new gate policy at the top right-hand corner of the page. This opens a window with the gate policy creation form. Enter a unique name and click Create gate policy . Set the values for the quality gates and click Next: Select and apply to repositories . Select existing repositories that should follow the gate policy and click Save and apply gate policy . Codacy will start using the new gate policy on the next analysis of each selected repository.", "title": "Creating a new gate policy"}, {"location": "organizations/using-gate-policies/#set-default", "text": "To set a gate policy as default: Open your organization Policies page, tab Gate policies . Toggle Make default on the relevant gate policy card. Note Only one gate policy at a time can be the default gate policy. Codacy will start applying the default gate policy to newly added repositories.", "title": "Setting a gate policy as default"}, {"location": "organizations/using-gate-policies/#editing", "text": "To edit the quality gates of an existing gate policy or change the repositories that follow that gate policy: Open your organization Policies page, tab Gate policies . Click the edit icon on the gate policy card. Edit the current quality gate values and click the button Next: Select and apply to repositories . Note You can't change the quality gate values of the built-in Codacy Gate Policy . Edit the list of repositories that follow the gate policy. Click the button Save and apply gate policy to save your changes to the gate policy. Codacy will start using the updated gate policy on the next analysis of each selected repository. If you stop applying a gate policy to a repository, Codacy restores the previous quality gates of that repository.", "title": "Editing a gate policy"}, {"location": "organizations/using-gate-policies/#deleting", "text": "Note You can't delete the built-in Codacy Gate Policy . To delete an organization gate policy: Open your organization Policies page, tab Gate policies . Click the trash can icon on the gate policy card and confirm. When you delete a gate policy: Codacy restores the previous quality gates of each repository following that gate policy. If the deleted gate policy was the default for your organization, Codacy makes the built-in Codacy Gate Policy the default.", "title": "Deleting a gate policy"}, {"location": "organizations/what-are-organizations/", "text": "What are organizations # Codacy organizations let you automatically import your Git provider organizations, repositories (including your personal repositories that don't belong to a Git provider organization), and team members into Codacy with a few clicks. Changes to the organizations, repositories, and team members are synchronized with Codacy in real-time, avoiding the manual management of repositories and teams. Adding an organization # To add a new organization to Codacy, select Add organization on the navigation menu. This opens the list of organizations on your Git providers. The organization with the same name as your Git provider username contains your personal repositories. To add a new organization to Codacy, click the link Add for that organization. To join an organization that's already on Codacy, click the link Join for that organization. To add organizations from a Git provider not yet listed on this page, click Add provider and give the necessary permissions for Codacy to sync with the new Git provider and display your organizations. Note If you can't see the organization you're looking for, follow these troubleshooting instructions . Updates on the Git provider # If you update your organization or repository information on your Git provider, some changes are automatically reflected on Codacy, as described in the table below. Note If an update to your organization name isn't automatically reflected on Codacy, navigate to the organization Settings page, tab Profile , and click the Synchronize button. Git provider Rename repository Change repository visibility Delete repository Rename organization or group Remove member from organization or group Delete organization or group GitHub Cloud Yes Yes Yes Yes Yes Yes GitHub Enterprise Yes Yes Yes Yes Yes Yes GitLab Cloud No No No No No No GitLab Enterprise Yes Yes Yes Yes Yes Yes Bitbucket Cloud Yes Yes No No No No Bitbucket Server Yes Yes No No No No Check out the roles and permission mapping from the Git providers . Deleting an organization # Deleting an organization on Codacy completely removes the configurations and all data related to the organization and its repositories from Codacy. This operation doesn't make any changes on your Git provider. To delete an organization, open the Profile page and click the button Delete organization . Note If you're using Codacy Cloud we'll ask for your feedback on why you're deleting your organization. See also # How does Codacy support GitLab Cloud? How does Codacy support GitLab Enterprise? How does Codacy support Bitbucket Cloud? How does Codacy support Bitbucket Server?", "title": "What are organizations"}, {"location": "organizations/what-are-organizations/#what-are-organizations", "text": "Codacy organizations let you automatically import your Git provider organizations, repositories (including your personal repositories that don't belong to a Git provider organization), and team members into Codacy with a few clicks. Changes to the organizations, repositories, and team members are synchronized with Codacy in real-time, avoiding the manual management of repositories and teams.", "title": "What are organizations"}, {"location": "organizations/what-are-organizations/#adding-an-organization", "text": "To add a new organization to Codacy, select Add organization on the navigation menu. This opens the list of organizations on your Git providers. The organization with the same name as your Git provider username contains your personal repositories. To add a new organization to Codacy, click the link Add for that organization. To join an organization that's already on Codacy, click the link Join for that organization. To add organizations from a Git provider not yet listed on this page, click Add provider and give the necessary permissions for Codacy to sync with the new Git provider and display your organizations. Note If you can't see the organization you're looking for, follow these troubleshooting instructions .", "title": "Adding an organization"}, {"location": "organizations/what-are-organizations/#updates-on-the-git-provider", "text": "If you update your organization or repository information on your Git provider, some changes are automatically reflected on Codacy, as described in the table below. Note If an update to your organization name isn't automatically reflected on Codacy, navigate to the organization Settings page, tab Profile , and click the Synchronize button. Git provider Rename repository Change repository visibility Delete repository Rename organization or group Remove member from organization or group Delete organization or group GitHub Cloud Yes Yes Yes Yes Yes Yes GitHub Enterprise Yes Yes Yes Yes Yes Yes GitLab Cloud No No No No No No GitLab Enterprise Yes Yes Yes Yes Yes Yes Bitbucket Cloud Yes Yes No No No No Bitbucket Server Yes Yes No No No No Check out the roles and permission mapping from the Git providers .", "title": "Updates on the Git provider"}, {"location": "organizations/what-are-organizations/#deleting-an-organization", "text": "Deleting an organization on Codacy completely removes the configurations and all data related to the organization and its repositories from Codacy. This operation doesn't make any changes on your Git provider. To delete an organization, open the Profile page and click the button Delete organization . Note If you're using Codacy Cloud we'll ask for your feedback on why you're deleting your organization.", "title": "Deleting an organization"}, {"location": "organizations/what-are-organizations/#see-also", "text": "How does Codacy support GitLab Cloud? How does Codacy support GitLab Enterprise? How does Codacy support Bitbucket Cloud? How does Codacy support Bitbucket Server?", "title": "See also"}, {"location": "organizations/integrations/default-git-provider-integration-settings/", "text": "Default Git provider integration settings # You can configure the default settings that Codacy uses to integrate with your Git provider when you add a new repository to Codacy. This enables you to apply the same settings across your organization repositories. To configure these default settings, open your organization Integrations page and select your Git provider. The organization-level Git provider integration settings define the defaults that Codacy applies to new repositories. You can then customize the settings for each individual repository, which depend on your Git provider, GitHub , GitLab or Bitbucket . Applying default settings to all repositories # To ensure that all your repositories are configured with the default Git provider integration settings defined for your organization, click the button Apply default to all repositories . See also # Integrating Codacy with your Git workflow", "title": "Default Git provider integration settings"}, {"location": "organizations/integrations/default-git-provider-integration-settings/#default-git-provider-integration-settings", "text": "You can configure the default settings that Codacy uses to integrate with your Git provider when you add a new repository to Codacy. This enables you to apply the same settings across your organization repositories. To configure these default settings, open your organization Integrations page and select your Git provider. The organization-level Git provider integration settings define the defaults that Codacy applies to new repositories. You can then customize the settings for each individual repository, which depend on your Git provider, GitHub , GitLab or Bitbucket .", "title": "Default Git provider integration settings"}, {"location": "organizations/integrations/default-git-provider-integration-settings/#apply-all", "text": "To ensure that all your repositories are configured with the default Git provider integration settings defined for your organization, click the button Apply default to all repositories .", "title": "Applying default settings to all repositories"}, {"location": "organizations/integrations/default-git-provider-integration-settings/#see-also", "text": "Integrating Codacy with your Git workflow", "title": "See also"}, {"location": "organizations/integrations/jira-integration/", "text": "Organization Jira integration for Security and risk management # This integration is only available for Jira Cloud Integrate Jira with Security and risk management to import your Jira issues and manage them all in one place as security items. Installing the Jira integration # To install the Jira integration: On Jira, add the label security (case-insensitive) to the issues you wish to import and confirm that they use the right Jira priorities to correctly map to item severities . Tip Add the security label as a default to all new Jira issues that track security-related work in your organization. Open your organization Integrations , page Jira , and click Install Jira to proceed to Atlassian's website. Note Use a Jira account with admin permissions when installing this integration. This lets Codacy access all issues, since the integration inherits the permissions of the account that installs it. On Atlassian's website, authorize Codacy. Once successful, you're redirected back to Codacy. After installing, Codacy imports all open Jira issues labeled security and created up to 90 days before the integration and then retrieves updates from Jira once a day. For more information on how this integration works, see how Codacy manages security items and how Codacy assigns security item severities . Uninstalling the Jira integration # To uninstall the Jira integration, open your organization Integrations , page Jira , then click Uninstall Jira and confirm. Important Uninstalling the Jira integration as described above deletes all associated open items. You can alternatively uninstall the Jira integration on the Jira website: this doesn't delete anything, but it prevents Codacy from opening new Jira-related items.", "title": "Jira integration for Security and risk management"}, {"location": "organizations/integrations/jira-integration/#organization-jira-integration-for-security-and-risk-management", "text": "This integration is only available for Jira Cloud Integrate Jira with Security and risk management to import your Jira issues and manage them all in one place as security items.", "title": "Organization Jira integration for Security and risk management"}, {"location": "organizations/integrations/jira-integration/#installing-the-jira-integration", "text": "To install the Jira integration: On Jira, add the label security (case-insensitive) to the issues you wish to import and confirm that they use the right Jira priorities to correctly map to item severities . Tip Add the security label as a default to all new Jira issues that track security-related work in your organization. Open your organization Integrations , page Jira , and click Install Jira to proceed to Atlassian's website. Note Use a Jira account with admin permissions when installing this integration. This lets Codacy access all issues, since the integration inherits the permissions of the account that installs it. On Atlassian's website, authorize Codacy. Once successful, you're redirected back to Codacy. After installing, Codacy imports all open Jira issues labeled security and created up to 90 days before the integration and then retrieves updates from Jira once a day. For more information on how this integration works, see how Codacy manages security items and how Codacy assigns security item severities .", "title": "Installing the Jira integration"}, {"location": "organizations/integrations/jira-integration/#uninstalling-the-jira-integration", "text": "To uninstall the Jira integration, open your organization Integrations , page Jira , then click Uninstall Jira and confirm. Important Uninstalling the Jira integration as described above deletes all associated open items. You can alternatively uninstall the Jira integration on the Jira website: this doesn't delete anything, but it prevents Codacy from opening new Jira-related items.", "title": "Uninstalling the Jira integration"}, {"location": "organizations/integrations/slack-integration/", "text": "Organization Slack integration for Security issues # The organization Slack integration for Security issues sends notifications to a Slack channel of your choice whenever Codacy detects new critical Security issues in the default branch of any repository in your organization. Installing the Slack integration # To install the Slack integration: On Slack : Access the Incoming WebHooks page on the App Directory of your Slack account. Select the channel where you want to receive notifications and click Add Incoming WebHooks Integration . Copy the Incoming WebHook URL (it starts with https://hooks.slack.com/services/ ). On Codacy : Open your organization Integrations , page Slack . Paste the Incoming WebHook URL in the field and click Install Slack . Once the Slack integration is installed, Codacy sends a confirmation message to the Slack channel you configured when creating the Incoming WebHook. From there on, Codacy notifies you on the same channel whenever a new critical Security issue is detected in the default branch of any repository in your organization. Uninstalling the Slack integration # To uninstall the Slack integration, open your organization Integrations , page Slack , then click Uninstall Slack and confirm.", "title": "Slack integration for Security issues"}, {"location": "organizations/integrations/slack-integration/#organization-slack-integration-for-security-issues", "text": "The organization Slack integration for Security issues sends notifications to a Slack channel of your choice whenever Codacy detects new critical Security issues in the default branch of any repository in your organization.", "title": "Organization Slack integration for Security issues"}, {"location": "organizations/integrations/slack-integration/#installing-the-slack-integration", "text": "To install the Slack integration: On Slack : Access the Incoming WebHooks page on the App Directory of your Slack account. Select the channel where you want to receive notifications and click Add Incoming WebHooks Integration . Copy the Incoming WebHook URL (it starts with https://hooks.slack.com/services/ ). On Codacy : Open your organization Integrations , page Slack . Paste the Incoming WebHook URL in the field and click Install Slack . Once the Slack integration is installed, Codacy sends a confirmation message to the Slack channel you configured when creating the Incoming WebHook. From there on, Codacy notifies you on the same channel whenever a new critical Security issue is detected in the default branch of any repository in your organization.", "title": "Installing the Slack integration"}, {"location": "organizations/integrations/slack-integration/#uninstalling-the-slack-integration", "text": "To uninstall the Slack integration, open your organization Integrations , page Slack , then click Uninstall Slack and confirm.", "title": "Uninstalling the Slack integration"}, {"location": "release-notes/", "text": "Codacy release notes # This section contains the release notes for Codacy Cloud and Codacy Self-hosted. For product updates that are in progress or planned visit the Codacy public roadmap instead . Tip Subscribe to this RSS feed using your favorite news aggregator to receive notifications when there are new Codacy release notes. Codacy Cloud release notes # 2024 Cloud July 2024 Cloud June 2024 Cloud May 2024 Cloud April 2024 Cloud March 2024 Cloud February 2024 Cloud January 2024 Discontinuation of SSH keys for GitHub repositories January 15, 2024 2023 Cloud December 2023 Cloud November 2023 Rollout of new Coverage engine November 23, 2023 Removal of Jira, Slack, and Webhooks repository integrations November 13, 2023 Cloud October 2023 Deprecation of CSSLint, JSHint, Faux Pas, Tailor, TSLint October 25, 2023 Deprecation of bundler-audit October 13, 2023 Cloud September 2023 Cloud August 2023 Cloud July 2023 Cloud June 2023 Cloud May 2023 Cloud April 2023 Cloud March 2023 Cloud February 2023 Cloud January 2023 2022 Cloud December 2022 Cloud November 2022 Cloud October 2022 Cloud September 2022 Cloud August 2022 Cloud July 2022 Cloud June 2022 Cloud May 2022 Cloud April 2022 Cloud March 2022 Adding ESLint 8 as a supported tool March 31, 2022 Cloud February 2022 Removal of PMD (Legacy) February 16, 2022 Cloud January 2022 2021 Cloud December 2021 Cloud November 2021 Cloud October 2021 Cloud September 2021 End of support for legacy manual organizations November 2, 2021 Cloud August 2021 Performing scheduled database maintenance July 3, 2021 2020 Deprecating HTTP headers for API tokens April 1, 2020 Removal of NodeSecurity, GoLint, and SCSS Lint March 9, 2020 Codacy now supports GitHub Apps February 2, 2020 2019 Cloud November 15, 2019 Cloud October 30, 2019 Cloud September 5, 2019 Cloud August 7, 2019 Cloud June 18, 2019 Cloud May 20, 2019 Cloud May 5, 2019 Cloud April 8, 2019 Cloud March 29, 2019 Bitbucket changes February 18, 2019 Cloud January 2, 2019 2018 Cloud November 16, 2018 Cloud November 2, 2018 Cloud October 19, 2018 Cloud July 23, 2018 Codacy Self-hosted release notes # v14 v14.0.0 (June 26, 2024) v13 v13.0.0 (November 23, 2023) v12 v12.0.0 (July 20, 2023) v11 v11.0.0 (April 20, 2023) v10 v10.0.0 (February 3, 2023) v9 v9.0.0 (September 23, 2022) v8 v8.1.0 (June 17, 2022) v8.0.0 (May 12, 2022) v7 v7.0.0 (April 4, 2022) v6 v6.0.0 (March 2, 2022) v5 v5.1.0 (January 6, 2022) v5.0.0 (December 17, 2021) v4 v4.4.0 (October 12, 2021) v4.3.0 (September 16, 2021) v4.2.0 (August 31, 2021) v4.1.0 (July 6, 2021) v4.0.1 (June 2, 2021) v4.0.0 (May 18, 2021) v3 v3.5.1 (June 1, 2021) v3.5.0 (March 31, 2021) v3.4.0 (March 12, 2021) v3.3.0 (February 12, 2021) v3.2.0 (December 17, 2020) v3.1.0 (December 10, 2020) v3.0.0 (November 2, 2020) v2 v2.2.1 (October 22, 2020) v2.2.0 (October 8, 2020) v2.1.1 (September 24, 2020) v2.1.0 (September 16, 2020) v2.0.0 (August 18, 2020) v1 v1.5.0 (July 20, 2020) v1.4.0 (June 23, 2020) v1.3.0 (June 12, 2020) v1.2.0 (June 4, 2020) v1.1.0 (May 26, 2020) v1.0.1 (May 21, 2020) v1.0.0 (May 18, 2020)", "title": "Codacy release notes"}, {"location": "release-notes/#codacy-release-notes", "text": "This section contains the release notes for Codacy Cloud and Codacy Self-hosted. For product updates that are in progress or planned visit the Codacy public roadmap instead . Tip Subscribe to this RSS feed using your favorite news aggregator to receive notifications when there are new Codacy release notes.", "title": "Codacy release notes"}, {"location": "release-notes/#cloud", "text": "2024 Cloud July 2024 Cloud June 2024 Cloud May 2024 Cloud April 2024 Cloud March 2024 Cloud February 2024 Cloud January 2024 Discontinuation of SSH keys for GitHub repositories January 15, 2024 2023 Cloud December 2023 Cloud November 2023 Rollout of new Coverage engine November 23, 2023 Removal of Jira, Slack, and Webhooks repository integrations November 13, 2023 Cloud October 2023 Deprecation of CSSLint, JSHint, Faux Pas, Tailor, TSLint October 25, 2023 Deprecation of bundler-audit October 13, 2023 Cloud September 2023 Cloud August 2023 Cloud July 2023 Cloud June 2023 Cloud May 2023 Cloud April 2023 Cloud March 2023 Cloud February 2023 Cloud January 2023 2022 Cloud December 2022 Cloud November 2022 Cloud October 2022 Cloud September 2022 Cloud August 2022 Cloud July 2022 Cloud June 2022 Cloud May 2022 Cloud April 2022 Cloud March 2022 Adding ESLint 8 as a supported tool March 31, 2022 Cloud February 2022 Removal of PMD (Legacy) February 16, 2022 Cloud January 2022 2021 Cloud December 2021 Cloud November 2021 Cloud October 2021 Cloud September 2021 End of support for legacy manual organizations November 2, 2021 Cloud August 2021 Performing scheduled database maintenance July 3, 2021 2020 Deprecating HTTP headers for API tokens April 1, 2020 Removal of NodeSecurity, GoLint, and SCSS Lint March 9, 2020 Codacy now supports GitHub Apps February 2, 2020 2019 Cloud November 15, 2019 Cloud October 30, 2019 Cloud September 5, 2019 Cloud August 7, 2019 Cloud June 18, 2019 Cloud May 20, 2019 Cloud May 5, 2019 Cloud April 8, 2019 Cloud March 29, 2019 Bitbucket changes February 18, 2019 Cloud January 2, 2019 2018 Cloud November 16, 2018 Cloud November 2, 2018 Cloud October 19, 2018 Cloud July 23, 2018", "title": "Codacy Cloud release notes"}, {"location": "release-notes/#self-hosted", "text": "v14 v14.0.0 (June 26, 2024) v13 v13.0.0 (November 23, 2023) v12 v12.0.0 (July 20, 2023) v11 v11.0.0 (April 20, 2023) v10 v10.0.0 (February 3, 2023) v9 v9.0.0 (September 23, 2022) v8 v8.1.0 (June 17, 2022) v8.0.0 (May 12, 2022) v7 v7.0.0 (April 4, 2022) v6 v6.0.0 (March 2, 2022) v5 v5.1.0 (January 6, 2022) v5.0.0 (December 17, 2021) v4 v4.4.0 (October 12, 2021) v4.3.0 (September 16, 2021) v4.2.0 (August 31, 2021) v4.1.0 (July 6, 2021) v4.0.1 (June 2, 2021) v4.0.0 (May 18, 2021) v3 v3.5.1 (June 1, 2021) v3.5.0 (March 31, 2021) v3.4.0 (March 12, 2021) v3.3.0 (February 12, 2021) v3.2.0 (December 17, 2020) v3.1.0 (December 10, 2020) v3.0.0 (November 2, 2020) v2 v2.2.1 (October 22, 2020) v2.2.0 (October 8, 2020) v2.1.1 (September 24, 2020) v2.1.0 (September 16, 2020) v2.0.0 (August 18, 2020) v1 v1.5.0 (July 20, 2020) v1.4.0 (June 23, 2020) v1.3.0 (June 12, 2020) v1.2.0 (June 4, 2020) v1.1.0 (May 26, 2020) v1.0.1 (May 21, 2020) v1.0.0 (May 18, 2020)", "title": "Codacy Self-hosted release notes"}, {"location": "repositories/commits/", "text": "Quality Commits page # The Quality Commits page displays an overview of the commits in your repository, such as the analysis status and the code quality metrics for each commit. This allows you to monitor the evolution of the code quality per commit in your repository. By default, the page lists the commits on the main branch of your repository, but if you have more than one branch enabled you can use the drop-down list at the top of the page to display commits on other branches. Click a specific commit to see detailed information about the code quality changes introduced by that commit. The next sections describe each area of the commit detail page. Commit status # This area displays the information that identifies the commit (commit message, committer, SHA hash, and last updated date), as well as: A link to the commit on your Git provider A link to reanalyze the commit , present when the committer is part of your organization A link to view analysis logs Commit quality overview # This area displays the quality gate status for the commit and the code quality metrics with a gate set up : The quality gate status is either Up to quality standards or Not up to quality standards depending on the quality gate rules for your repository. If there are no gate rules enabled for commits, the status is always Up to quality standards . The variation introduced by the commit is displayed either as a positive or negative variation , or no variation (represented by = ) for code quality metrics with a gate set up : Issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Coverage variation: Changes in code coverage percentage compared with the parent commit Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ). Note Learn how Codacy calculates the code quality metrics in more detail: Which code quality metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the quality gate rules for your repository: Green: The metric passes the quality gate Red: The metric fails the quality gate Gray: The metric has no value Note If you change the quality gate rules you must reanalyze the commit to update the metrics and optionally re-upload the Coverage report if you also changed the coverage gate rules. Issues tab # The Issues tab displays the lists of issues that the commit creates or fixes. Use the sidebar filters to filter the list by new issues (including issues of specific severity or category), issues within a specific file, fixed issues, potential new issues, or potential fixed issues . Click the title of an issue card to expand it and see the following information: The committer and date of the commit that introduced the issue, if available The estimated time to fix the issue What the issue is and how to solve it The tool that reported the issue and the related code pattern To ignore or manage an issue , click the associated options in the menu. Potential issues # Codacy may label some issues as potential , which means that the code analysis detected these issues in lines of code that weren't changed by the analyzed commit. This highlights potential consequences in other parts of your codebase. The following are example situations that can lead to potential issues: The issue was either created or fixed in the current commit, but the static code analysis tools reported the issue on a line that didn't change in the commit. For example, if you remove the line containing the declaration of a variable you may get an \"undeclared variable\" issue in other lines that use that variable. If a file had more than 50 issues reported by the same tool and you push a new commit that fixes some of these issues, Codacy will report more issues until the limit of 50 issues. These issues will be potential issues if they're outside the lines of code changed in the new commit. Note If you're using GitHub you may see annotations for potential issues reported under Unchanged files with check annotations on the Files changed tab of your pull requests. This happens when Codacy reports potential issues in files that weren't changed in your pull request. Read more about this GitHub feature . Duplication tab # The Duplication tab displays the lists of clones (duplicated code blocks) that the commit adds or fixes. You can click a clone to expand it and inspect the code. Complexity tab # The Complexity tab displays the complexity changes introduced by the commit. Use the sidebar filters to filter the list by high increase (4 or more), low increase (1 to 3), or improvement (less than 0). Note When calculating the complexity variation introduced by a commit, Codacy only considers files with a high increase in complexity. For more information, see how Codacy calculates cyclomatic complexity . Coverage tab # The Coverage tab displays a line-by-line view of the coverage variation introduced by the commit. It includes the following areas: A list of files modified by the commit, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the commit The coverage variation introduced by the commit (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line Diff tab # The Diff tab displays the code changes and issues introduced by the commit. It includes the following areas: A list of files modified by the commit, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the commit The number of new issues introduced by the commit A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. Lines with issues are highlighted according to issue severity and include a pill label with the issue type and count. Hover over the pill label to view more details or navigate to the issues. Files tab # The Files tab displays the variation of the following code quality metrics that the commit introduces to the files in your repository, displayed either as a positive or negative variation , or no variation (represented by = ): New issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Coverage variation: Changes in code coverage percentage compared with the parent commit Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ). Viewing analysis logs # Analysis logs can help you identify the duration of each analysis phase and any potential issues. To access the analysis logs, click the View logs link in the commit status area. This opens a modal displaying execution times and outcomes for the tools used to analyze the commit. See also # Which metrics does Codacy calculate?", "title": "Quality Commits page"}, {"location": "repositories/commits/#quality-commits-page", "text": "The Quality Commits page displays an overview of the commits in your repository, such as the analysis status and the code quality metrics for each commit. This allows you to monitor the evolution of the code quality per commit in your repository. By default, the page lists the commits on the main branch of your repository, but if you have more than one branch enabled you can use the drop-down list at the top of the page to display commits on other branches. Click a specific commit to see detailed information about the code quality changes introduced by that commit. The next sections describe each area of the commit detail page.", "title": "Quality Commits page"}, {"location": "repositories/commits/#status", "text": "This area displays the information that identifies the commit (commit message, committer, SHA hash, and last updated date), as well as: A link to the commit on your Git provider A link to reanalyze the commit , present when the committer is part of your organization A link to view analysis logs", "title": "Commit status"}, {"location": "repositories/commits/#quality-overview", "text": "This area displays the quality gate status for the commit and the code quality metrics with a gate set up : The quality gate status is either Up to quality standards or Not up to quality standards depending on the quality gate rules for your repository. If there are no gate rules enabled for commits, the status is always Up to quality standards . The variation introduced by the commit is displayed either as a positive or negative variation , or no variation (represented by = ) for code quality metrics with a gate set up : Issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Coverage variation: Changes in code coverage percentage compared with the parent commit Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ). Note Learn how Codacy calculates the code quality metrics in more detail: Which code quality metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the quality gate rules for your repository: Green: The metric passes the quality gate Red: The metric fails the quality gate Gray: The metric has no value Note If you change the quality gate rules you must reanalyze the commit to update the metrics and optionally re-upload the Coverage report if you also changed the coverage gate rules.", "title": "Commit quality overview"}, {"location": "repositories/commits/#issues-tabs", "text": "The Issues tab displays the lists of issues that the commit creates or fixes. Use the sidebar filters to filter the list by new issues (including issues of specific severity or category), issues within a specific file, fixed issues, potential new issues, or potential fixed issues . Click the title of an issue card to expand it and see the following information: The committer and date of the commit that introduced the issue, if available The estimated time to fix the issue What the issue is and how to solve it The tool that reported the issue and the related code pattern To ignore or manage an issue , click the associated options in the menu.", "title": "Issues tab"}, {"location": "repositories/commits/#duplication-tabs", "text": "The Duplication tab displays the lists of clones (duplicated code blocks) that the commit adds or fixes. You can click a clone to expand it and inspect the code.", "title": "Duplication tab"}, {"location": "repositories/commits/#complexity-tab", "text": "The Complexity tab displays the complexity changes introduced by the commit. Use the sidebar filters to filter the list by high increase (4 or more), low increase (1 to 3), or improvement (less than 0). Note When calculating the complexity variation introduced by a commit, Codacy only considers files with a high increase in complexity. For more information, see how Codacy calculates cyclomatic complexity .", "title": "Complexity tab"}, {"location": "repositories/commits/#coverage-tab", "text": "The Coverage tab displays a line-by-line view of the coverage variation introduced by the commit. It includes the following areas: A list of files modified by the commit, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the commit The coverage variation introduced by the commit (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line", "title": "Coverage tab"}, {"location": "repositories/commits/#diff-tab", "text": "The Diff tab displays the code changes and issues introduced by the commit. It includes the following areas: A list of files modified by the commit, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the commit The number of new issues introduced by the commit A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. Lines with issues are highlighted according to issue severity and include a pill label with the issue type and count. Hover over the pill label to view more details or navigate to the issues.", "title": "Diff tab"}, {"location": "repositories/commits/#files-tab", "text": "The Files tab displays the variation of the following code quality metrics that the commit introduces to the files in your repository, displayed either as a positive or negative variation , or no variation (represented by = ): New issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Coverage variation: Changes in code coverage percentage compared with the parent commit Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ).", "title": "Files tab"}, {"location": "repositories/commits/#viewing-analysis-logs", "text": "Analysis logs can help you identify the duration of each analysis phase and any potential issues. To access the analysis logs, click the View logs link in the commit status area. This opens a modal displaying execution times and outcomes for the tools used to analyze the commit.", "title": "Viewing analysis logs"}, {"location": "repositories/commits/#see-also", "text": "Which metrics does Codacy calculate?", "title": "See also"}, {"location": "repositories/files/", "text": "Quality Files page # The Quality Files page displays the current code quality information for each analyzed file in your enabled repository branches . By default, the page lists the files on the main branch of your repository. However, if you have more than one branch enabled , you can select other branches using the drop-down list at the top of the page. Codacy displays the following code quality metrics for each file, if available: Grade: Overall grade of the file Issues: Number of issues in the file Complexity: Cyclomatic complexity of the file Duplication: Number of duplicated code blocks in the file Coverage: Percentage of coverable source lines of code that are covered by tests Codacy displays the files in alphabetical order by default, but you can sort the list by each column to help you identify which files you should improve or refactor next. Note You can use the Codacy API to generate reports or obtain code quality metrics for the files in your repositories in a more flexible way. Use the search box to filter the list and find specific files: File details # Click a specific file to see more detailed analysis information for that file. The header of the file detail page displays the same code quality metrics as the Files page, as well as: An Ignore file link to ignore the selected file on future Codacy analysis A link to view the file on your Git provider Depending on the available analysis information for the file, Codacy displays one or more of the following tabs: Issues: Shows the annotated source code on the left-hand side and the matching list of issues and issue distribution by severity on the right-hand side. Each listed issue includes the same information and options available on the Quality Issues page . Duplication: Shows the annotated source code on the left-hand side and the matching list of duplicated code blocks and counts on the right-hand side. Each listed duplicate includes the number of clones and their locations. Coverage: Shows which lines of code are covered by tests (green background labeled with test hit count) or not covered (red background), along with the counts of coverable and covered lines and the file status with respect to the coverage goal . Why are some files missing? # The Files page only displays files in your repository that were analyzed by Codacy. This means that some of your files may be missing from the list, for example: You're viewing the incorrect branch Not all files may exist in all branches of your repositories. Make sure that you're displaying files for the correct branch. The file might be ignored The Files page doesn't display ignored files that aren't meant to be analyzed, including the files that Codacy ignores by default . The file has an extension that is not on the list of supported extensions Codacy supports a list of file extensions associated with each language. Codacy doesn't analyze or display files with extensions that aren't associated with a language. The file might be too big Codacy doesn't analyze or display files that are over a certain size. Read more details for information on how to overcome this limit. See also # Which metrics does Codacy calculate? Using the Codacy API to obtain code quality metrics for files", "title": "Quality Files page"}, {"location": "repositories/files/#quality-files-page", "text": "The Quality Files page displays the current code quality information for each analyzed file in your enabled repository branches . By default, the page lists the files on the main branch of your repository. However, if you have more than one branch enabled , you can select other branches using the drop-down list at the top of the page. Codacy displays the following code quality metrics for each file, if available: Grade: Overall grade of the file Issues: Number of issues in the file Complexity: Cyclomatic complexity of the file Duplication: Number of duplicated code blocks in the file Coverage: Percentage of coverable source lines of code that are covered by tests Codacy displays the files in alphabetical order by default, but you can sort the list by each column to help you identify which files you should improve or refactor next. Note You can use the Codacy API to generate reports or obtain code quality metrics for the files in your repositories in a more flexible way. Use the search box to filter the list and find specific files:", "title": "Quality Files page"}, {"location": "repositories/files/#file-details", "text": "Click a specific file to see more detailed analysis information for that file. The header of the file detail page displays the same code quality metrics as the Files page, as well as: An Ignore file link to ignore the selected file on future Codacy analysis A link to view the file on your Git provider Depending on the available analysis information for the file, Codacy displays one or more of the following tabs: Issues: Shows the annotated source code on the left-hand side and the matching list of issues and issue distribution by severity on the right-hand side. Each listed issue includes the same information and options available on the Quality Issues page . Duplication: Shows the annotated source code on the left-hand side and the matching list of duplicated code blocks and counts on the right-hand side. Each listed duplicate includes the number of clones and their locations. Coverage: Shows which lines of code are covered by tests (green background labeled with test hit count) or not covered (red background), along with the counts of coverable and covered lines and the file status with respect to the coverage goal .", "title": "File details"}, {"location": "repositories/files/#missing-files", "text": "The Files page only displays files in your repository that were analyzed by Codacy. This means that some of your files may be missing from the list, for example: You're viewing the incorrect branch Not all files may exist in all branches of your repositories. Make sure that you're displaying files for the correct branch. The file might be ignored The Files page doesn't display ignored files that aren't meant to be analyzed, including the files that Codacy ignores by default . The file has an extension that is not on the list of supported extensions Codacy supports a list of file extensions associated with each language. Codacy doesn't analyze or display files with extensions that aren't associated with a language. The file might be too big Codacy doesn't analyze or display files that are over a certain size. Read more details for information on how to overcome this limit.", "title": "Why are some files missing?"}, {"location": "repositories/files/#see-also", "text": "Which metrics does Codacy calculate? Using the Codacy API to obtain code quality metrics for files", "title": "See also"}, {"location": "repositories/issues/", "text": "Quality Issues page # The Quality Issues page lists all the issues that Codacy detected in your repository, including the severity level and category of each issue. By default, the page lists the issues on the main branch of your repository but if you have more than one branch enabled you can use the drop-down list at the top of the page to display issues on other branches. Note You can use the Codacy API to generate reports or obtain information about the current issues in your repositories in a more flexible way. Click the title of an issue card to expand it and see the following information: The committer and date of the commit that introduced the issue, if available The estimated time to fix the issue What the issue is and how to solve it The tool that reported the issue and the related code pattern Filtering issues # Filter the list of issues to find specific issues, such as the issues with the highest severity or security issues. The list of code patterns with issues is always visible on the left side of the page. Click a code pattern to filter the list of issues by that pattern. You can moreover define one or more of the following filters: Language: Programming language of the file where the issues were detected Severity level: Potential impact of the issues: Critical (red): The most dangerous issues that you should prioritize fixing since they identify code that's susceptible to serious problems regarding security and compatibility Medium (yellow): You should check out these issues, as they're based on coding standards and conventions Minor (blue): The least critical issues, such as most code style issues Issue category: One of the following types of issue: Code style: Code formatting and syntax problems, such as variable names style and enforcing the use of brackets and quotation marks Error prone: Code that may hide bugs and language keywords that should be used with caution, such as the operator == in JavaScript or Option.get in Scala Code complexity: High complexity methods and classes that should be refactored Performance: Code that can have performance problems Compatibility: Mainly for frontend code, compatibility problems across different browser versions Unused code: Unused variables and methods, code that can't be reached Security: Potential security vulnerabilities, including hard-coded passwords and keys (secret scanning), vulnerable dependencies (software composition analysis or SCA), and insecure code patterns (static application security testing or SAST). For more information, see the complete list of security issue categories Documentation: Methods and classes that don't have the correct comment annotations Best practice: Code that doesn't follow the recommended coding standards and best practices Comprehensibility: Code that can be difficult to understand and modify Author: Commit author that introduced the issue on the code Note Each code pattern has a pre-defined severity level and at the moment Codacy doesn't support customizing that information. Ignoring and managing issues # Organization admins can manage access to this feature Use the options in the menu of each issue to: Ignore the issue and hide it from the list. Codacy will no longer report the issue after the next analysis of your repository. For example, you can ignore issues that you disagree with because: Your team won't tackle the issues in the immediate future The issue isn't relevant in the specific context of your code The issue is a false positive See how to restore ignored issues . Tip Organization admins can configure who is allowed to ignore issues . Disable the code pattern that detected the issue. Codacy will stop using that pattern after the next analysis of your repository, so be sure that you're no longer interested in identifying similar issues. To re-enable patterns use the Code patterns page . Note If you're using a custom configuration file , you must manage patterns manually on your configuration file. If your repository is following an organization coding standard , disabling the code pattern causes the repository to stop following the coding standard. In this case, Codacy asks for your confirmation before accepting the changes and then copies the coding standard configurations to your repository, so you can customize them. View the file where the issue was detected. Ignore the file where the issue was detected. Codacy will no longer analyze that file on your repository, so be sure that you're no longer interested in identifying any type of issues on that file. To remove an ignored file use the Ignored Files tab in your repository settings. Restoring ignored issues # To see the list of ignored issues, click the Ignored tab. To restore an ignored issue, select Unignore issue from the options menu: Fixing issues automatically # This section applies to GitHub repositories only If Codacy detects code patterns with suggested fixes, a Fix issues button appears above the issue list. In this case, Codacy generates a patch that enables you to solve all resolvable issues. To apply this patch to the default branch, do the following: Click the button Fix issues to open a modal with a patch that addresses all resolvable issues. Copy the patch content to the clipboard. Create a new branch from the default branch. Apply the patch from the repository's root directory, for example with the pbpaste | patch command. Note These changes are automatically generated. Review them to make sure they're correct. Push the new branch to the repository. On GitHub, create a pull request from the new branch to the default branch. See also # Which metrics does Codacy calculate? Using the Codacy API to obtain current issues in repositories", "title": "Quality Issues page"}, {"location": "repositories/issues/#quality-issues-page", "text": "The Quality Issues page lists all the issues that Codacy detected in your repository, including the severity level and category of each issue. By default, the page lists the issues on the main branch of your repository but if you have more than one branch enabled you can use the drop-down list at the top of the page to display issues on other branches. Note You can use the Codacy API to generate reports or obtain information about the current issues in your repositories in a more flexible way. Click the title of an issue card to expand it and see the following information: The committer and date of the commit that introduced the issue, if available The estimated time to fix the issue What the issue is and how to solve it The tool that reported the issue and the related code pattern", "title": "Quality Issues page"}, {"location": "repositories/issues/#filtering-issues", "text": "Filter the list of issues to find specific issues, such as the issues with the highest severity or security issues. The list of code patterns with issues is always visible on the left side of the page. Click a code pattern to filter the list of issues by that pattern. You can moreover define one or more of the following filters: Language: Programming language of the file where the issues were detected Severity level: Potential impact of the issues: Critical (red): The most dangerous issues that you should prioritize fixing since they identify code that's susceptible to serious problems regarding security and compatibility Medium (yellow): You should check out these issues, as they're based on coding standards and conventions Minor (blue): The least critical issues, such as most code style issues Issue category: One of the following types of issue: Code style: Code formatting and syntax problems, such as variable names style and enforcing the use of brackets and quotation marks Error prone: Code that may hide bugs and language keywords that should be used with caution, such as the operator == in JavaScript or Option.get in Scala Code complexity: High complexity methods and classes that should be refactored Performance: Code that can have performance problems Compatibility: Mainly for frontend code, compatibility problems across different browser versions Unused code: Unused variables and methods, code that can't be reached Security: Potential security vulnerabilities, including hard-coded passwords and keys (secret scanning), vulnerable dependencies (software composition analysis or SCA), and insecure code patterns (static application security testing or SAST). For more information, see the complete list of security issue categories Documentation: Methods and classes that don't have the correct comment annotations Best practice: Code that doesn't follow the recommended coding standards and best practices Comprehensibility: Code that can be difficult to understand and modify Author: Commit author that introduced the issue on the code Note Each code pattern has a pre-defined severity level and at the moment Codacy doesn't support customizing that information.", "title": "Filtering issues"}, {"location": "repositories/issues/#ignoring-and-managing-issues", "text": "Organization admins can manage access to this feature Use the options in the menu of each issue to: Ignore the issue and hide it from the list. Codacy will no longer report the issue after the next analysis of your repository. For example, you can ignore issues that you disagree with because: Your team won't tackle the issues in the immediate future The issue isn't relevant in the specific context of your code The issue is a false positive See how to restore ignored issues . Tip Organization admins can configure who is allowed to ignore issues . Disable the code pattern that detected the issue. Codacy will stop using that pattern after the next analysis of your repository, so be sure that you're no longer interested in identifying similar issues. To re-enable patterns use the Code patterns page . Note If you're using a custom configuration file , you must manage patterns manually on your configuration file. If your repository is following an organization coding standard , disabling the code pattern causes the repository to stop following the coding standard. In this case, Codacy asks for your confirmation before accepting the changes and then copies the coding standard configurations to your repository, so you can customize them. View the file where the issue was detected. Ignore the file where the issue was detected. Codacy will no longer analyze that file on your repository, so be sure that you're no longer interested in identifying any type of issues on that file. To remove an ignored file use the Ignored Files tab in your repository settings.", "title": "Ignoring and managing issues"}, {"location": "repositories/issues/#restoring-ignored-issues", "text": "To see the list of ignored issues, click the Ignored tab. To restore an ignored issue, select Unignore issue from the options menu:", "title": "Restoring ignored issues"}, {"location": "repositories/issues/#fixing-issues-automatically", "text": "This section applies to GitHub repositories only If Codacy detects code patterns with suggested fixes, a Fix issues button appears above the issue list. In this case, Codacy generates a patch that enables you to solve all resolvable issues. To apply this patch to the default branch, do the following: Click the button Fix issues to open a modal with a patch that addresses all resolvable issues. Copy the patch content to the clipboard. Create a new branch from the default branch. Apply the patch from the repository's root directory, for example with the pbpaste | patch command. Note These changes are automatically generated. Review them to make sure they're correct. Push the new branch to the repository. On GitHub, create a pull request from the new branch to the default branch.", "title": "Fixing issues automatically"}, {"location": "repositories/issues/#see-also", "text": "Which metrics does Codacy calculate? Using the Codacy API to obtain current issues in repositories", "title": "See also"}, {"location": "repositories/pull-requests/", "text": "Quality Pull Requests page # The Quality Pull Requests page displays an overview of the pull requests in your repository, such as the analysis status and the code quality metrics for each pull request. This allows you to monitor the code quality of the work in progress in your repository. By default, the page lists open pull requests, but you can click the Closed tab at the top of the list to display the closed pull requests. Click a specific pull request to see detailed information about the code quality changes introduced by that pull request. The next sections describe each area of the pull request detail page. Pull request status # This area displays the information that identifies the pull request (name, author, head and base branches, and last updated date), as well as: A link to the pull request on your Git provider A link to reanalyze the latest pull request commit , present when the committer is part of your organization A link to view analysis logs Pull request quality overview # This area displays the quality gate status for the pull request and the code quality metrics with a gate set up : The quality gate status is either Up to quality standards or Not up to quality standards depending on the quality gate rules for your repository. If there are no gate rules enabled for pull requests, the status is always Up to quality standards . The variation introduced by the pull request is displayed either as a positive or negative variation , no variation (represented by = ), or not applicable (represented by \u2205 ) for code quality metrics with a gate set up : Issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Diff coverage: Code coverage of the coverable lines affected by the pull request, or \u2205 (not applicable) if there are no coverable lines Coverage variation: Changes in code coverage percentage compared with the target branch Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ). Note Learn how Codacy calculates the code quality metrics in more detail: Which code quality metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the quality gate rules for your repository: Green: The metric passes the quality gate Red: The metric fails the quality gate Gray: The metric has no value Note If you change the quality gate rules you must reanalyze the pull request to update the metrics and optionally re-upload the Coverage report if you also changed the coverage gate rules. Issues tab # The Issues tab displays the lists of issues that the pull request creates or fixes. Use the sidebar filters to filter the list by new issues (including issues of specific severity or category), issues within a specific file, fixed issues, potential new issues, or potential fixed issues . Click the title of an issue card to expand it and see the following information: The committer and date of the commit that introduced the issue, if available The estimated time to fix the issue What the issue is and how to solve it The tool that reported the issue and the related code pattern To ignore or manage an issue , click the associated options in the menu. Potential issues # Codacy may label some issues as potential , which means that the code analysis detected these issues in lines of code that weren't changed by the analyzed pull request. This highlights potential consequences in other parts of your codebase. The following are example situations that can lead to potential issues: The issue was either created or fixed in the current pull request, but the static code analysis tools reported the issue on a line that didn't change in the pull request. For example, if you remove the line containing the declaration of a variable you may get an \"undeclared variable\" issue in other lines that use that variable. If a file had more than 50 issues reported by the same tool and you push a new commit that fixes some of these issues, Codacy will report more issues until the limit of 50 issues. These issues will be potential issues if they're outside the lines of code changed in the new commit. Note If you're using GitHub you may see annotations for potential issues reported under Unchanged files with check annotations on the Files changed tab of your pull requests. This happens when Codacy reports potential issues in files that weren't changed in your pull request. Read more about this GitHub feature . Duplication tab # The Duplication tab displays the lists of clones (duplicated code blocks) that the pull request adds or fixes. You can click a clone to expand it and inspect the code. Complexity tab # The Complexity tab displays the complexity changes introduced by the pull request. Use the sidebar filters to filter the list by high increase (4 or more), low increase (1 to 3), or improvement (less than 0). Note When calculating the complexity variation introduced by a pull request, Codacy only considers files with a high increase in complexity. For more information, see how Codacy calculates cyclomatic complexity . Coverage tab # The Coverage tab displays a line-by-line view of the coverage variation introduced by the pull request. It includes the following areas: A list of files modified by the pull request, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the pull request The coverage variation introduced by the pull request (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line Diff tab # The Diff tab displays the code changes and issues introduced by the pull request. It includes the following areas: A list of files modified by the pull request, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the pull request The number of new issues introduced by the pull request A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. Lines with issues are highlighted according to issue severity and include a pill label with the issue type and count. Hover over the pill label to view more details or navigate to the issues. Files tab # The Files tab displays the variation of the following code quality metrics that the pull request introduces to the files in your repository, displayed either as a positive or negative variation , or no variation (represented by = ): New issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Coverage variation: Changes in code coverage percentage compared with the target branch Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ). Commits tab # The Commits tab displays an overview of each commit included in the pull request, such as the analysis status and the number of issues introduced. Click a specific commit to see detailed information about that commit . Viewing analysis logs # Analysis logs can help you track and understand the performance of the tools and the timing of analyses on your pull requests. To access these logs, click the View logs link in the pull request status area. This opens a modal with two tabs: The Quality tab displays execution times and outcomes for the tools used to analyze the latest commit of the pull request. It helps identify the duration of each analysis phase and any potential issues. The Coverage tab lists reports received for the common ancestor commit and the head commit of the pull request. It helps you spot any issues with the coverage analysis, such as missing coverage reports. Fixing issues automatically # This section applies to GitHub repositories only If Codacy detects code patterns with suggested fixes, a Fix issues button appears above the issue list. In this case, Codacy generates a patch that enables you to solve all resolvable issues. To apply this patch to the pull request, do the following: Click the button Fix issues to open a modal with a patch that addresses all resolvable issues. Copy the patch content to the clipboard. Check out the relevant branch in the local repository. Apply the patch from the repository's root directory, for example with the pbpaste | patch command. Note These changes are automatically generated. Review them to make sure they're correct. Push the changes to the repository. See also # Which metrics does Codacy calculate?", "title": "Quality Pull Requests page"}, {"location": "repositories/pull-requests/#quality-pull-requests-page", "text": "The Quality Pull Requests page displays an overview of the pull requests in your repository, such as the analysis status and the code quality metrics for each pull request. This allows you to monitor the code quality of the work in progress in your repository. By default, the page lists open pull requests, but you can click the Closed tab at the top of the list to display the closed pull requests. Click a specific pull request to see detailed information about the code quality changes introduced by that pull request. The next sections describe each area of the pull request detail page.", "title": "Quality Pull Requests page"}, {"location": "repositories/pull-requests/#status", "text": "This area displays the information that identifies the pull request (name, author, head and base branches, and last updated date), as well as: A link to the pull request on your Git provider A link to reanalyze the latest pull request commit , present when the committer is part of your organization A link to view analysis logs", "title": "Pull request status"}, {"location": "repositories/pull-requests/#quality-overview", "text": "This area displays the quality gate status for the pull request and the code quality metrics with a gate set up : The quality gate status is either Up to quality standards or Not up to quality standards depending on the quality gate rules for your repository. If there are no gate rules enabled for pull requests, the status is always Up to quality standards . The variation introduced by the pull request is displayed either as a positive or negative variation , no variation (represented by = ), or not applicable (represented by \u2205 ) for code quality metrics with a gate set up : Issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Diff coverage: Code coverage of the coverable lines affected by the pull request, or \u2205 (not applicable) if there are no coverable lines Coverage variation: Changes in code coverage percentage compared with the target branch Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ). Note Learn how Codacy calculates the code quality metrics in more detail: Which code quality metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the quality gate rules for your repository: Green: The metric passes the quality gate Red: The metric fails the quality gate Gray: The metric has no value Note If you change the quality gate rules you must reanalyze the pull request to update the metrics and optionally re-upload the Coverage report if you also changed the coverage gate rules.", "title": "Pull request quality overview"}, {"location": "repositories/pull-requests/#issues-tabs", "text": "The Issues tab displays the lists of issues that the pull request creates or fixes. Use the sidebar filters to filter the list by new issues (including issues of specific severity or category), issues within a specific file, fixed issues, potential new issues, or potential fixed issues . Click the title of an issue card to expand it and see the following information: The committer and date of the commit that introduced the issue, if available The estimated time to fix the issue What the issue is and how to solve it The tool that reported the issue and the related code pattern To ignore or manage an issue , click the associated options in the menu.", "title": "Issues tab"}, {"location": "repositories/pull-requests/#duplication-tabs", "text": "The Duplication tab displays the lists of clones (duplicated code blocks) that the pull request adds or fixes. You can click a clone to expand it and inspect the code.", "title": "Duplication tab"}, {"location": "repositories/pull-requests/#complexity-tab", "text": "The Complexity tab displays the complexity changes introduced by the pull request. Use the sidebar filters to filter the list by high increase (4 or more), low increase (1 to 3), or improvement (less than 0). Note When calculating the complexity variation introduced by a pull request, Codacy only considers files with a high increase in complexity. For more information, see how Codacy calculates cyclomatic complexity .", "title": "Complexity tab"}, {"location": "repositories/pull-requests/#coverage-tab", "text": "The Coverage tab displays a line-by-line view of the coverage variation introduced by the pull request. It includes the following areas: A list of files modified by the pull request, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the pull request The coverage variation introduced by the pull request (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line", "title": "Coverage tab"}, {"location": "repositories/pull-requests/#diff-tab", "text": "The Diff tab displays the code changes and issues introduced by the pull request. It includes the following areas: A list of files modified by the pull request, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the pull request The number of new issues introduced by the pull request A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. Lines with issues are highlighted according to issue severity and include a pill label with the issue type and count. Hover over the pill label to view more details or navigate to the issues.", "title": "Diff tab"}, {"location": "repositories/pull-requests/#files-tab", "text": "The Files tab displays the variation of the following code quality metrics that the pull request introduces to the files in your repository, displayed either as a positive or negative variation , or no variation (represented by = ): New issues: Number of new issues Duplication: Changes in the number of duplicated code blocks Complexity: Changes in code complexity Coverage variation: Changes in code coverage percentage compared with the target branch Depending on the languages being analyzed or if you haven't set up coverage for your repository , some metrics may not be calculated (represented by - ).", "title": "Files tab"}, {"location": "repositories/pull-requests/#commits-tab", "text": "The Commits tab displays an overview of each commit included in the pull request, such as the analysis status and the number of issues introduced. Click a specific commit to see detailed information about that commit .", "title": "Commits tab"}, {"location": "repositories/pull-requests/#viewing-analysis-logs", "text": "Analysis logs can help you track and understand the performance of the tools and the timing of analyses on your pull requests. To access these logs, click the View logs link in the pull request status area. This opens a modal with two tabs: The Quality tab displays execution times and outcomes for the tools used to analyze the latest commit of the pull request. It helps identify the duration of each analysis phase and any potential issues. The Coverage tab lists reports received for the common ancestor commit and the head commit of the pull request. It helps you spot any issues with the coverage analysis, such as missing coverage reports.", "title": "Viewing analysis logs"}, {"location": "repositories/pull-requests/#fixing-issues-automatically", "text": "This section applies to GitHub repositories only If Codacy detects code patterns with suggested fixes, a Fix issues button appears above the issue list. In this case, Codacy generates a patch that enables you to solve all resolvable issues. To apply this patch to the pull request, do the following: Click the button Fix issues to open a modal with a patch that addresses all resolvable issues. Copy the patch content to the clipboard. Check out the relevant branch in the local repository. Apply the patch from the repository's root directory, for example with the pbpaste | patch command. Note These changes are automatically generated. Review them to make sure they're correct. Push the changes to the repository.", "title": "Fixing issues automatically"}, {"location": "repositories/pull-requests/#see-also", "text": "Which metrics does Codacy calculate?", "title": "See also"}, {"location": "repositories/repository-dashboard/", "text": "Quality Repository Dashboard # The Quality Repository Dashboard provides an overview of the repository code quality and items that require your attention. To access your Repository Dashboard, select a repository from the Repositories list and select Dashboard on the left navigation sidebar. Tip You can share the URL of the Repository Dashboard for your public repositories to allow other people to see your repository code quality metrics, even if they aren't registered on Codacy. The top of the Repository Dashboard displays: The name and code quality grade of the repository A drop-down list that selects which branch of your repository to display on the dashboard On the Repository Dashboard you have the following areas to help you monitor your repository: Quality evolution chart Issues breakdown Coverage Open pull requests The following sections provide a detailed overview of each dashboard area. Note You can use the Codacy API to generate reports or obtain information about the code quality of your repositories in a more flexible way. For more information see the list of available API endpoints and the following examples: Obtaining current issues in repositories Obtaining code quality metrics for files Quality evolution chart # The Quality evolution chart displays the evolution of the repository code quality regarding issues , complex files , duplication , and code coverage . Click on Last 3 months , Last 31 days , or Last 7 days to select the time interval of the historical data to display on the chart. Each tab displays the following information for the corresponding metric: A green or red indicator depending if the metric is within the acceptable quality level or not The current value The variation of the value introduced by the last commit Note The coverage tab only displays a value if Codacy received coverage data for the most recent commit. This is because one commit can easily change the size or number of files on the repository, or even remove some files that had coverage information. The chart also displays the trendline based on the past behavior and the quality goals defined for the repository. Issues breakdown # The Issues breakdown area displays the total number of issues found on the selected branch, as well as the distribution of issues across each code quality issue category. Click See all issues to see the full list of issues found, or click a category to see the issues in that category. If Codacy detects code patterns that have suggested fixes, a Fix issues button appears below the total issue count. Click this button to open a modal with a patch that addresses all resolvable issues, and follow the same procedure outlined on the Quality Issues page . Coverage # The Coverage area displays the percentage of lines of code on the selected branch that are covered by tests versus the coverage goal defined in the quality settings of the repository, as well as the number of files: Without coverage With coverage not up to standards (based on the coverage goal) With coverage up to standards (based on the coverage goal) Click See all files to open the list of files in the repository. Tip If you don't have coverage set up for your repository yet, the Coverage area provides you with instructions on how to add coverage for your repository . Open pull requests # The Open pull requests area displays the last updated pull requests and the split between the status of all open pull requests in your repository: Up to standards: Pull requests that meet the minimum quality levels Not up to standards: Pull requests that failed to meet at least one of the quality gate rules defined for the repository Analyzing: Pull requests currently being analyzed by Codacy Click a bar segment to display only pull requests with the corresponding status. To see the details of pull requests, click a pull request from the list or click See all pull requests to open the list of pull requests in the repository. See also # Which metrics does Codacy calculate? Using the Codacy API to obtain current issues in repositories Using the Codacy API to obtain code quality metrics for files", "title": "Quality Repository Dashboard"}, {"location": "repositories/repository-dashboard/#quality-repository-dashboard", "text": "The Quality Repository Dashboard provides an overview of the repository code quality and items that require your attention. To access your Repository Dashboard, select a repository from the Repositories list and select Dashboard on the left navigation sidebar. Tip You can share the URL of the Repository Dashboard for your public repositories to allow other people to see your repository code quality metrics, even if they aren't registered on Codacy. The top of the Repository Dashboard displays: The name and code quality grade of the repository A drop-down list that selects which branch of your repository to display on the dashboard On the Repository Dashboard you have the following areas to help you monitor your repository: Quality evolution chart Issues breakdown Coverage Open pull requests The following sections provide a detailed overview of each dashboard area. Note You can use the Codacy API to generate reports or obtain information about the code quality of your repositories in a more flexible way. For more information see the list of available API endpoints and the following examples: Obtaining current issues in repositories Obtaining code quality metrics for files", "title": "Quality Repository Dashboard"}, {"location": "repositories/repository-dashboard/#quality-evolution-chart", "text": "The Quality evolution chart displays the evolution of the repository code quality regarding issues , complex files , duplication , and code coverage . Click on Last 3 months , Last 31 days , or Last 7 days to select the time interval of the historical data to display on the chart. Each tab displays the following information for the corresponding metric: A green or red indicator depending if the metric is within the acceptable quality level or not The current value The variation of the value introduced by the last commit Note The coverage tab only displays a value if Codacy received coverage data for the most recent commit. This is because one commit can easily change the size or number of files on the repository, or even remove some files that had coverage information. The chart also displays the trendline based on the past behavior and the quality goals defined for the repository.", "title": "Quality evolution chart"}, {"location": "repositories/repository-dashboard/#issues-breakdown", "text": "The Issues breakdown area displays the total number of issues found on the selected branch, as well as the distribution of issues across each code quality issue category. Click See all issues to see the full list of issues found, or click a category to see the issues in that category. If Codacy detects code patterns that have suggested fixes, a Fix issues button appears below the total issue count. Click this button to open a modal with a patch that addresses all resolvable issues, and follow the same procedure outlined on the Quality Issues page .", "title": "Issues breakdown"}, {"location": "repositories/repository-dashboard/#coverage", "text": "The Coverage area displays the percentage of lines of code on the selected branch that are covered by tests versus the coverage goal defined in the quality settings of the repository, as well as the number of files: Without coverage With coverage not up to standards (based on the coverage goal) With coverage up to standards (based on the coverage goal) Click See all files to open the list of files in the repository. Tip If you don't have coverage set up for your repository yet, the Coverage area provides you with instructions on how to add coverage for your repository .", "title": "Coverage"}, {"location": "repositories/repository-dashboard/#open-pull-requests", "text": "The Open pull requests area displays the last updated pull requests and the split between the status of all open pull requests in your repository: Up to standards: Pull requests that meet the minimum quality levels Not up to standards: Pull requests that failed to meet at least one of the quality gate rules defined for the repository Analyzing: Pull requests currently being analyzed by Codacy Click a bar segment to display only pull requests with the corresponding status. To see the details of pull requests, click a pull request from the list or click See all pull requests to open the list of pull requests in the repository.", "title": "Open pull requests"}, {"location": "repositories/repository-dashboard/#see-also", "text": "Which metrics does Codacy calculate? Using the Codacy API to obtain current issues in repositories Using the Codacy API to obtain code quality metrics for files", "title": "See also"}, {"location": "repositories-configure/adjusting-quality-gates/", "text": "Adjusting quality gates # The quality gates of your repository configure when Codacy reports your pull requests and commits as not up to standards. When you add your repository to Codacy, it automatically follows the default gate policy for your organization . If you want to set different quality gates for the repository, create a new organization gate policy to apply to the repository. Note Although you can define custom quality gate settings for specific repositories, we recommend that you always use a gate policy defined by your organization to enforce consistent rules across multiple repositories. Depending on the result of applying the quality gate rules, Codacy updates the color of the metrics on the pull request or commit quality overview and reports the corresponding pull request status on your Git provider, if enabled. Tip Integrate Codacy with your Git workflow to report the pull request status to your Git provider and optionally block merging pull requests that aren't up to standards. To access the quality gates, open your repository Settings , tab Gates . New issues are over: Pull requests or commits are marked not up to standards if the number of issues introduced that have at least the specified severity level is higher than the set value. New security issues are over: Pull requests or commits are marked not up to standards if the number of security issues introduced is higher than the set value. Complexity is over: Pull requests or commits are marked not up to standards if the introduced complexity is higher than the set value. Duplication is over: Pull requests or commits are marked not up to standards if the number of clones introduced is higher than the set value. Coverage variation is under: Pull requests or commits are marked not up to standards if they introduce a variation to coverage lower than the set value. Tip Set this gate to -0.10% or lower. This will ensure that developers have a coverage drop margin so they aren't blocked while performing some types of code refactors To ensure that the changes in each pull request have a minimum level of coverage, use the gate Diff coverage is under instead. Diff coverage is under: Pull requests are marked not up to standards if the diff coverage of the pull request is lower than the set value or \u2205 ( not applicable ). This rule is only available for pull requests. See also # Which metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? Integrating Codacy with your Git workflow", "title": "Adjusting quality gates"}, {"location": "repositories-configure/adjusting-quality-gates/#adjusting-quality-gates", "text": "The quality gates of your repository configure when Codacy reports your pull requests and commits as not up to standards. When you add your repository to Codacy, it automatically follows the default gate policy for your organization . If you want to set different quality gates for the repository, create a new organization gate policy to apply to the repository. Note Although you can define custom quality gate settings for specific repositories, we recommend that you always use a gate policy defined by your organization to enforce consistent rules across multiple repositories. Depending on the result of applying the quality gate rules, Codacy updates the color of the metrics on the pull request or commit quality overview and reports the corresponding pull request status on your Git provider, if enabled. Tip Integrate Codacy with your Git workflow to report the pull request status to your Git provider and optionally block merging pull requests that aren't up to standards. To access the quality gates, open your repository Settings , tab Gates . New issues are over: Pull requests or commits are marked not up to standards if the number of issues introduced that have at least the specified severity level is higher than the set value. New security issues are over: Pull requests or commits are marked not up to standards if the number of security issues introduced is higher than the set value. Complexity is over: Pull requests or commits are marked not up to standards if the introduced complexity is higher than the set value. Duplication is over: Pull requests or commits are marked not up to standards if the number of clones introduced is higher than the set value. Coverage variation is under: Pull requests or commits are marked not up to standards if they introduce a variation to coverage lower than the set value. Tip Set this gate to -0.10% or lower. This will ensure that developers have a coverage drop margin so they aren't blocked while performing some types of code refactors To ensure that the changes in each pull request have a minimum level of coverage, use the gate Diff coverage is under instead. Diff coverage is under: Pull requests are marked not up to standards if the diff coverage of the pull request is lower than the set value or \u2205 ( not applicable ). This rule is only available for pull requests.", "title": "Adjusting quality gates"}, {"location": "repositories-configure/adjusting-quality-gates/#see-also", "text": "Which metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? Integrating Codacy with your Git workflow", "title": "See also"}, {"location": "repositories-configure/adjusting-quality-goals/", "text": "Adjusting quality goals # Adjust the quality goals to help you monitor the progress of the code quality in your repository dashboard, and configure which files Codacy considers complex or duplicated. Codacy displays the quality goals as dashed lines on the quality evolution chart to help you monitor the progress and overall quality status of your repository. To access the quality goals, open your repository Settings , tab Goals . The following screenshot displays the default configuration values: Issues are over: Defines the threshold displayed on the tab Issues of the quality evolution chart. Complexity is over: Defines the threshold displayed on the tab Complexity of the quality evolution chart. File is complex when over: A file is considered complex when its complexity is over this value. Duplication is over: Defines the threshold displayed on the tab Duplication of the quality evolution chart. File is duplicate when over: A file is considered duplicated when it has more clones than this value. Coverage is under: Defines the threshold displayed on the tab Coverage of the quality evolution chart. See also # Which metrics does Codacy calculate?", "title": "Adjusting quality goals"}, {"location": "repositories-configure/adjusting-quality-goals/#adjusting-quality-goals", "text": "Adjust the quality goals to help you monitor the progress of the code quality in your repository dashboard, and configure which files Codacy considers complex or duplicated. Codacy displays the quality goals as dashed lines on the quality evolution chart to help you monitor the progress and overall quality status of your repository. To access the quality goals, open your repository Settings , tab Goals . The following screenshot displays the default configuration values: Issues are over: Defines the threshold displayed on the tab Issues of the quality evolution chart. Complexity is over: Defines the threshold displayed on the tab Complexity of the quality evolution chart. File is complex when over: A file is considered complex when its complexity is over this value. Duplication is over: Defines the threshold displayed on the tab Duplication of the quality evolution chart. File is duplicate when over: A file is considered duplicated when it has more clones than this value. Coverage is under: Defines the threshold displayed on the tab Coverage of the quality evolution chart.", "title": "Adjusting quality goals"}, {"location": "repositories-configure/adjusting-quality-goals/#see-also", "text": "Which metrics does Codacy calculate?", "title": "See also"}, {"location": "repositories-configure/codacy-configuration-file/", "text": "Codacy configuration file # Codacy supports configuring certain advanced features through a configuration file, such as: Ignoring files globally, for duplication, or a specific tool Including specific ignored files in the analysis Adjusting tool-specific configurations Configuring a specific repository directory on which to start the analysis Configuring the languages that Codacy analyzes in your repository: Adding custom file extensions to languages Disabling the analysis of a specific language Using a Codacy configuration file # Important If your repository has a Codacy configuration file, the Ignored files settings defined on the Codacy UI don't apply and you must ignore files using the configuration file instead. Codacy always uses the configuration file in the default branch . New settings added to the Codacy configuration file by a pull request are also considered for the pull request analysis, but the existing configuration in the default branch takes precedence. For example, if a pull request removes an ignored path from the Codacy configuration file, any matching files will stay ignored until that pull request is merged into the default branch. To use a Codacy configuration file: Create a text file with the name .codacy.yml or .codacy.yaml on the root of your repository. The file must start with a line containing a triple dash ( --- ). Add your settings to the configuration file based on the example template below. If you defined any Ignored files settings for the repository, make sure you add those settings to the Codacy configuration file. --- engines : rubocop : exclude_paths : - \"config/test.yml\" base_sub_dir : \"test/baseDir\" duplication : exclude_paths : - \"config/test.yml\" config : languages : - \"ruby\" languages : css : extensions : - \".scss\" python : enabled : false exclude_paths : - \".bundle/**\" - \"spec/**/*\" - \"benchmarks/**/*\" - \"**.min.js\" - \"**/tests/**\" include_paths : - \"**/tests/integration/**\" Optionally, validate the syntax of your configuration file with the Codacy Analysis CLI by running the following command in the same folder as the Codacy configuration file: codacy-analysis-cli validate-configuration --directory ` pwd ` Ignoring files using a Codacy configuration file # The Codacy configuration file gives you more flexibility in ignoring or excluding files from the Codacy analysis. Note To exclude files from coverage analysis only, you must ignore them directly in the tool you're using to generate coverage reports and ensure that the reports you upload to Codacy don't include coverage information for those files. Syntax for ignoring files # To ignore files using a Codacy configuration file, you must define one or more patterns under exclude_paths using the Java glob syntax : Example pattern Ignored files test/README.md The file test/README.md test/* All files in the root of test test/** All files and directories inside test test/**/* All files inside sub-directories of test **.resource All .resource files across all your repository **/*.resource All .resource files in all directories and sub-directories For example: --- exclude_paths : - \"test/README.md\" - \"**/*.resource\" Including specific files using a Codacy configuration file # The Codacy configuration file allows you to explicitly specify files or directories to include in the analysis. This is particularly useful for bypassing files or directories that are ignored by default or specified in exclude_paths . Note If both exclude_paths and include_paths are defined, include_paths will specify exceptions to the exclusions defined in exclude_paths . Syntax for including files # To include specific files using a Codacy configuration file, you must define one or more patterns under include_paths using the same syntax as exclude_paths . For example: --- exclude_paths : - \"lib*/**\" include_paths : - \"lib-a/**\" - \"libs/**\" In this example, while all directories matching lib* are excluded, lib-a is specifically included for analysis, as well as any files within libs . Adjusting tool configurations # Note The Codacy configuration file lets you configure tools , but you can't enable or disable them. A tool can only be enabled or disabled on the Code patterns page by users with the necessary permissions . Which tools can be configured and which name should I use? # You can use the Codacy configuration file to configure all tools supported by Codacy except the client-side tools . The following are the tool names that must be used in the Codacy configuration file: ameba bandit brakeman checkov checkstyle codacy-scalameta-pro codenarc coffeelint cppcheck credo dartanalyzer detekt eslint-8 flawfinder hadolint jacksonlinter markdownlint phpcs phpmd pmd prospector psscriptanalyzer pylintpython3 remark-lint revive rubocop scalastyle semgrep shellcheck sonarcsharp sonarvb spectral SQLint stylelint swiftlint trivy tsqllint The following names are deprecated and shouldn't be used, although they're still accepted in the Codacy configuration file: bundleraudit - The tool bundler-audit is deprecated . If you are using Semprep or Trivy instead, use the names trivy or semgrep . csslint - The tool CSSLint is deprecated . If you are using Stylelint instead, use the name stylelint . eslint - Use the name eslint-8 for ESLint . jshint , tslint - The tools JSHint and TSLint are deprecated . If you are using ESLint instead, use the name eslint-8 . pylint - Use the name pylintpython3 for Pylint . tailor - The tool Tailor is deprecated . If you are using SwiftLint instead, use the name swiftlint . Tool-specific configurations # By default, Codacy tries to detect which language is used on each source code file, and uses a set of default options for identifying duplicate blocks of code. However, some false positives may occur. The tools below support specifying the language or language version used in the source code files that you're analyzing, or tuning the duplication detection. Cppcheck # If you're using Cppcheck to analyze C or C++ source code files, add the following configuration to your Codacy configuration file to define the programming language you're using. The supported languages are c and c++ : --- engines : cppcheck : language : c++ PHP_CodeSniffer # If you're using the PHP Compatibility coding standard for PHP_CodeSniffer, add the following configuration to your Codacy configuration file to define the PHP version you're using: --- engines : phpcs : php_version : 5.5 Legacy Pylint 1.9.* # If you're using the legacy Pylint 1.9.* to analyze Python source code files, add the following configuration to your Codacy configuration file to define the Python language version you're using. The supported versions are 2 and 3 : --- engines : pylint : python_version : 2 Tip If you're using Python 3.4.* or later as your programming language, disable the tool Pylint (legacy) and enable the tool Pylint on your repository Code patterns page instead. For more information, see What's New in Pylint 2.0 . PMD CPD (Duplication) # Codacy uses PMD's Copy/Paste Detector (CPD) to identify duplicated blocks of code on the supported languages . By default, Codacy only reports duplicate code blocks that have the following minimum token length, depending on the language: Language Default minimum token length C# 50 C/C++ 50 Go 40 Java 100 JavaScript 40 Python 50 Ruby 50 SQL 100 Scala 50 Swift 50 Besides this, Codacy runs PMD CPD with the following options enabled by default: Skip lexical errors: Skip files which can't be tokenized due to invalid characters instead of aborting CPD Ignore literals: Ignore number values and string contents when comparing text Ignore annotations: Ignore language annotations when comparing text Ignore usings : Ignore using directives in C# when comparing text To use a different minimum token length or change any of the default options, add your settings to the Codacy configuration file based on the example template below. Important If you configure minTokenMatch on the Codacy configuration file, Codacy will use that value for all languages. --- engines : duplication : minTokenMatch : 20 skipLexicalErrors : false ignoreLiterals : false ignoreIdentifiers : true ignoreAnnotations : false ignoreUsings : false Configuring languages using a Codacy configuration file # You can use a Codacy configuration file to manage the languages that Codacy analyzes in your repository. Note Codacy applies the language settings from the Codacy configuration file as well as any settings defined in the Codacy UI . Adding custom file extensions # To add custom file extensions to languages using a Codacy configuration file, you must define one or more extensions under languages..extensions . Keep in mind that some tools might not work out of the box with those extensions. For example: --- languages : css : extensions : - \".scss\" Disabling analysis of a language # To disable the analysis of a specific language using a Codacy configuration file, set languages..enabled to false . The analysis is enabled by default for all languages. For example: --- languages : css : enabled : false", "title": "Codacy configuration file"}, {"location": "repositories-configure/codacy-configuration-file/#codacy-configuration-file", "text": "Codacy supports configuring certain advanced features through a configuration file, such as: Ignoring files globally, for duplication, or a specific tool Including specific ignored files in the analysis Adjusting tool-specific configurations Configuring a specific repository directory on which to start the analysis Configuring the languages that Codacy analyzes in your repository: Adding custom file extensions to languages Disabling the analysis of a specific language", "title": "Codacy configuration file"}, {"location": "repositories-configure/codacy-configuration-file/#using-a-codacy-configuration-file", "text": "Important If your repository has a Codacy configuration file, the Ignored files settings defined on the Codacy UI don't apply and you must ignore files using the configuration file instead. Codacy always uses the configuration file in the default branch . New settings added to the Codacy configuration file by a pull request are also considered for the pull request analysis, but the existing configuration in the default branch takes precedence. For example, if a pull request removes an ignored path from the Codacy configuration file, any matching files will stay ignored until that pull request is merged into the default branch. To use a Codacy configuration file: Create a text file with the name .codacy.yml or .codacy.yaml on the root of your repository. The file must start with a line containing a triple dash ( --- ). Add your settings to the configuration file based on the example template below. If you defined any Ignored files settings for the repository, make sure you add those settings to the Codacy configuration file. --- engines : rubocop : exclude_paths : - \"config/test.yml\" base_sub_dir : \"test/baseDir\" duplication : exclude_paths : - \"config/test.yml\" config : languages : - \"ruby\" languages : css : extensions : - \".scss\" python : enabled : false exclude_paths : - \".bundle/**\" - \"spec/**/*\" - \"benchmarks/**/*\" - \"**.min.js\" - \"**/tests/**\" include_paths : - \"**/tests/integration/**\" Optionally, validate the syntax of your configuration file with the Codacy Analysis CLI by running the following command in the same folder as the Codacy configuration file: codacy-analysis-cli validate-configuration --directory ` pwd `", "title": "Using a Codacy configuration file"}, {"location": "repositories-configure/codacy-configuration-file/#ignore-files", "text": "The Codacy configuration file gives you more flexibility in ignoring or excluding files from the Codacy analysis. Note To exclude files from coverage analysis only, you must ignore them directly in the tool you're using to generate coverage reports and ensure that the reports you upload to Codacy don't include coverage information for those files.", "title": "Ignoring files using a Codacy configuration file"}, {"location": "repositories-configure/codacy-configuration-file/#include-files", "text": "The Codacy configuration file allows you to explicitly specify files or directories to include in the analysis. This is particularly useful for bypassing files or directories that are ignored by default or specified in exclude_paths . Note If both exclude_paths and include_paths are defined, include_paths will specify exceptions to the exclusions defined in exclude_paths .", "title": "Including specific files using a Codacy configuration file"}, {"location": "repositories-configure/codacy-configuration-file/#tool-conf", "text": "Note The Codacy configuration file lets you configure tools , but you can't enable or disable them. A tool can only be enabled or disabled on the Code patterns page by users with the necessary permissions .", "title": "Adjusting tool configurations"}, {"location": "repositories-configure/codacy-configuration-file/#languages", "text": "You can use a Codacy configuration file to manage the languages that Codacy analyzes in your repository. Note Codacy applies the language settings from the Codacy configuration file as well as any settings defined in the Codacy UI .", "title": "Configuring languages using a Codacy configuration file"}, {"location": "repositories-configure/configuring-code-patterns/", "text": "Configuring code patterns # Organization admins can manage access to this feature By default, Codacy analyzes your repositories using a subset of the supported analysis tools and code patterns. These defaults are based on current best practices and community feedback, and you can adapt them to your needs as follows: Configuring tools and code patterns using the Codacy UI Using tool configuration files Configuring tools and code patterns using the Codacy UI # To configure the tools and code patterns for a repository using the Codacy UI: Open your repository Code patterns page. Enable or disable the tools that Codacy will use to analyze the repository. Select a tool to enable or disable its code patterns. To make it easier to find relevant patterns, use the filters above the pattern list. You can filter by issue category , status, severity level, or display only recommended code patterns. To see an explanation of the issues that a pattern detects and how to fix them, click the respective dropdown arrow. Tip To enable a group of code patterns, use the filter to select the relevant group of patterns and click the checkbox in the header of the patterns list. Codacy displays the tag New for one month next to the name of newly added code patterns. Optionally, to take the changes into account immediately, reanalyze the repository manually . Otherwise, Codacy will use the updated configuration when analyzing new commits and pull requests. Customizing applied coding standards # To apply or edit a repository's coding standards , click Customize in the Following ... section at the top of the Code patterns page. Select the coding standards that you want to follow or stop following and click Apply . Using tool configuration files # Note After activating a configuration file for a tool, Codacy uses that configuration file even if you exclude it from Codacy analysis . When using a tool configuration file alongside a coding standard , the configuration file controls the code patterns, while the coding standard controls whether the tool is enabled or disabled. Codacy supports configuration files for several static analysis tools to help you streamline your setup. To use a configuration file for a static analysis tool: Push the configuration file to the root of the default Codacy branch . Open the repository Code patterns page, select the tool of interest, and activate the toggle to use a configuration file. Note Codacy uses the version of the configuration file in the branch being analyzed . For example, if you open a pull request that includes changes to the configuration file, the analysis results take those changes into account. If Codacy analyzes a branch that doesn't include the configuration file, Codacy reverts to using the code patterns configured for the tool before you selected the option Configuration file on the Code patterns page. For performance reasons, when you update pattern settings using a configuration file, Codacy may display outdated messages for issues identified previously by those patterns. The table below lists the configuration file names that Codacy detects and supports for each tool: Tool name Languages Files detected Other info Ameba Crystal .ameba.yml Bandit Python bandit.yml , bandit.yaml , .bandit , bandit.toml , bandit.ini To solve flagged valid Python \"assert\" statements, create a bandit.yml on the root of the repository containing: skips: \\['B101'\\] Brakeman Ruby config/brakeman.yml Checkstyle Java checkstyle.xml Supports configuration file in directories other than root and can search up to 5 directories into the repository. CodeNarc Groovy .codenarcrc Credo Elixir .credo.exs , config/.credo.exs dartanalyzer Dart analysis_options.yml Customizing static analysis detekt Kotlin default-detekt-config.yml , detekt.yml Supports configuration file in directories other than root and can search up to 5 directories into the repository. ESLint JavaScript, TypeScript .eslintrc.js , .eslintrc.cjs , .eslintrc.yaml , .eslintrc.yml , .eslintrc.json Plugins configurable on the Codacy UI Other supported plugins If you're using module-level ESLint configuration files , you must also include a ESLint configuration file on the root of your repository for Codacy to detect that you're using configuration files. For example, add the following minimal .eslintrc.json configuration file: { \"root\": true } Hadolint Dockerfile .hadolint.yaml markdownlint Markdown .markdownlint.json PHP_CodeSniffer PHP phpcs.xml , phpcs.xml.dist PHP Mess Detector PHP codesize.xml , phpmd.xml , phpmd.xml.dist PMD Apex, Java, JavaScript, JSP, PL/SQL, XML, Velocity and Visualforce ruleset.xml , apex-ruleset.xml Supports configuration file in directories other than root and can search up to 5 directories into the repository. Prospector Python .prospector.yml , .prospector.yaml , prospector.yml , prospector.yaml , .landscape.yml , .landscape.yaml , landscape.yml , landscape.yaml Pylint Python pylintrc , .pylintrc Plugins remark-lint Markdown .remarkrc , .remarkrc.json , .remarkrc.yaml , .remarkrc.yml , .remarkrc.js Revive Go revive.toml RuboCop Ruby .rubocop.yml , .rubocop-codacy.yml Supports alternative configuration file .rubocop-codacy.yml for Codacy analysis, allowing exclusion of private gems. This prevents analysis issues caused by private gem references, ensuring proper validation by Codacy. Scalastyle Scala scalastyle-config.xml , scalastyle_config.xml Semgrep Apex, C++, C#, Dockerfile, Elixir, GitHub Actions, Go, Java, JavaScript, Kotlin, PHP, Python, Ruby, Rust, Scala, Shell, Swift, Terraform, TypeScript .semgrep.yaml SonarC# C# SonarLint.xml SonarVB Visual Basic SonarLint.xml Spectral AsyncAPI, OpenAPI .spectral.yaml , .spectral.yml , .spectral.json SpotBugs Java, Scala findbugs.xml , findbugs-includes.xml , findbugs-excludes.xml , spotbugs.xml , spotbugs-includes.xml , spotbugs-excludes.xml Supports configuration file in directories other than root and can search up to 5 directories into the repository. Stylelint CSS, LESS, SASS .stylelintrc , stylelint.config.js , .stylelintrc.json , .stylelintrc.yaml , .stylelintrc.yml , .stylelintrc.js Supports configuration file in directories other than root and can search up to 5 directories into the repository. SwiftLint Swift .swiftlint.yml TSQLLint Transact-SQL .tsqllintrc Note Codacy doesn't support configuration files for the following tools: aligncheck Checkov Clang-Tidy Codacy Scalameta Pro CoffeeLint Cppcheck deadcode Flawfinder Gosec Jackson Linter PSScriptAnalyzer ShellCheck SQLint Staticcheck Trivy Unity Roslyn Analyzers See also # Applying a coding standard across multiple repositories How to implement Google JavaScript style guide with Codacy", "title": "Configuring code patterns"}, {"location": "repositories-configure/configuring-code-patterns/#configuring-code-patterns", "text": "Organization admins can manage access to this feature By default, Codacy analyzes your repositories using a subset of the supported analysis tools and code patterns. These defaults are based on current best practices and community feedback, and you can adapt them to your needs as follows: Configuring tools and code patterns using the Codacy UI Using tool configuration files", "title": "Configuring code patterns"}, {"location": "repositories-configure/configuring-code-patterns/#configuring-tools-and-code-patterns-using-the-codacy-ui", "text": "To configure the tools and code patterns for a repository using the Codacy UI: Open your repository Code patterns page. Enable or disable the tools that Codacy will use to analyze the repository. Select a tool to enable or disable its code patterns. To make it easier to find relevant patterns, use the filters above the pattern list. You can filter by issue category , status, severity level, or display only recommended code patterns. To see an explanation of the issues that a pattern detects and how to fix them, click the respective dropdown arrow. Tip To enable a group of code patterns, use the filter to select the relevant group of patterns and click the checkbox in the header of the patterns list. Codacy displays the tag New for one month next to the name of newly added code patterns. Optionally, to take the changes into account immediately, reanalyze the repository manually . Otherwise, Codacy will use the updated configuration when analyzing new commits and pull requests.", "title": "Configuring tools and code patterns using the Codacy UI"}, {"location": "repositories-configure/configuring-code-patterns/#customizing-applied-coding-standards", "text": "To apply or edit a repository's coding standards , click Customize in the Following ... section at the top of the Code patterns page. Select the coding standards that you want to follow or stop following and click Apply .", "title": "Customizing applied coding standards"}, {"location": "repositories-configure/configuring-code-patterns/#using-your-own-tool-configuration-files", "text": "Note After activating a configuration file for a tool, Codacy uses that configuration file even if you exclude it from Codacy analysis . When using a tool configuration file alongside a coding standard , the configuration file controls the code patterns, while the coding standard controls whether the tool is enabled or disabled. Codacy supports configuration files for several static analysis tools to help you streamline your setup. To use a configuration file for a static analysis tool: Push the configuration file to the root of the default Codacy branch . Open the repository Code patterns page, select the tool of interest, and activate the toggle to use a configuration file. Note Codacy uses the version of the configuration file in the branch being analyzed . For example, if you open a pull request that includes changes to the configuration file, the analysis results take those changes into account. If Codacy analyzes a branch that doesn't include the configuration file, Codacy reverts to using the code patterns configured for the tool before you selected the option Configuration file on the Code patterns page. For performance reasons, when you update pattern settings using a configuration file, Codacy may display outdated messages for issues identified previously by those patterns. The table below lists the configuration file names that Codacy detects and supports for each tool: Tool name Languages Files detected Other info Ameba Crystal .ameba.yml Bandit Python bandit.yml , bandit.yaml , .bandit , bandit.toml , bandit.ini To solve flagged valid Python \"assert\" statements, create a bandit.yml on the root of the repository containing: skips: \\['B101'\\] Brakeman Ruby config/brakeman.yml Checkstyle Java checkstyle.xml Supports configuration file in directories other than root and can search up to 5 directories into the repository. CodeNarc Groovy .codenarcrc Credo Elixir .credo.exs , config/.credo.exs dartanalyzer Dart analysis_options.yml Customizing static analysis detekt Kotlin default-detekt-config.yml , detekt.yml Supports configuration file in directories other than root and can search up to 5 directories into the repository. ESLint JavaScript, TypeScript .eslintrc.js , .eslintrc.cjs , .eslintrc.yaml , .eslintrc.yml , .eslintrc.json Plugins configurable on the Codacy UI Other supported plugins If you're using module-level ESLint configuration files , you must also include a ESLint configuration file on the root of your repository for Codacy to detect that you're using configuration files. For example, add the following minimal .eslintrc.json configuration file: { \"root\": true } Hadolint Dockerfile .hadolint.yaml markdownlint Markdown .markdownlint.json PHP_CodeSniffer PHP phpcs.xml , phpcs.xml.dist PHP Mess Detector PHP codesize.xml , phpmd.xml , phpmd.xml.dist PMD Apex, Java, JavaScript, JSP, PL/SQL, XML, Velocity and Visualforce ruleset.xml , apex-ruleset.xml Supports configuration file in directories other than root and can search up to 5 directories into the repository. Prospector Python .prospector.yml , .prospector.yaml , prospector.yml , prospector.yaml , .landscape.yml , .landscape.yaml , landscape.yml , landscape.yaml Pylint Python pylintrc , .pylintrc Plugins remark-lint Markdown .remarkrc , .remarkrc.json , .remarkrc.yaml , .remarkrc.yml , .remarkrc.js Revive Go revive.toml RuboCop Ruby .rubocop.yml , .rubocop-codacy.yml Supports alternative configuration file .rubocop-codacy.yml for Codacy analysis, allowing exclusion of private gems. This prevents analysis issues caused by private gem references, ensuring proper validation by Codacy. Scalastyle Scala scalastyle-config.xml , scalastyle_config.xml Semgrep Apex, C++, C#, Dockerfile, Elixir, GitHub Actions, Go, Java, JavaScript, Kotlin, PHP, Python, Ruby, Rust, Scala, Shell, Swift, Terraform, TypeScript .semgrep.yaml SonarC# C# SonarLint.xml SonarVB Visual Basic SonarLint.xml Spectral AsyncAPI, OpenAPI .spectral.yaml , .spectral.yml , .spectral.json SpotBugs Java, Scala findbugs.xml , findbugs-includes.xml , findbugs-excludes.xml , spotbugs.xml , spotbugs-includes.xml , spotbugs-excludes.xml Supports configuration file in directories other than root and can search up to 5 directories into the repository. Stylelint CSS, LESS, SASS .stylelintrc , stylelint.config.js , .stylelintrc.json , .stylelintrc.yaml , .stylelintrc.yml , .stylelintrc.js Supports configuration file in directories other than root and can search up to 5 directories into the repository. SwiftLint Swift .swiftlint.yml TSQLLint Transact-SQL .tsqllintrc Note Codacy doesn't support configuration files for the following tools: aligncheck Checkov Clang-Tidy Codacy Scalameta Pro CoffeeLint Cppcheck deadcode Flawfinder Gosec Jackson Linter PSScriptAnalyzer ShellCheck SQLint Staticcheck Trivy Unity Roslyn Analyzers", "title": "Using tool configuration files"}, {"location": "repositories-configure/configuring-code-patterns/#see-also", "text": "Applying a coding standard across multiple repositories How to implement Google JavaScript style guide with Codacy", "title": "See also"}, {"location": "repositories-configure/ignoring-files/", "text": "Ignoring files # Organization admins can manage access to this feature In some situations, you may want to ignore or exclude files from the Codacy analysis. To exclude files from your repository analysis open your repository Settings , tab Ignored Files , and select the files you want to ignore. This view only shows the files on your main branch. Note See below the files that Codacy ignores by default . You can also ignore files using your own tool configuration files , although this depends on the option being supported by each tool. To exclude files from coverage analysis only, you must ignore them directly in the tool you're using to generate coverage reports and ensure that the reports you upload to Codacy don't include coverage information for those files. If you need more flexibility in ignoring files, use a Codacy configuration file to define a custom list of file paths to exclude . Important If your repository has a Codacy configuration file , the Ignored files settings defined on the Codacy UI don't apply and you must ignore files using the configuration file instead. Default ignored files # By default, Codacy ignores all the files that match the regular expressions below. If you need to analyze files that match these regular expressions, use a Codacy configuration file to define a custom list of file paths to include . .*[\\.-]min\\.css .*[\\.-]min\\.js .*node_modules/.* .*bower_components/.* .*vendor/.* .*third[_-]?[Pp]arty/.* .*samples?/.* .*releases?/.* .*builds?/.* .*dist/.* .*external/.* .*libs/.* .*d3\\.js .*angular(-resource|)?\\.js .*select2(-resource|)?\\.js .*-ace\\.js .*typeahead\\.js .*jquery-ui\\.js .*reveal\\.js .*three\\.js .*chart\\.js .*jquery\\.js .*underscore\\.js .*lodash\\.js .*bootstrap\\.js .*bootstrap\\.css .*font-awesome\\.css .*\\.[Dd]esigner\\.cs", "title": "Ignoring files"}, {"location": "repositories-configure/ignoring-files/#ignoring-files", "text": "Organization admins can manage access to this feature In some situations, you may want to ignore or exclude files from the Codacy analysis. To exclude files from your repository analysis open your repository Settings , tab Ignored Files , and select the files you want to ignore. This view only shows the files on your main branch. Note See below the files that Codacy ignores by default . You can also ignore files using your own tool configuration files , although this depends on the option being supported by each tool. To exclude files from coverage analysis only, you must ignore them directly in the tool you're using to generate coverage reports and ensure that the reports you upload to Codacy don't include coverage information for those files. If you need more flexibility in ignoring files, use a Codacy configuration file to define a custom list of file paths to exclude . Important If your repository has a Codacy configuration file , the Ignored files settings defined on the Codacy UI don't apply and you must ignore files using the configuration file instead.", "title": "Ignoring files"}, {"location": "repositories-configure/ignoring-files/#default-ignored-files", "text": "By default, Codacy ignores all the files that match the regular expressions below. If you need to analyze files that match these regular expressions, use a Codacy configuration file to define a custom list of file paths to include . .*[\\.-]min\\.css .*[\\.-]min\\.js .*node_modules/.* .*bower_components/.* .*vendor/.* .*third[_-]?[Pp]arty/.* .*samples?/.* .*releases?/.* .*builds?/.* .*dist/.* .*external/.* .*libs/.* .*d3\\.js .*angular(-resource|)?\\.js .*select2(-resource|)?\\.js .*-ace\\.js .*typeahead\\.js .*jquery-ui\\.js .*reveal\\.js .*three\\.js .*chart\\.js .*jquery\\.js .*underscore\\.js .*lodash\\.js .*bootstrap\\.js .*bootstrap\\.css .*font-awesome\\.css .*\\.[Dd]esigner\\.cs", "title": "Default ignored files"}, {"location": "repositories-configure/languages/", "text": "Configuring languages # Organization admins can manage access to this feature Codacy automatically detects and analyzes languages in your repository based on a list of supported file extensions. On the repository Settings , tab Languages , you can see the list of languages that Codacy detected and will include in the next analysis. By default, the analysis is enabled for all languages that Codacy detects in you repository. You can adapt this configuration to your needs as follows: Configure Codacy to include unrecognized extensions Disable the analysis of specific languages Note Codacy applies the language settings defined in the Codacy UI as well as any settings defined using a Codacy configuration file . Configuring file extensions # If your repository contains source files with extensions not supported by Codacy, associate these extensions with their respective languages to ensure Codacy analyzes them in the next analysis: Go to your repository's Settings , Languages . Add the extensions you want to be recognized for each language. Click Save changes to update your file extension settings. The updated settings will be used on the next analysis, but you can click reanalyze the latest commit of your branches now on the notification that appears at the bottom of the page to trigger an analysis immediately. Note Currently, the Semgrep static analysis tool doesn't support custom file extensions. Disabling analysis of a language # By default, Codacy analyzes all languages detected in your repository. To disable the analysis of a specific language, do the following: Go to your repository's Settings , Languages . Use the toggle next to the language to disable its analysis. Click Save changes to update your settings. The updated settings will be used on the next analysis, but you can click reanalyze the latest commit of your branches now on the notification that appears at the bottom of the page to trigger an analysis immediately.", "title": "Configuring languages"}, {"location": "repositories-configure/languages/#configuring-languages", "text": "Organization admins can manage access to this feature Codacy automatically detects and analyzes languages in your repository based on a list of supported file extensions. On the repository Settings , tab Languages , you can see the list of languages that Codacy detected and will include in the next analysis. By default, the analysis is enabled for all languages that Codacy detects in you repository. You can adapt this configuration to your needs as follows: Configure Codacy to include unrecognized extensions Disable the analysis of specific languages Note Codacy applies the language settings defined in the Codacy UI as well as any settings defined using a Codacy configuration file .", "title": "Configuring languages"}, {"location": "repositories-configure/languages/#configuring-file-extensions", "text": "If your repository contains source files with extensions not supported by Codacy, associate these extensions with their respective languages to ensure Codacy analyzes them in the next analysis: Go to your repository's Settings , Languages . Add the extensions you want to be recognized for each language. Click Save changes to update your file extension settings. The updated settings will be used on the next analysis, but you can click reanalyze the latest commit of your branches now on the notification that appears at the bottom of the page to trigger an analysis immediately. Note Currently, the Semgrep static analysis tool doesn't support custom file extensions.", "title": "Configuring file extensions"}, {"location": "repositories-configure/languages/#disable-language", "text": "By default, Codacy analyzes all languages detected in your repository. To disable the analysis of a specific language, do the following: Go to your repository's Settings , Languages . Use the toggle next to the language to disable its analysis. Click Save changes to update your settings. The updated settings will be used on the next analysis, but you can click reanalyze the latest commit of your branches now on the notification that appears at the bottom of the page to trigger an analysis immediately.", "title": "Disabling analysis of a language"}, {"location": "repositories-configure/managing-branches/", "text": "Managing branches # Organization admins can manage access to this feature Codacy automatically analyzes the default branch of your repository (typically master or main as configured on your Git provider) and loads its data first on dashboards. Codacy also supports analyzing multiple branches. Note Codacy doesn't support and skips the analysis of branches named HEAD or matching the pattern refs/heads/* , as these are Git reserved terms. To change the default branch of your repository or start analyzing other branches: Open your repository Settings , tab Branches . To enable analysis for a new branch, toggle the corresponding switch in the column Analyze . Enabling a new branch triggers an initial analysis of that branch and the analysis results and information for that branch will become available after the analysis is complete. To change the default branch on Codacy, click the corresponding Make default link that appears when you hover the column Default . Changing the default branch on Codacy doesn't change the default branch on your Git provider. Likewise, changing the default branch on your Git provider doesn't change the default branch on Codacy. Note You can only set as default branch an already enabled branch. Codacy manages pull request branches and inactive branches as follows: Pull request branches Codacy automatically analyzes branches corresponding to new pull requests and also enables the target branches if they're disabled. Inactive branches Codacy automatically disables analysis for branches that don't have any commits for more than 2 weeks, except for the main branch and pull request branches that are analyzed automatically.", "title": "Managing branches"}, {"location": "repositories-configure/managing-branches/#managing-branches", "text": "Organization admins can manage access to this feature Codacy automatically analyzes the default branch of your repository (typically master or main as configured on your Git provider) and loads its data first on dashboards. Codacy also supports analyzing multiple branches. Note Codacy doesn't support and skips the analysis of branches named HEAD or matching the pattern refs/heads/* , as these are Git reserved terms. To change the default branch of your repository or start analyzing other branches: Open your repository Settings , tab Branches . To enable analysis for a new branch, toggle the corresponding switch in the column Analyze . Enabling a new branch triggers an initial analysis of that branch and the analysis results and information for that branch will become available after the analysis is complete. To change the default branch on Codacy, click the corresponding Make default link that appears when you hover the column Default . Changing the default branch on Codacy doesn't change the default branch on your Git provider. Likewise, changing the default branch on your Git provider doesn't change the default branch on Codacy. Note You can only set as default branch an already enabled branch. Codacy manages pull request branches and inactive branches as follows: Pull request branches Codacy automatically analyzes branches corresponding to new pull requests and also enables the target branches if they're disabled. Inactive branches Codacy automatically disables analysis for branches that don't have any commits for more than 2 weeks, except for the main branch and pull request branches that are analyzed automatically.", "title": "Managing branches"}, {"location": "repositories-configure/removing-your-repository/", "text": "Removing your repository # To stop Codacy from analyzing your repository, you must remove the repository from Codacy. Removing a repository from Codacy completely removes the configurations and all data related to your repository from Codacy. This operation doesn't make any changes on your Git provider. Important To remove a repository from Codacy you must have administrator permissions for that repository on your Git provider. To delete your repository from Codacy: Open your repository Settings , tab General . Click the button Remove repository and confirm that you want to remove the repository. Note For added security, after you remove the repository from Codacy you can delete from your Git provider the Codacy resources related to that repository to prevent their reuse: Webhooks SSH keys (GitLab and Bitbucket only)", "title": "Removing your repository"}, {"location": "repositories-configure/removing-your-repository/#removing-your-repository", "text": "To stop Codacy from analyzing your repository, you must remove the repository from Codacy. Removing a repository from Codacy completely removes the configurations and all data related to your repository from Codacy. This operation doesn't make any changes on your Git provider. Important To remove a repository from Codacy you must have administrator permissions for that repository on your Git provider. To delete your repository from Codacy: Open your repository Settings , tab General . Click the button Remove repository and confirm that you want to remove the repository. Note For added security, after you remove the repository from Codacy you can delete from your Git provider the Codacy resources related to that repository to prevent their reuse: Webhooks SSH keys (GitLab and Bitbucket only)", "title": "Removing your repository"}, {"location": "repositories-configure/using-submodules/", "text": "Using submodules # Git submodules allow you to keep a Git repository as a subdirectory within another Git repository. Git submodules are helpful in maintaining a shared configuration file for your team, and then applying it to multiple Git repositories. By default, Codacy does normal Git clones that don't include submodules to ensure that we only clone necessary repositories. If your organization needs to use submodules, you can request Codacy to enable this feature for you. Important GitHub only: Your repository and the repositories that you add as submodules must belong to the same GitHub organization. Prerequisites for using submodules # Contact us at support@codacy.com asking to enable submodules on Codacy. If you're using Codacy Self-hosted , update your license . Make sure that your Git URL uses the correct protocol: GitHub: HTTPS protocol GitLab and Bitbucket: HTTPS protocol, if your submodules are public repositories SSH protocol, if your submodules are private repositories Enabling submodules on a repository # When using submodules, you must do the following for all your existing and new repositories: GitLab and Bitbucket only: Update the public SSH key that Codacy uses to access your repository. If you're using submodules to share an analysis tool configuration file across your repositories, check if your tool recursively searches the subdirectories of your repositories for configuration files. If your tool doesn't detect the configuration files in the submodule directories, you must include a configuration file directly in the root of your repositories referencing the configuration files in the submodule directories. Updating the public SSH key to access the repository # This section applies only to GitLab and Bitbucket On GitLab and Bitbucket organizations, Codacy generates a repository key when you add a repository to Codacy and uses it to clone that repository. When you're using submodules, Codacy needs to clone additional repositories it may not have access to. To overcome this, Codacy must use an SSH key of your user account to have access to the same repositories as your user. To update your GitLab or Bitbucket public SSH key that Codacy uses to access your repository, do the following: Open the repository Settings , tab General . In the Danger zone area, you have the SSH Key generated by Codacy to access your repository. Depending on your Git provider, do the following to update the key: For GitLab, click the button Generate New User Key . Codacy removes the existing repository key and creates the new SSH key on your user account automatically. For Bitbucket: Remove the existing Codacy key from the repository settings on your Git provider. Click the link Add new user key . This takes you to the Git provider page where you can manage your user account SSH keys. Add a new SSH key to your Git provider account. Automating user keys for new repositories # This section applies only to Codacy Self-hosted You can set Codacy to automatically add the new SSH key to your Git provider account for all new repositories by enabling Add project key to the user, by default on the Administration console, page Settings . Important If you're using Bitbucket Cloud this setting must be turned off since automatically adding the user keys isn't supported. See also # Configure repository settings in Bitbucket Add an SSH key to your Bitbucket account", "title": "Using submodules"}, {"location": "repositories-configure/using-submodules/#using-submodules", "text": "Git submodules allow you to keep a Git repository as a subdirectory within another Git repository. Git submodules are helpful in maintaining a shared configuration file for your team, and then applying it to multiple Git repositories. By default, Codacy does normal Git clones that don't include submodules to ensure that we only clone necessary repositories. If your organization needs to use submodules, you can request Codacy to enable this feature for you. Important GitHub only: Your repository and the repositories that you add as submodules must belong to the same GitHub organization.", "title": "Using submodules"}, {"location": "repositories-configure/using-submodules/#prerequisites-for-using-submodules", "text": "Contact us at support@codacy.com asking to enable submodules on Codacy. If you're using Codacy Self-hosted , update your license . Make sure that your Git URL uses the correct protocol: GitHub: HTTPS protocol GitLab and Bitbucket: HTTPS protocol, if your submodules are public repositories SSH protocol, if your submodules are private repositories", "title": "Prerequisites for using submodules"}, {"location": "repositories-configure/using-submodules/#enabling-submodules-on-a-repository", "text": "When using submodules, you must do the following for all your existing and new repositories: GitLab and Bitbucket only: Update the public SSH key that Codacy uses to access your repository. If you're using submodules to share an analysis tool configuration file across your repositories, check if your tool recursively searches the subdirectories of your repositories for configuration files. If your tool doesn't detect the configuration files in the submodule directories, you must include a configuration file directly in the root of your repositories referencing the configuration files in the submodule directories.", "title": "Enabling submodules on a repository"}, {"location": "repositories-configure/using-submodules/#update-key", "text": "This section applies only to GitLab and Bitbucket On GitLab and Bitbucket organizations, Codacy generates a repository key when you add a repository to Codacy and uses it to clone that repository. When you're using submodules, Codacy needs to clone additional repositories it may not have access to. To overcome this, Codacy must use an SSH key of your user account to have access to the same repositories as your user. To update your GitLab or Bitbucket public SSH key that Codacy uses to access your repository, do the following: Open the repository Settings , tab General . In the Danger zone area, you have the SSH Key generated by Codacy to access your repository. Depending on your Git provider, do the following to update the key: For GitLab, click the button Generate New User Key . Codacy removes the existing repository key and creates the new SSH key on your user account automatically. For Bitbucket: Remove the existing Codacy key from the repository settings on your Git provider. Click the link Add new user key . This takes you to the Git provider page where you can manage your user account SSH keys. Add a new SSH key to your Git provider account.", "title": "Updating the public SSH key to access the repository"}, {"location": "repositories-configure/using-submodules/#automating-user-keys-for-new-repositories", "text": "This section applies only to Codacy Self-hosted You can set Codacy to automatically add the new SSH key to your Git provider account for all new repositories by enabling Add project key to the user, by default on the Administration console, page Settings . Important If you're using Bitbucket Cloud this setting must be turned off since automatically adding the user keys isn't supported.", "title": "Automating user keys for new repositories"}, {"location": "repositories-configure/using-submodules/#see-also", "text": "Configure repository settings in Bitbucket Add an SSH key to your Bitbucket account", "title": "See also"}, {"location": "repositories-configure/integrations/bitbucket-integration/", "text": "Bitbucket integration # The Bitbucket integration incorporates Codacy on your existing Git provider workflows by reporting issues and the analysis status directly on your pull requests. When you add a new repository, Codacy sets the Bitbucket integration using the default settings for your organization . You can then customize the settings for the repository. Important Codacy uses the Bitbucket user who added the repository to create comments on pull requests. If that user loses access to the repository, a repository admin must refresh the Bitbucket integration . Configuring the Bitbucket integration # To configure the Bitbucket integration, open your repository Settings , tab Integrations . Depending on the options that you enable, Codacy will automatically update pull requests on Bitbucket with extra information when accepting pull requests. Tip You can apply the default Git provider integration settings to all repositories to ensure that your repositories all share the same settings. Status checks # Adds a report to your pull requests showing whether your pull requests and coverage are up to standards or not as configured on the quality gate rules for your repository. You can then optionally block merging pull requests that aren't up to standards . Important To get a status for coverage you must also: Add coverage to your repository Enable the rule Diff coverage is under or Coverage variation is under on the pull request quality gate . Issue annotations # Adds comments on the lines of the pull request where Codacy finds new issues. Click on the links to open Codacy and see more details about the issues and how to fix them. To enable this option, you must enable Status checks first. Issue summaries # This feature isn't available for Bitbucket Server Shows an overall view of the changes in the pull request, including new issues and metrics such as complexity and duplication. To enable this option, you must enable Status checks first. AI-Enhanced Comments # Adds AI-enhanced comments with insights to help you fix identified issues. Note This feature is compatible with most programming languages and requires no additional setup. Comments are generated using the description of the static analysis issue, information about the tool that detected the issue, and a few lines of surrounding code to provide the AI with extra context and improve its accuracy. This feature leverages the OpenAI API. No information is shared with other third parties or used to train AI models. Please refer to the OpenAI API data usage policies for more information. Refreshing the Bitbucket integration # If the user who added the repository to Codacy loses access to the repository, which may happen when the user leaves the team or the organization, Codacy won't be able to create comments on pull requests. In this situation, another user with administrator access to the repository needs to refresh the Bitbucket integration: Tip Use a dedicated service account to integrate Codacy with your repositories. This prevents disruption of service if the user who originally enabled the integration loses access to the repositories, which may happen when a user leaves the team or the organization. For more information and instructions on how to set up a dedicated service account see Why did Codacy stop commenting on pull requests? Open the repository Settings , tab Integrations . On the Bitbucket integration area, click the link Refresh connection . After refreshing the integration, Codacy will use the logged in Bitbucket user to create comments on new pull requests. Generating automatic pull request summaries # This is a preview feature This is an upcoming Codacy feature. If you're interested, contact support@codacy.com for early access. Codacy can provide a clear, high-level summary of the code changes introduced by a pull request, based on the committed code. Codacy generates an overview of the changes in the pull request so that any reviewer can understand its intent and impact. Note This feature uses only AWS services within Codacy's existing infrastructure. No information is shared with any other third party or used to train AI models. Summaries are generated using the pull request title, branch name, commit messages, and changes diff. To enable this feature, add the following to the Codacy configuration file .codacy.yaml in the root of your repository: --- reviews : high_level_summary : true You can also enable this feature across your organization by creating the above file in the root of a repository named .codacy . This file will be used as the default configuration for all repositories in the organization and overridden by repository-specific configuration files. Once enabled, summaries will be created when pull requests are opened and updated at each commit to reflect any changes to the pull request. Pull requests opened by bots, such as Dependabot, are ignored. If you see duplicated comments posted by Codacy on the same pull request, please ensure that your repository only has one configured webhook for Codacy. See also # Integrating Codacy with your Git workflow", "title": "Bitbucket integration"}, {"location": "repositories-configure/integrations/bitbucket-integration/#bitbucket-integration", "text": "The Bitbucket integration incorporates Codacy on your existing Git provider workflows by reporting issues and the analysis status directly on your pull requests. When you add a new repository, Codacy sets the Bitbucket integration using the default settings for your organization . You can then customize the settings for the repository. Important Codacy uses the Bitbucket user who added the repository to create comments on pull requests. If that user loses access to the repository, a repository admin must refresh the Bitbucket integration .", "title": "Bitbucket integration"}, {"location": "repositories-configure/integrations/bitbucket-integration/#configuring", "text": "To configure the Bitbucket integration, open your repository Settings , tab Integrations . Depending on the options that you enable, Codacy will automatically update pull requests on Bitbucket with extra information when accepting pull requests. Tip You can apply the default Git provider integration settings to all repositories to ensure that your repositories all share the same settings.", "title": "Configuring the Bitbucket integration"}, {"location": "repositories-configure/integrations/bitbucket-integration/#refreshing", "text": "If the user who added the repository to Codacy loses access to the repository, which may happen when the user leaves the team or the organization, Codacy won't be able to create comments on pull requests. In this situation, another user with administrator access to the repository needs to refresh the Bitbucket integration: Tip Use a dedicated service account to integrate Codacy with your repositories. This prevents disruption of service if the user who originally enabled the integration loses access to the repositories, which may happen when a user leaves the team or the organization. For more information and instructions on how to set up a dedicated service account see Why did Codacy stop commenting on pull requests? Open the repository Settings , tab Integrations . On the Bitbucket integration area, click the link Refresh connection . After refreshing the integration, Codacy will use the logged in Bitbucket user to create comments on new pull requests.", "title": "Refreshing the Bitbucket integration"}, {"location": "repositories-configure/integrations/bitbucket-integration/#generating-automatic-pull-request-summaries", "text": "This is a preview feature This is an upcoming Codacy feature. If you're interested, contact support@codacy.com for early access. Codacy can provide a clear, high-level summary of the code changes introduced by a pull request, based on the committed code. Codacy generates an overview of the changes in the pull request so that any reviewer can understand its intent and impact. Note This feature uses only AWS services within Codacy's existing infrastructure. No information is shared with any other third party or used to train AI models. Summaries are generated using the pull request title, branch name, commit messages, and changes diff. To enable this feature, add the following to the Codacy configuration file .codacy.yaml in the root of your repository: --- reviews : high_level_summary : true You can also enable this feature across your organization by creating the above file in the root of a repository named .codacy . This file will be used as the default configuration for all repositories in the organization and overridden by repository-specific configuration files. Once enabled, summaries will be created when pull requests are opened and updated at each commit to reflect any changes to the pull request. Pull requests opened by bots, such as Dependabot, are ignored. If you see duplicated comments posted by Codacy on the same pull request, please ensure that your repository only has one configured webhook for Codacy.", "title": "Generating automatic pull request summaries"}, {"location": "repositories-configure/integrations/bitbucket-integration/#see-also", "text": "Integrating Codacy with your Git workflow", "title": "See also"}, {"location": "repositories-configure/integrations/github-integration/", "text": "GitHub integration # The GitHub integration incorporates Codacy on your existing Git provider workflows by reporting issues and the analysis status directly on your pull requests. When you add a new repository, Codacy sets the GitHub integration using the default settings for your organization . You can then customize the settings for the repository. Configuring the GitHub integration # To configure the GitHub integration, open your repository Settings , tab Integrations . Depending on the options that you enable, Codacy will automatically update pull requests on GitHub with extra information when accepting pull requests. Tip You can apply the default Git provider integration settings to all repositories to ensure that your repositories all share the same settings. Status checks # Adds a report to your pull requests showing whether your pull requests and coverage are up to standards or not as configured on the quality gate rules for your repository. You can then optionally block merging pull requests that aren't up to standards . Important To get a status for coverage you must also: Add coverage to your repository Enable the rule Diff coverage is under or Coverage variation is under on the pull request quality gate . Issue annotations # Adds annotations on the lines of the pull request where Codacy finds new issues. Codacy maps the severity of the issues reported by the tools to the severity levels of the annotations. To enable this option, you must enable Status checks first. Issue summaries # Shows an overall view of the changes in the pull request, including new issues and metrics such as complexity and duplication. To enable this option, you must enable Status checks first. Coverage summaries # Adds a pull request comment showing an overall view of the coverage metrics for the pull request, including details about the data that Codacy used to calculate the coverage variation and diff coverage metrics. When there are new coverage results, Codacy updates the last coverage summary comment if it's included in the last 5 comments of the pull request. Otherwise, Codacy creates a new comment. Important To get coverage summaries you must also add coverage to your repository . Note This feature is only supported on GitHub Cloud. Suggested fixes # This feature is only available on paid plans Adds comments on the lines of the pull request where Codacy finds new issues with suggestions on how to fix the issues. Codacy doesn't apply any changes automatically. To apply the changes, manually review and accept the suggestions . Tip Enable also AI-enhanced comments to get ready-to-commit AI-generated fixes. AI-enhanced comments # Adds AI-enhanced comments, providing insights and ready-to-commit AI-generated fixes for identified issues in cases where tool-suggested fixes are not supported. To enable this option, you must enable Suggested fixes first. Note This feature is compatible with most programming languages and requires no additional setup. Comments are generated using the description of the static analysis issue, information about the tool that detected the issue, and a few lines of surrounding code to provide the AI with extra context and improve its accuracy. This feature leverages the OpenAI API. No information is shared with other third parties or used to train AI models. Please refer to the OpenAI API data usage policies for more information. Generating automatic pull request summaries # This is a preview feature This is an upcoming Codacy feature. If you're interested, contact support@codacy.com for early access. Codacy can provide a clear, high-level summary of the code changes introduced by a pull request, based on the committed code. Codacy generates an overview of the changes in the pull request so that any reviewer can understand its intent and impact. Note This feature uses only AWS services within Codacy's existing infrastructure. No information is shared with any other third party or used to train AI models. Summaries are generated using the pull request title, branch name, commit messages, and changes diff. To enable this feature, add the following to the Codacy configuration file .codacy.yaml in the root of your repository: --- reviews : high_level_summary : true You can also enable this feature across your organization by creating the above file in the root of a repository named .codacy . This file will be used as the default configuration for all repositories in the organization and overridden by repository-specific configuration files. Once enabled, summaries will be created when pull requests are opened and updated at each commit to reflect any changes to the pull request. Pull requests opened by bots, such as Dependabot, are ignored. If you see duplicated comments posted by Codacy on the same pull request, please ensure that your repository only has one configured webhook for Codacy. See also # Integrating Codacy with your Git workflow", "title": "GitHub integration"}, {"location": "repositories-configure/integrations/github-integration/#github-integration", "text": "The GitHub integration incorporates Codacy on your existing Git provider workflows by reporting issues and the analysis status directly on your pull requests. When you add a new repository, Codacy sets the GitHub integration using the default settings for your organization . You can then customize the settings for the repository.", "title": "GitHub integration"}, {"location": "repositories-configure/integrations/github-integration/#configuring", "text": "To configure the GitHub integration, open your repository Settings , tab Integrations . Depending on the options that you enable, Codacy will automatically update pull requests on GitHub with extra information when accepting pull requests. Tip You can apply the default Git provider integration settings to all repositories to ensure that your repositories all share the same settings.", "title": "Configuring the GitHub integration"}, {"location": "repositories-configure/integrations/github-integration/#generating-automatic-pull-request-summaries", "text": "This is a preview feature This is an upcoming Codacy feature. If you're interested, contact support@codacy.com for early access. Codacy can provide a clear, high-level summary of the code changes introduced by a pull request, based on the committed code. Codacy generates an overview of the changes in the pull request so that any reviewer can understand its intent and impact. Note This feature uses only AWS services within Codacy's existing infrastructure. No information is shared with any other third party or used to train AI models. Summaries are generated using the pull request title, branch name, commit messages, and changes diff. To enable this feature, add the following to the Codacy configuration file .codacy.yaml in the root of your repository: --- reviews : high_level_summary : true You can also enable this feature across your organization by creating the above file in the root of a repository named .codacy . This file will be used as the default configuration for all repositories in the organization and overridden by repository-specific configuration files. Once enabled, summaries will be created when pull requests are opened and updated at each commit to reflect any changes to the pull request. Pull requests opened by bots, such as Dependabot, are ignored. If you see duplicated comments posted by Codacy on the same pull request, please ensure that your repository only has one configured webhook for Codacy.", "title": "Generating automatic pull request summaries"}, {"location": "repositories-configure/integrations/github-integration/#see-also", "text": "Integrating Codacy with your Git workflow", "title": "See also"}, {"location": "repositories-configure/integrations/gitlab-integration/", "text": "GitLab integration # The GitLab integration incorporates Codacy on your existing Git provider workflows by reporting issues and the analysis status directly on your merge requests. When you add a new repository, Codacy sets the GitLab integration using the default settings for your organization . You can then customize the settings for the repository. Important Codacy uses the GitLab user who added the repository to create comments on merge requests. If that user loses access to the repository, a repository admin must refresh the GitLab integration . Configuring the GitLab integration # To configure the GitLab integration, open your repository Settings , tab Integrations . Depending on the options that you enable, Codacy will automatically update merge requests on GitLab with extra information when accepting merge requests. Tip You can apply the default Git provider integration settings to all repositories to ensure that your repositories all share the same settings. Status checks # Adds a report to your merge requests showing whether your merge requests and coverage are up to standards or not as configured on the quality gate rules for your project. You can then optionally block merging merge requests that aren't up to standards . Important To get a status for coverage you must also: Add coverage to your repository Enable the rule Diff coverage is under or Coverage variation is under on the pull request quality gate . Issue annotations # Adds comments on the lines of the merge request where Codacy finds new issues. Click on the links to open Codacy and see more details about the issues and how to fix them. To enable this option, you must enable Status checks first. Issue summaries # Shows an overall view of the changes in the merge request, including new issues and metrics such as complexity and duplication. To enable this option, you must enable Status checks first. AI-Enhanced Comments # Adds AI-enhanced comments with insights to help you fix identified issues. Note This feature is compatible with most programming languages and requires no additional setup. Comments are generated using the description of the static analysis issue, information about the tool that detected the issue, and a few lines of surrounding code to provide the AI with extra context and improve its accuracy. This feature leverages the OpenAI API. No information is shared with other third parties or used to train AI models. Please refer to the OpenAI API data usage policies for more information. Refreshing the GitLab integration # If the user who added the repository to Codacy loses access to the repository, which may happen when the user leaves the team or the organization, Codacy won't be able to create comments on merge requests. In this situation, another user with administrator access to the repository needs to refresh the GitLab integration: Tip Use a dedicated service account to integrate Codacy with your repositories. This prevents disruption of service if the user who originally enabled the integration loses access to the repositories, which may happen when a user leaves the team or the organization. For more information and instructions on how to set up a dedicated service account see Why did Codacy stop commenting on pull requests? Open the repository Settings , tab Integrations . On the GitLab integration area, click the link Refresh connection . After refreshing the integration, Codacy will use the logged in GitLab user to create comments on new merge requests. See also # Integrating Codacy with your Git workflow", "title": "GitLab integration"}, {"location": "repositories-configure/integrations/gitlab-integration/#gitlab-integration", "text": "The GitLab integration incorporates Codacy on your existing Git provider workflows by reporting issues and the analysis status directly on your merge requests. When you add a new repository, Codacy sets the GitLab integration using the default settings for your organization . You can then customize the settings for the repository. Important Codacy uses the GitLab user who added the repository to create comments on merge requests. If that user loses access to the repository, a repository admin must refresh the GitLab integration .", "title": "GitLab integration"}, {"location": "repositories-configure/integrations/gitlab-integration/#configuring", "text": "To configure the GitLab integration, open your repository Settings , tab Integrations . Depending on the options that you enable, Codacy will automatically update merge requests on GitLab with extra information when accepting merge requests. Tip You can apply the default Git provider integration settings to all repositories to ensure that your repositories all share the same settings.", "title": "Configuring the GitLab integration"}, {"location": "repositories-configure/integrations/gitlab-integration/#refreshing", "text": "If the user who added the repository to Codacy loses access to the repository, which may happen when the user leaves the team or the organization, Codacy won't be able to create comments on merge requests. In this situation, another user with administrator access to the repository needs to refresh the GitLab integration: Tip Use a dedicated service account to integrate Codacy with your repositories. This prevents disruption of service if the user who originally enabled the integration loses access to the repositories, which may happen when a user leaves the team or the organization. For more information and instructions on how to set up a dedicated service account see Why did Codacy stop commenting on pull requests? Open the repository Settings , tab Integrations . On the GitLab integration area, click the link Refresh connection . After refreshing the integration, Codacy will use the logged in GitLab user to create comments on new merge requests.", "title": "Refreshing the GitLab integration"}, {"location": "repositories-configure/integrations/gitlab-integration/#see-also", "text": "Integrating Codacy with your Git workflow", "title": "See also"}, {"location": "repositories-configure/integrations/post-commit-hooks/", "text": "Post-commit hooks # When you add a new repository to Codacy, Codacy automatically creates a repository hook on your Git provider to check for new commits and pull requests. This post-commit hook enables Codacy to trigger an analysis to run immediately after you push code to your repository. Important Don't change the configuration of the hooks created by Codacy on your Git provider, as it might cause service failure. Creating a new post-commit hook # In case your repository\u2019s hook is missing from your Git provider, you can create a new one: Open your repository Settings , tab Integrations . On the Post-commit hook area, click the button Create new hook .", "title": "Post-commit hooks"}, {"location": "repositories-configure/integrations/post-commit-hooks/#post-commit-hooks", "text": "When you add a new repository to Codacy, Codacy automatically creates a repository hook on your Git provider to check for new commits and pull requests. This post-commit hook enables Codacy to trigger an analysis to run immediately after you push code to your repository. Important Don't change the configuration of the hooks created by Codacy on your Git provider, as it might cause service failure.", "title": "Post-commit hooks"}, {"location": "repositories-configure/integrations/post-commit-hooks/#creating-a-new-post-commit-hook", "text": "In case your repository\u2019s hook is missing from your Git provider, you can create a new one: Open your repository Settings , tab Integrations . On the Post-commit hook area, click the button Create new hook .", "title": "Creating a new post-commit hook"}, {"location": "repositories-configure/local-analysis/client-side-tools/", "text": "Client-side tools # Client-side tools enable you to run an analysis locally or as part of your build process and upload the results to Codacy. This way, Codacy presents the analysis information reported by your local tools on the Codacy dashboards, in addition to the default code quality information. The following diagram presents a high-level overview of the local analysis flow. Codacy supports client-side tools in two ways: Containerized tools: Codacy provides Docker images to run analysis tools locally. To fetch code pattern configurations from Codacy, run the images, print out analysis results, and upload them to Codacy, use the Codacy Analysis CLI . The Codacy Analysis CLI automatically fetches the code pattern settings that you define on the Codacy UI and applies them when running the tools. Standalone tools: Codacy provides auxiliary converters that parse the output of third-party tools and convert to a format that you then upload to Codacy. You must download, configure, and run the third-party tools yourself. You can't configure these tools on the Codacy UI, since you manage their configuration locally. The table below describes the supported client-side tools and includes links to specific instructions on how to run each tool. Tip If you're using GitHub we recommend that you use the Codacy Analysis CLI GitHub Action to run the containerized client-side tools and upload the results to Codacy. Language Client-side tool Description Usage instructions C, C++ Clang-Tidy Clang-tidy is a clang-based C++ \u201clinter\u201d tool. Its purpose is to provide an extensible framework for diagnosing and fixing typical programming errors, like style violations, interface misuse, or bugs that can be deduced via static analysis. Clang-tidy is modular and provides a convenient interface for writing new checks. Running Clang-Tidy (standalone) Go aligncheck aligncheck is a utility for finding unused struct fields in Go source files. Running aligncheck (containerized) deadcode deadcode is a very simple utility which detects unused declarations in Go packages. Running deadcode (containerized) Gosec Gosec inspects source code for security problems by scanning the Go AST. Running Gosec (standalone) Staticcheck Staticcheck is a state of the art linter for the Go programming language. Using static analysis, it finds bugs and performance issues, offers simplifications, and enforces style rules. Running Staticcheck (standalone) Java, Scala SpotBugs SpotBugs is a program which uses static analysis to look for bugs in Java code. Together with the Find Security Bugs plugin it provides security audits. It has support for Maven, sbt, and Gradle in Java projects. Running SpotBugs (containerized) Objective-C Clang-Tidy Clang-tidy is a clang-based C++ \"linter\" tool. Its purpose is to provide an extensible framework for diagnosing and fixing typical programming errors, like style violations, interface misuse, or bugs that can be deduced via static analysis. Clang-tidy is modular and provides a convenient interface for writing new checks. Running Clang-Tidy (standalone) Unity Unity Roslyn Analyzers Unity-specific diagnostics for CSharp Unity projects. Running Unity Roslyn Analyzers (standalone) See also # Supported languages and tools", "title": "Client-side tools"}, {"location": "repositories-configure/local-analysis/client-side-tools/#client-side-tools", "text": "Client-side tools enable you to run an analysis locally or as part of your build process and upload the results to Codacy. This way, Codacy presents the analysis information reported by your local tools on the Codacy dashboards, in addition to the default code quality information. The following diagram presents a high-level overview of the local analysis flow. Codacy supports client-side tools in two ways: Containerized tools: Codacy provides Docker images to run analysis tools locally. To fetch code pattern configurations from Codacy, run the images, print out analysis results, and upload them to Codacy, use the Codacy Analysis CLI . The Codacy Analysis CLI automatically fetches the code pattern settings that you define on the Codacy UI and applies them when running the tools. Standalone tools: Codacy provides auxiliary converters that parse the output of third-party tools and convert to a format that you then upload to Codacy. You must download, configure, and run the third-party tools yourself. You can't configure these tools on the Codacy UI, since you manage their configuration locally. The table below describes the supported client-side tools and includes links to specific instructions on how to run each tool. Tip If you're using GitHub we recommend that you use the Codacy Analysis CLI GitHub Action to run the containerized client-side tools and upload the results to Codacy. Language Client-side tool Description Usage instructions C, C++ Clang-Tidy Clang-tidy is a clang-based C++ \u201clinter\u201d tool. Its purpose is to provide an extensible framework for diagnosing and fixing typical programming errors, like style violations, interface misuse, or bugs that can be deduced via static analysis. Clang-tidy is modular and provides a convenient interface for writing new checks. Running Clang-Tidy (standalone) Go aligncheck aligncheck is a utility for finding unused struct fields in Go source files. Running aligncheck (containerized) deadcode deadcode is a very simple utility which detects unused declarations in Go packages. Running deadcode (containerized) Gosec Gosec inspects source code for security problems by scanning the Go AST. Running Gosec (standalone) Staticcheck Staticcheck is a state of the art linter for the Go programming language. Using static analysis, it finds bugs and performance issues, offers simplifications, and enforces style rules. Running Staticcheck (standalone) Java, Scala SpotBugs SpotBugs is a program which uses static analysis to look for bugs in Java code. Together with the Find Security Bugs plugin it provides security audits. It has support for Maven, sbt, and Gradle in Java projects. Running SpotBugs (containerized) Objective-C Clang-Tidy Clang-tidy is a clang-based C++ \"linter\" tool. Its purpose is to provide an extensible framework for diagnosing and fixing typical programming errors, like style violations, interface misuse, or bugs that can be deduced via static analysis. Clang-tidy is modular and provides a convenient interface for writing new checks. Running Clang-Tidy (standalone) Unity Unity Roslyn Analyzers Unity-specific diagnostics for CSharp Unity projects. Running Unity Roslyn Analyzers (standalone)", "title": "Client-side tools"}, {"location": "repositories-configure/local-analysis/client-side-tools/#see-also", "text": "Supported languages and tools", "title": "See also"}, {"location": "repositories-configure/local-analysis/running-aligncheck/", "text": "Running aligncheck # To run aligncheck as a client-side tool : Enable aligncheck and configure the corresponding code patterns on your repository Code patterns page. Enable Run analysis on your build server on your repository Settings , tab General , Repository analysis on your server . This setting enables Codacy to wait for the results of the local analysis before resuming the analysis of your commits. Set up an API token to authenticate on Codacy: If you're setting up one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up multiple repositories , obtain an account API Token and set the following environment variable to specify the account API token: export CODACY_API_TOKEN = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variable to specify your Codacy instance URL: export CODACY_API_BASE_URL = Download and run the Codacy Analysis CLI on the root of the repository, specifying the tool aligncheck. codacy-analysis-cli analyze --tool aligncheck \\ --allow-network \\ --upload \\ --verbose If you're using an account API token , you must also provide the flags --provider , --username , and --project . You can obtain the values for these flags from the URL of your repository dashboard on Codacy: codacy-analysis-cli analyze --provider \\ --username \\ --project \\ --tool aligncheck \\ --allow-network \\ --upload \\ --verbose The Codacy Analysis CLI runs aligncheck on your repository and uploads the results to Codacy so you can use them in your workflow. Advanced configuration # See the available Codacy Analysis CLI configuration flags to configure running aligncheck in more advanced scenarios.", "title": "Running aligncheck"}, {"location": "repositories-configure/local-analysis/running-aligncheck/#running-aligncheck", "text": "To run aligncheck as a client-side tool : Enable aligncheck and configure the corresponding code patterns on your repository Code patterns page. Enable Run analysis on your build server on your repository Settings , tab General , Repository analysis on your server . This setting enables Codacy to wait for the results of the local analysis before resuming the analysis of your commits. Set up an API token to authenticate on Codacy: If you're setting up one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up multiple repositories , obtain an account API Token and set the following environment variable to specify the account API token: export CODACY_API_TOKEN = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variable to specify your Codacy instance URL: export CODACY_API_BASE_URL = Download and run the Codacy Analysis CLI on the root of the repository, specifying the tool aligncheck. codacy-analysis-cli analyze --tool aligncheck \\ --allow-network \\ --upload \\ --verbose If you're using an account API token , you must also provide the flags --provider , --username , and --project . You can obtain the values for these flags from the URL of your repository dashboard on Codacy: codacy-analysis-cli analyze --provider \\ --username \\ --project \\ --tool aligncheck \\ --allow-network \\ --upload \\ --verbose The Codacy Analysis CLI runs aligncheck on your repository and uploads the results to Codacy so you can use them in your workflow.", "title": "Running aligncheck"}, {"location": "repositories-configure/local-analysis/running-aligncheck/#advanced-configuration", "text": "See the available Codacy Analysis CLI configuration flags to configure running aligncheck in more advanced scenarios.", "title": "Advanced configuration"}, {"location": "repositories-configure/local-analysis/running-deadcode/", "text": "Running deadcode # To run deadcode as a client-side tool : Enable deadcode and configure the corresponding code patterns on your repository Code patterns page. Enable Run analysis on your build server on your repository Settings , tab General , Repository analysis on your server . This setting enables Codacy to wait for the results of the local analysis before resuming the analysis of your commits. Set up an API token to authenticate on Codacy: If you're setting up one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up multiple repositories , obtain an account API Token and set the following environment variable to specify the account API token: export CODACY_API_TOKEN = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variable to specify your Codacy instance URL: export CODACY_API_BASE_URL = Download and run the Codacy Analysis CLI on the root of the repository, specifying the tool deadcode. codacy-analysis-cli analyze --tool deadcode \\ --allow-network \\ --upload \\ --verbose If you're using an account API token , you must also provide the flags --provider , --username , and --project . You can obtain the values for these flags from the URL of your repository dashboard on Codacy: codacy-analysis-cli analyze --provider \\ --username \\ --project \\ --tool deadcode \\ --allow-network \\ --upload \\ --verbose The Codacy Analysis CLI runs deadcode on your repository and uploads the results to Codacy so you can use them in your workflow. Advanced configuration # See the available Codacy Analysis CLI configuration flags to configure running deadcode in more advanced scenarios.", "title": "Running deadcode"}, {"location": "repositories-configure/local-analysis/running-deadcode/#running-deadcode", "text": "To run deadcode as a client-side tool : Enable deadcode and configure the corresponding code patterns on your repository Code patterns page. Enable Run analysis on your build server on your repository Settings , tab General , Repository analysis on your server . This setting enables Codacy to wait for the results of the local analysis before resuming the analysis of your commits. Set up an API token to authenticate on Codacy: If you're setting up one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up multiple repositories , obtain an account API Token and set the following environment variable to specify the account API token: export CODACY_API_TOKEN = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variable to specify your Codacy instance URL: export CODACY_API_BASE_URL = Download and run the Codacy Analysis CLI on the root of the repository, specifying the tool deadcode. codacy-analysis-cli analyze --tool deadcode \\ --allow-network \\ --upload \\ --verbose If you're using an account API token , you must also provide the flags --provider , --username , and --project . You can obtain the values for these flags from the URL of your repository dashboard on Codacy: codacy-analysis-cli analyze --provider \\ --username \\ --project \\ --tool deadcode \\ --allow-network \\ --upload \\ --verbose The Codacy Analysis CLI runs deadcode on your repository and uploads the results to Codacy so you can use them in your workflow.", "title": "Running deadcode"}, {"location": "repositories-configure/local-analysis/running-deadcode/#advanced-configuration", "text": "See the available Codacy Analysis CLI configuration flags to configure running deadcode in more advanced scenarios.", "title": "Advanced configuration"}, {"location": "repositories-configure/local-analysis/running-spotbugs/", "text": "Running SpotBugs # To run SpotBugs as a client-side tool : Enable SpotBugs and configure the corresponding code patterns on your repository Code patterns page. Enable Run analysis on your build server on your repository Settings , tab General , Repository analysis on your server . This setting enables Codacy to wait for the results of the local analysis before resuming the analysis of your commits. Set up an API token to authenticate on Codacy: If you're setting up one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up multiple repositories , obtain an account API Token and set the following environment variable to specify the account API token: export CODACY_API_TOKEN = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variable to specify your Codacy instance URL: export CODACY_API_BASE_URL = Compile your Java or Scala repository on your build server, as you would normally do. Download and run the Codacy Analysis CLI on the root of the repository, specifying the tool SpotBugs. codacy-analysis-cli analyze --tool spotbugs \\ --allow-network \\ --upload \\ --verbose If you're using an account API token , you must also provide the flags --provider , --username , and --project . You can obtain the values for these flags from the URL of your repository dashboard on Codacy: codacy-analysis-cli analyze --provider \\ --username \\ --project \\ --tool spotbugs \\ --allow-network \\ --upload \\ --verbose The Codacy Analysis CLI runs SpotBugs on the compiled classes of your repository and uploads the results to Codacy so you can use them in your workflow. Detecting sources and compiled classes # The Codacy Analysis CLI tries to find the compiled classes and map results to the source files automatically. If you use Maven, Gradle, or sbt the Codacy Analysis CLI also detects the default layouts automatically. If there is an issue with detection, you can configure these paths manually by adding a .codacy.yml Codacy configuration file to the root of the repository: --- engines: spotbugs: modules: - classesDirectories: [ \"core/target/classes\" ] sourceDirectories: [ \"core/src/main\" ] - classesDirectories: [ \"api/target/classes\" ] sourceDirectories: [ \"api/src/main\" ] Increasing the timeout to run SpotBugs # When running SpotBugs on the compiled classes of larger projects, the default execution timeout of 15 minutes may not be enough for SpotBugs to complete the analysis. To increase the timeout that SpotBugs has to execute, use the option --tool-timeout when running the Codacy Analysis CLI. For example, use --tool-timeout 1hour to set the timeout to one hour. Advanced configuration # See the available Codacy Analysis CLI configuration flags to configure running SpotBugs in more advanced scenarios.", "title": "Running SpotBugs"}, {"location": "repositories-configure/local-analysis/running-spotbugs/#running-spotbugs", "text": "To run SpotBugs as a client-side tool : Enable SpotBugs and configure the corresponding code patterns on your repository Code patterns page. Enable Run analysis on your build server on your repository Settings , tab General , Repository analysis on your server . This setting enables Codacy to wait for the results of the local analysis before resuming the analysis of your commits. Set up an API token to authenticate on Codacy: If you're setting up one repository , obtain a repository API token and set the following environment variable to specify your repository API token: export CODACY_PROJECT_TOKEN = If you're setting up multiple repositories , obtain an account API Token and set the following environment variable to specify the account API token: export CODACY_API_TOKEN = Warning Never write API tokens to your configuration files and keep your API tokens well protected, as they grant owner permissions to your projects on Codacy. It's a best practice to store API tokens as environment variables. Check the documentation of your CI/CD platform on how to do this. If you're using Codacy Self-hosted set the following environment variable to specify your Codacy instance URL: export CODACY_API_BASE_URL = Compile your Java or Scala repository on your build server, as you would normally do. Download and run the Codacy Analysis CLI on the root of the repository, specifying the tool SpotBugs. codacy-analysis-cli analyze --tool spotbugs \\ --allow-network \\ --upload \\ --verbose If you're using an account API token , you must also provide the flags --provider , --username , and --project . You can obtain the values for these flags from the URL of your repository dashboard on Codacy: codacy-analysis-cli analyze --provider \\ --username \\ --project \\ --tool spotbugs \\ --allow-network \\ --upload \\ --verbose The Codacy Analysis CLI runs SpotBugs on the compiled classes of your repository and uploads the results to Codacy so you can use them in your workflow.", "title": "Running SpotBugs"}, {"location": "repositories-configure/local-analysis/running-spotbugs/#detecting-sources-and-compiled-classes", "text": "The Codacy Analysis CLI tries to find the compiled classes and map results to the source files automatically. If you use Maven, Gradle, or sbt the Codacy Analysis CLI also detects the default layouts automatically. If there is an issue with detection, you can configure these paths manually by adding a .codacy.yml Codacy configuration file to the root of the repository: --- engines: spotbugs: modules: - classesDirectories: [ \"core/target/classes\" ] sourceDirectories: [ \"core/src/main\" ] - classesDirectories: [ \"api/target/classes\" ] sourceDirectories: [ \"api/src/main\" ]", "title": "Detecting sources and compiled classes"}, {"location": "repositories-configure/local-analysis/running-spotbugs/#increasing-the-timeout-to-run-spotbugs", "text": "When running SpotBugs on the compiled classes of larger projects, the default execution timeout of 15 minutes may not be enough for SpotBugs to complete the analysis. To increase the timeout that SpotBugs has to execute, use the option --tool-timeout when running the Codacy Analysis CLI. For example, use --tool-timeout 1hour to set the timeout to one hour.", "title": "Increasing the timeout to run SpotBugs"}, {"location": "repositories-configure/local-analysis/running-spotbugs/#advanced-configuration", "text": "See the available Codacy Analysis CLI configuration flags to configure running SpotBugs in more advanced scenarios.", "title": "Advanced configuration"}, {"location": "repositories-coverage/commits/", "text": "Coverage Commits page # The Coverage Commits page displays an overview of the commits in your repository, such as the analysis status and coverage for each commit. This allows you to monitor the evolution of coverage in your repository per commit. By default, the page lists the commits on the main branch of your repository but if you have more than one branch enabled you can use the drop-down list at the top of the page to display commits on other branches. Click a specific commit to see detailed information about the code coverage changes introduced by that commit. The next sections describe each area of the commit detail page. Commit information # This area displays detailed information about the commit: Commit message Committer, SHA hash, and parent commits Date Link to the commit on your Git provider Commit coverage overview # This area displays the coverage gate status and an overview of the coverage metrics for the commit: The quality gate status is either Up to coverage standards or Not up to coverage standards depending on the coverage gate rules for your repository. If you don't have any rules enabled for commits, the status is always Up to coverage standards . The following coverage metrics for the commit, displayed either as a positive or negative variation , or no variation (represented by = ): Coverage variation: Variation of code coverage percentage relative to the parent commit Total coverage: Coverage value of the repository at this commit Note Learn how Codacy calculates the code quality metrics in more detail: Which coverage metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the coverage gate rules for your repository: Green: The metric passes the coverage gate Red: The metric fails the coverage gate Gray: There aren't coverage gate rules configured for the metric or the value doesn't impact the coverage gate Diff tab # The Diff tab displays a line-by-line view of the coverage variation introduced by the commit. It includes the following areas: A list of files modified by the commit, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the commit The coverage variation introduced by the commit (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line Files tab # The Files tab displays the coverage variation that the commit introduces to the files in your repository relative to the parent commit, displayed either as a positive or negative variation , or no variation (represented by = ): The option Show also files without coverage changes allows you to list all files that the commit updates, even if their coverage doesn't change.", "title": "Coverage Commits page"}, {"location": "repositories-coverage/commits/#coverage-commits-page", "text": "The Coverage Commits page displays an overview of the commits in your repository, such as the analysis status and coverage for each commit. This allows you to monitor the evolution of coverage in your repository per commit. By default, the page lists the commits on the main branch of your repository but if you have more than one branch enabled you can use the drop-down list at the top of the page to display commits on other branches. Click a specific commit to see detailed information about the code coverage changes introduced by that commit. The next sections describe each area of the commit detail page.", "title": "Coverage Commits page"}, {"location": "repositories-coverage/commits/#info", "text": "This area displays detailed information about the commit: Commit message Committer, SHA hash, and parent commits Date Link to the commit on your Git provider", "title": "Commit information"}, {"location": "repositories-coverage/commits/#coverage-overview", "text": "This area displays the coverage gate status and an overview of the coverage metrics for the commit: The quality gate status is either Up to coverage standards or Not up to coverage standards depending on the coverage gate rules for your repository. If you don't have any rules enabled for commits, the status is always Up to coverage standards . The following coverage metrics for the commit, displayed either as a positive or negative variation , or no variation (represented by = ): Coverage variation: Variation of code coverage percentage relative to the parent commit Total coverage: Coverage value of the repository at this commit Note Learn how Codacy calculates the code quality metrics in more detail: Which coverage metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the coverage gate rules for your repository: Green: The metric passes the coverage gate Red: The metric fails the coverage gate Gray: There aren't coverage gate rules configured for the metric or the value doesn't impact the coverage gate", "title": "Commit coverage overview"}, {"location": "repositories-coverage/commits/#diff-tab", "text": "The Diff tab displays a line-by-line view of the coverage variation introduced by the commit. It includes the following areas: A list of files modified by the commit, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the commit The coverage variation introduced by the commit (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line", "title": "Diff tab"}, {"location": "repositories-coverage/commits/#files-tab", "text": "The Files tab displays the coverage variation that the commit introduces to the files in your repository relative to the parent commit, displayed either as a positive or negative variation , or no variation (represented by = ): The option Show also files without coverage changes allows you to list all files that the commit updates, even if their coverage doesn't change.", "title": "Files tab"}, {"location": "repositories-coverage/files/", "text": "Coverage Files page # The Coverage Files page displays the current code coverage information for each analyzed file in your enabled repository branches . By default, the page lists the files on the main branch of your repository but if you have more than one branch enabled you can use the drop-down list at the top of the page to display files on other branches. Codacy displays the files in alphabetical order by default, but you can sort the list by each column to help you identify which files need more test coverage. Note You can use the Codacy API to generate reports or obtain coverage metrics for the files in your repositories in a more flexible way. Use the search box to filter the list and find specific files: File details # Click a specific file to see more detailed coverage information for that file, including: Coverable lines: Source lines of code that can be covered by tests Covered lines: Source lines of code that are covered by tests Coverage: Percentage of coverable source lines of code that are covered by tests The page also shows the source code of the file and identifies which lines of code are covered by tests (green background) or not (red background). Why are some files missing? # The Files page only displays files in your repository that were analyzed by Codacy. This means that some of your files may be missing from the list, for example: You're viewing the incorrect branch Not all files may exist in all branches of your repositories. Make sure that you're displaying files for the correct branch. The file might be ignored The Files page doesn't display ignored files that aren't meant to be analyzed, including the files that Codacy ignores by default . The file has an extension that is not on the list of supported extensions Codacy supports a list of file extensions associated with each language. Codacy doesn't analyze or display files with extensions that aren't associated with a language. The file might be too big Codacy doesn't analyze or display files that are over a certain size. Read more details for information on how to overcome this limit. See also # Which metrics does Codacy calculate? Using the Codacy API to obtain code quality metrics for files", "title": "Coverage Files page"}, {"location": "repositories-coverage/files/#coverage-files-page", "text": "The Coverage Files page displays the current code coverage information for each analyzed file in your enabled repository branches . By default, the page lists the files on the main branch of your repository but if you have more than one branch enabled you can use the drop-down list at the top of the page to display files on other branches. Codacy displays the files in alphabetical order by default, but you can sort the list by each column to help you identify which files need more test coverage. Note You can use the Codacy API to generate reports or obtain coverage metrics for the files in your repositories in a more flexible way. Use the search box to filter the list and find specific files:", "title": "Coverage Files page"}, {"location": "repositories-coverage/files/#file-details", "text": "Click a specific file to see more detailed coverage information for that file, including: Coverable lines: Source lines of code that can be covered by tests Covered lines: Source lines of code that are covered by tests Coverage: Percentage of coverable source lines of code that are covered by tests The page also shows the source code of the file and identifies which lines of code are covered by tests (green background) or not (red background).", "title": "File details"}, {"location": "repositories-coverage/files/#missing-files", "text": "The Files page only displays files in your repository that were analyzed by Codacy. This means that some of your files may be missing from the list, for example: You're viewing the incorrect branch Not all files may exist in all branches of your repositories. Make sure that you're displaying files for the correct branch. The file might be ignored The Files page doesn't display ignored files that aren't meant to be analyzed, including the files that Codacy ignores by default . The file has an extension that is not on the list of supported extensions Codacy supports a list of file extensions associated with each language. Codacy doesn't analyze or display files with extensions that aren't associated with a language. The file might be too big Codacy doesn't analyze or display files that are over a certain size. Read more details for information on how to overcome this limit.", "title": "Why are some files missing?"}, {"location": "repositories-coverage/files/#see-also", "text": "Which metrics does Codacy calculate? Using the Codacy API to obtain code quality metrics for files", "title": "See also"}, {"location": "repositories-coverage/pull-requests/", "text": "Coverage Pull Requests page # The Coverage Pull Requests page displays an overview of the pull requests in your repository, such as the status and coverage metrics for each pull request. This allows you to monitor the coverage of the work in progress in your repository. By default, the page lists open pull requests but you can click the Closed tab at the top of the list to display the closed pull requests. Click a specific pull request to see detailed coverage information for that pull request. The next sections describe each area of the pull request detail page. Pull request information # This area displays detailed information about the pull request: Pull request title and pull request status Pull request author, pull request branch, target branch, and pull request identifier on the Git provider Last updated date of the pull request Link to the pull request on your Git provider Link to reanalyze the pull request Link to view analysis logs Pull request coverage overview # This area displays the coverage gate status and an overview of the coverage metrics for the pull request: The quality gate status is either Up to coverage standards or Not up to coverage standards depending on the coverage gate rules for your repository. If you don't have any rules enabled for pull requests, the status is always Up to coverage standards . The following coverage metrics for the pull request, displayed either as a positive or negative variation , no variation (represented by = ), or not applicable (represented by \u2205 ): Diff coverage: Code coverage of the coverable lines added or changed by the pull request, or \u2205 (not applicable) if there aren't any coverable lines added or changed Coverage variation: Variation of code coverage percentage relative to the target branch of the pull request Note Learn how Codacy calculates the code quality metrics in more detail: Which coverage metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the coverage gate rules for your repository: Green: The metric passes the coverage gate Red: The metric fails the coverage gate Gray: There aren't coverage gate rules configured for the metric or the value doesn't impact the coverage gate Diff tab # The Diff tab displays a line-by-line view of the coverage variation introduced by the pull request. It includes the following areas: A list of files modified by the pull request, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the pull request The coverage variation introduced by the pull request (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line Files tab # The Files tab displays the coverage variation that the pull request introduces to the files in your repository relative to the target branch, displayed either as a positive or negative variation , or no variation (represented by = ): The option Show also files without coverage changes allows you to list all files that the pull request updates, even if their coverage doesn't change. Commits tab # The Commits tab displays an overview of each commit included in the pull request, such as the status and coverage metrics for each commit. Click a specific commit to see detailed information about that commit . Viewing analysis logs # Analysis logs can help you spot any issues with the coverage analysis, such as missing coverage reports. To access the coverage analysis logs, click the View logs link in the pull request information area. This opens a modal listing coverage reports received for the common ancestor commit and the head commit of the pull request. See also # Which metrics does Codacy calculate?", "title": "Coverage Pull Requests page"}, {"location": "repositories-coverage/pull-requests/#coverage-pull-requests-page", "text": "The Coverage Pull Requests page displays an overview of the pull requests in your repository, such as the status and coverage metrics for each pull request. This allows you to monitor the coverage of the work in progress in your repository. By default, the page lists open pull requests but you can click the Closed tab at the top of the list to display the closed pull requests. Click a specific pull request to see detailed coverage information for that pull request. The next sections describe each area of the pull request detail page.", "title": "Coverage Pull Requests page"}, {"location": "repositories-coverage/pull-requests/#info", "text": "This area displays detailed information about the pull request: Pull request title and pull request status Pull request author, pull request branch, target branch, and pull request identifier on the Git provider Last updated date of the pull request Link to the pull request on your Git provider Link to reanalyze the pull request Link to view analysis logs", "title": "Pull request information"}, {"location": "repositories-coverage/pull-requests/#coverage-overview", "text": "This area displays the coverage gate status and an overview of the coverage metrics for the pull request: The quality gate status is either Up to coverage standards or Not up to coverage standards depending on the coverage gate rules for your repository. If you don't have any rules enabled for pull requests, the status is always Up to coverage standards . The following coverage metrics for the pull request, displayed either as a positive or negative variation , no variation (represented by = ), or not applicable (represented by \u2205 ): Diff coverage: Code coverage of the coverable lines added or changed by the pull request, or \u2205 (not applicable) if there aren't any coverable lines added or changed Coverage variation: Variation of code coverage percentage relative to the target branch of the pull request Note Learn how Codacy calculates the code quality metrics in more detail: Which coverage metrics does Codacy calculate? Why does Codacy show unexpected coverage changes? The colors depend on the coverage gate rules for your repository: Green: The metric passes the coverage gate Red: The metric fails the coverage gate Gray: There aren't coverage gate rules configured for the metric or the value doesn't impact the coverage gate", "title": "Pull request coverage overview"}, {"location": "repositories-coverage/pull-requests/#diff-tab", "text": "The Diff tab displays a line-by-line view of the coverage variation introduced by the pull request. It includes the following areas: A list of files modified by the pull request, with additional information for each file: A green plus icon if the file is added or a yellow dot icon if it's modified by the pull request The coverage variation introduced by the pull request (green or red value) or the total file coverage if there's no variation (grey value) A diff viewer showing for each modified file the diff coverage and a comparison of the old and new file content. The background of any added or modified lines depends on their coverage status: Red : Uncovered line Green : Covered line, labeled with its test coverage count No background : Non-coverable line", "title": "Diff tab"}, {"location": "repositories-coverage/pull-requests/#files-tab", "text": "The Files tab displays the coverage variation that the pull request introduces to the files in your repository relative to the target branch, displayed either as a positive or negative variation , or no variation (represented by = ): The option Show also files without coverage changes allows you to list all files that the pull request updates, even if their coverage doesn't change.", "title": "Files tab"}, {"location": "repositories-coverage/pull-requests/#commits-tab", "text": "The Commits tab displays an overview of each commit included in the pull request, such as the status and coverage metrics for each commit. Click a specific commit to see detailed information about that commit .", "title": "Commits tab"}, {"location": "repositories-coverage/pull-requests/#viewing-analysis-logs", "text": "Analysis logs can help you spot any issues with the coverage analysis, such as missing coverage reports. To access the coverage analysis logs, click the View logs link in the pull request information area. This opens a modal listing coverage reports received for the common ancestor commit and the head commit of the pull request.", "title": "Viewing analysis logs"}, {"location": "repositories-coverage/pull-requests/#see-also", "text": "Which metrics does Codacy calculate?", "title": "See also"}, {"location": "repositories-coverage/repository-dashboard/", "text": "Coverage Repository Dashboard # The Coverage Repository Dashboard provides an overview of the repository coverage and items that require your attention. To access your Repository Dashboard, select a repository from the Repositories list and select Dashboard on the left navigation sidebar. Tip You can share the URL of the Repository Dashboard for your public repositories to allow other people to see your repository coverage metrics, even if they aren't registered on Codacy. The top of the Repository Dashboard displays: The name of the repository A drop-down list that selects which branch of your repository to display on the dashboard On the Repository Dashboard you have the following areas to help you monitor your repository: Coverage evolution chart Coverage Open pull requests The following sections provide a detailed overview of each dashboard area. Coverage evolution chart # The Coverage evolution chart displays the evolution of the repository code coverage . Click on Last 3 months , Last 31 days , or Last 7 days to select the time interval of the historical data to display on the chart. The tab displays the following information: A green or red indicator depending if coverage is within the acceptable level or not The current coverage value The coverage variation introduced by the last commit Note The chart only displays a value if Codacy received coverage data for the most recent commit. This is because one commit can easily change the size or number of files on the repository, or even remove some files that had coverage information. The chart also displays the trendline based on the past behavior and the coverage goal defined on the repository quality settings . Coverage # The Coverage area displays the percentage of lines of code on the selected branch that are covered by tests versus the coverage goal defined in the quality settings of the repository, as well as the number of files: Without coverage With coverage not up to standards (based on the coverage goal) With coverage up to standards (based on the coverage goal) Click See all files to open the list of files in the repository. Tip If you don't have coverage set up for your repository yet, the Coverage area provides you with instructions on how to add coverage for your repository . Open pull requests # The Open pull requests area displays the last updated pull requests and the split between the status of all open pull requests in your repository: Up to coverage standards: Pull requests that meet the minimum coverage levels Not up to coverage standards: Pull requests that failed to meet at least one of the coverage gate rules defined for the repository No information: Pull requests that didn't receive the coverage reports required for Codacy to calculate the coverage metrics Click a bar segment to display only pull requests with the corresponding status. To see the details of pull requests, click a pull request from the list or click See all pull requests to open the list of pull requests in the repository. See also # Which metrics does Codacy calculate? Using the Codacy API to obtain code quality metrics for files", "title": "Coverage Repository Dashboard"}, {"location": "repositories-coverage/repository-dashboard/#coverage-repository-dashboard", "text": "The Coverage Repository Dashboard provides an overview of the repository coverage and items that require your attention. To access your Repository Dashboard, select a repository from the Repositories list and select Dashboard on the left navigation sidebar. Tip You can share the URL of the Repository Dashboard for your public repositories to allow other people to see your repository coverage metrics, even if they aren't registered on Codacy. The top of the Repository Dashboard displays: The name of the repository A drop-down list that selects which branch of your repository to display on the dashboard On the Repository Dashboard you have the following areas to help you monitor your repository: Coverage evolution chart Coverage Open pull requests The following sections provide a detailed overview of each dashboard area.", "title": "Coverage Repository Dashboard"}, {"location": "repositories-coverage/repository-dashboard/#coverage-evolution-chart", "text": "The Coverage evolution chart displays the evolution of the repository code coverage . Click on Last 3 months , Last 31 days , or Last 7 days to select the time interval of the historical data to display on the chart. The tab displays the following information: A green or red indicator depending if coverage is within the acceptable level or not The current coverage value The coverage variation introduced by the last commit Note The chart only displays a value if Codacy received coverage data for the most recent commit. This is because one commit can easily change the size or number of files on the repository, or even remove some files that had coverage information. The chart also displays the trendline based on the past behavior and the coverage goal defined on the repository quality settings .", "title": "Coverage evolution chart"}, {"location": "repositories-coverage/repository-dashboard/#coverage", "text": "The Coverage area displays the percentage of lines of code on the selected branch that are covered by tests versus the coverage goal defined in the quality settings of the repository, as well as the number of files: Without coverage With coverage not up to standards (based on the coverage goal) With coverage up to standards (based on the coverage goal) Click See all files to open the list of files in the repository. Tip If you don't have coverage set up for your repository yet, the Coverage area provides you with instructions on how to add coverage for your repository .", "title": "Coverage"}, {"location": "repositories-coverage/repository-dashboard/#open-pull-requests", "text": "The Open pull requests area displays the last updated pull requests and the split between the status of all open pull requests in your repository: Up to coverage standards: Pull requests that meet the minimum coverage levels Not up to coverage standards: Pull requests that failed to meet at least one of the coverage gate rules defined for the repository No information: Pull requests that didn't receive the coverage reports required for Codacy to calculate the coverage metrics Click a bar segment to display only pull requests with the corresponding status. To see the details of pull requests, click a pull request from the list or click See all pull requests to open the list of pull requests in the repository.", "title": "Open pull requests"}, {"location": "repositories-coverage/repository-dashboard/#see-also", "text": "Which metrics does Codacy calculate? Using the Codacy API to obtain code quality metrics for files", "title": "See also"}]} \ No newline at end of file diff --git a/sitemap.xml b/sitemap.xml index d633fe7699..2135e26ce8 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -2,1087 +2,1087 @@ https://docs.codacy.com/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/special-thanks/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/account/emails/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/account/managing-your-profile/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/account/user-session-management/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/requirements/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/configuration/caching/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/configuration/logging/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/configuration/monitoring/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/configuration/integrations/bitbucket-cloud/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/configuration/integrations/bitbucket-server/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/configuration/integrations/email/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/configuration/integrations/github-app-create/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/configuration/integrations/github-cloud/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/configuration/integrations/github-enterprise/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/configuration/integrations/gitlab-cloud/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/configuration/integrations/gitlab-enterprise/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/infrastructure/eks-quickstart/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/infrastructure/microk8s-quickstart/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/maintenance/database/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/maintenance/license/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/maintenance/uninstall/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/maintenance/upgrade/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/troubleshoot/k8s-cheatsheet/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/troubleshoot/logs-collect/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/chart/troubleshoot/troubleshoot/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/codacy-api/api-tokens/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/codacy-api/using-the-codacy-api/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/codacy-api/examples/adding-people-to-codacy-programmatically/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/codacy-api/examples/adding-repositories-to-codacy-programmatically/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/codacy-api/examples/creating-repository-api-tokens-programmatically/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/codacy-api/examples/identifying-commits-without-coverage-data/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/codacy-api/examples/obtaining-code-quality-metrics-for-files/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/codacy-api/examples/obtaining-current-issues-in-repositories/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/codacy-api/examples/uploading-dast-results/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/coverage-reporter/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/coverage-reporter/alternative-ways-of-running-coverage-reporter/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/coverage-reporter/troubleshooting-coverage-cli-issues/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/coverage-reporter/uploading-coverage-in-advanced-scenarios/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/code-analysis/can-i-bypass-codacy-status-check/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/code-analysis/does-codacy-check-for-dependencies/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/code-analysis/does-codacy-place-limits-on-the-code-analysis/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/code-analysis/how-long-does-it-take-for-my-repository-to-be-analyzed/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/code-analysis/how-to-configure-php-codesniffer-coding-standards/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/code-analysis/how-to-skip-an-analysis/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/code-analysis/which-metrics-does-codacy-calculate/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/code-analysis/why-does-codacy-show-unexpected-coverage-changes/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/general/does-codacy-keep-audit-logs/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/general/how-can-i-change-or-cancel-my-plan/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/general/how-do-i-allowlist-codacy-cloud-on-my-git-provider/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/general/how-does-codacy-keep-my-data-secure/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/general/how-does-codacy-protect-my-privacy/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/general/how-does-codacy-support-bitbucket-cloud/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/general/how-does-codacy-support-bitbucket-server/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/general/how-does-codacy-support-gitlab-cloud/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/general/how-does-codacy-support-gitlab-enterprise/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/general/which-platforms-and-technologies-does-codacy-support/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/repositories/how-do-i-reanalyze-my-repository/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/repositories/i-moved-my-repository-on-the-git-provider/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/repositories/i-renamed-my-repository-on-the-git-provider/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/troubleshooting/error-line-endings/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/troubleshooting/not-a-member-of-the-organization/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/troubleshooting/we-no-longer-have-access-to-this-repository/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/troubleshooting/why-arent-duplication-metrics-being-calculated/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/troubleshooting/why-cant-i-see-my-organization/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/troubleshooting/why-did-codacy-stop-commenting-on-pull-requests/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/troubleshooting/why-is-my-file-over-150-kb-missing/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/faq/troubleshooting/why-isnt-my-public-repository-being-analyzed/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/getting-started/adding-a-codacy-badge/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/getting-started/codacy-quickstart/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/getting-started/configuring-your-repository/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/getting-started/integrating-codacy-with-intellij-ides/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/getting-started/integrating-codacy-with-visual-studio-code/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/getting-started/integrating-codacy-with-your-git-workflow/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/getting-started/supported-languages-and-tools/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/getting-started/which-permissions-does-codacy-need-from-my-account/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/organizations/audit-logs-for-organizations/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/organizations/changing-your-plan-and-billing/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/organizations/managing-people/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/organizations/managing-repositories/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/organizations/managing-security-and-risk/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/organizations/organization-overview/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/organizations/roles-and-permissions-for-organizations/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/organizations/using-coding-standards/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/organizations/using-gate-policies/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/organizations/what-are-organizations/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/organizations/integrations/default-git-provider-integration-settings/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/organizations/integrations/jira-integration/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/organizations/integrations/slack-integration/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2018-07-23/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2018-10-19/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2018-11-02/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2018-11-16/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2019-01-02/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2019-02-18-bitbucket-changes/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2019-03-29/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2019-04-08/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2019-05-05/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2019-05-20/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2019-06-18/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2019-08-07/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2019-09-05/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2019-10-30/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2019-11-15/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2020-02-github-apps/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2020-03-09-nodesecurity-golint-scsslint-removal/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2020-04-01-deprecating-http-headers-for-api-tokens/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2021-07-03-scheduled-db-maintenance/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2021-08/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2021-09/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2021-10/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2021-11-02-legacy-organizations/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2021-11/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2021-12/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-01/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-02-16-pmd-legacy-removal/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-02/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-03-31-adding-eslint8/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-03/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-04/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-05/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-06/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-07/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-08/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-09/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-10/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-11/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2022-12/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-01/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-02/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-03/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-04/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-05/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-06/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-07/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-08/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-09/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-10-13-bundler-audit-deprecation/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-10-25-csslint-jshint-fauxpas-tailor-tslint-deprecation/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-10/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-11-13-jira-slack-webhooks-repo-integrations-removal/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-11-23-new-coverage-engine-status-checks/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-11/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2023-12/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2024-01-15-gh-repository-ssh-keys-discontinuation/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2024-01/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2024-02/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2024-03/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2024-04/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2024-05/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2024-06/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/cloud/cloud-2024-07/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v1.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v1.0.1/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v1.1.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v1.2.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v1.3.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v1.4.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v1.5.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v10.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v11.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v12.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v13.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v14.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v2.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v2.1.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v2.1.1/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v2.2.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v2.2.1/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v3.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v3.1.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v3.2.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v3.3.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v3.4.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v3.5.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v3.5.1/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v4.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v4.0.1/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v4.1.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v4.2.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v4.3.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v4.4.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v5.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v5.1.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v6.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v7.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v8.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v8.1.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/release-notes/self-hosted/self-hosted-v9.0.0/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories/commits/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories/files/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories/issues/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories/pull-requests/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories/repository-dashboard/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/adjusting-quality-gates/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/adjusting-quality-goals/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/codacy-configuration-file/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/configuring-code-patterns/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/ignoring-files/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/languages/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/managing-branches/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/removing-your-repository/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/using-submodules/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/integrations/bitbucket-integration/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/integrations/github-integration/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/integrations/gitlab-integration/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/integrations/post-commit-hooks/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/local-analysis/client-side-tools/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/local-analysis/running-aligncheck/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/local-analysis/running-deadcode/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-configure/local-analysis/running-spotbugs/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-coverage/commits/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-coverage/files/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-coverage/pull-requests/ - 2024-08-20 + 2024-08-27 daily https://docs.codacy.com/repositories-coverage/repository-dashboard/ - 2024-08-20 + 2024-08-27 daily \ No newline at end of file diff --git a/sitemap.xml.gz b/sitemap.xml.gz index b21a1c2f21..fdbbd0eba6 100644 Binary files a/sitemap.xml.gz and b/sitemap.xml.gz differ