Update codacy/codacy-analysis-cli-action action to v4.4.7

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
codacy/codacy-analysis-cli-action	action	minor	v4.2.0 → v4.4.7

---

Release Notes

codacy/codacy-analysis-cli-action (codacy/codacy-analysis-cli-action)

v4.4.7: Bump CLI version to 7.9.25

Compare Source

v4.4.6: Adds support for High severity

Compare Source

This release adds support for the newly added High severity

v4.4.5

Compare Source

What's Changed

• Fix export REGISTRY_ADDRESS env variable by @​heliocodacy in #​133

v4.4.4

Compare Source

What's Changed

• update cli version to 7.9.11 by @​hjrocha in #​132

v4.4.3

Compare Source

What's Changed

• fix registry-address default value by @​hjrocha in #​131

v4.4.2

Compare Source

What's Changed

• Fixed some broken links by @​mushlih-almubarak in #​77
• bump: Bump codacy-analysis-cli to 7.6.4 CY-6112 by @​lolgab in #​80
• feature: Introduce new versioning scheme vX.X.X by @​lolgab in #​81
• doc: Mention setting up the Go environment DOCS-380 by @​prcr in #​83
• [SE-140] Add max-tool-memory flag by @​heliocodacy in #​86
• Bump gosec to v2.13.1 CY-6239 by @​stefanvacareanu7 in #​87
• Fix typo by @​pSub in #​82
• doc: Bump supported Go version to 1.19.1 CY-6239 by @​prcr in #​88
• Update supported languages count by @​nicklem in #​91
• doc: Improve CLI parameters DOCS-180 by @​nicklem in #​92
• doc: Flag @​codacy/techwriters as owners of README.md DOCS-483 by @​nicklem in #​93
• added github_token in all requests to github api in action.yml by @​DMarinhoCodacy in #​96
• removed github-token from action.yaml file by @​DMarinhoCodacy in #​100
• changed staticcheck URL using github api to artifact TS-214 by @​DMarinhoCodacy in #​102
• updated Clang-Tidy URL to artifact by @​DMarinhoCodacy in #​103
• doc: Mention turning on and configuring the client-side tool by @​prcr in #​106
• moved gosec and fauxpas to artifact by @​DMarinhoCodacy in #​107
• fix installation staticcheck using official binary by @​DMarinhoCodacy in #​108
• feature: allow skipping container engine check IO-423 by @​pedrocodacy in #​110
• close if statement properly by @​bjarkebm in #​114
• bump cli version by @​pedrocodacy in #​116
• doc: Update Codacy logo DOCS-594 by @​nicklem in #​119
• action: prevent globbing with double quotes by @​ljmf00 in #​68
• Bump cli, staticheck, gosec versions TCE-614 by @​stefanvacareanu7 in #​124
• TCE-937 add condition to setup go only if the user wants to run staticcheck by @​DMarinhoCodacy in #​126
• feat: [TCE-1039] Add parameter 'registry-address' in order to support alternative registry addresses by @​heliocodacy in #​129

New Contributors

• @​mushlih-almubarak made their first contribution in #​77
• @​stefanvacareanu7 made their first contribution in #​87
• @​pSub made their first contribution in #​82
• @​nicklem made their first contribution in #​91
• @​DMarinhoCodacy made their first contribution in #​96
• @​bjarkebm made their first contribution in #​114
• @​ljmf00 made their first contribution in #​68

Full Changelog: codacy/codacy-analysis-cli-action@4.0.2...v4.4.2

v4.4.1

Compare Source

v4.4.0: Update cli and tool versions

Compare Source

Update versions of:

• staticheck
• gosec
• codacy-analysis-cli

v4.4

Compare Source

v4.3

Compare Source

v4.3.0: Move tools to artifact

Compare Source

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[pull-request-quantifier-deprecated]

This PR has 2 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

---

Quantification details

Label      : Extra Small
Size       : +1 -1
Percentile : 0.8%

Total files changed: 1

Change summary by file extension:
.yml : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

• Fast and predictable releases to production:
  • Optimal size changes are more likely to be reviewed faster with fewer
    iterations.
  • Similarity in low PR complexity drives similar review times.
• Review quality is likely higher as complexity is lower:
  • Bugs are more likely to be detected.
  • Code inconsistencies are more likely to be detected.
• Knowledge sharing is improved within the participants:
  • Small portions can be assimilated better.
• Better engineering practices are exercised:
  • Solving big problems by dividing them in well contained, smaller problems.
  • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

• Use the PullRequestQuantifier to quantify your PR accurately
  • Create a context profile for your repo using the context generator
  • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
• Change your engineering behaviors
  • For PRs that fall outside of the desired spectrum, review the details and check if:
    • Your PR could be split in smaller, self-contained PRs instead
    • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

• One line was added: +1 -0
• One line was deleted: +0 -1
• One line was modified: +1 -1 (git diff doesn't know about modified, it will
  interpret that line like one addition plus one deletion)
• Change percentiles: Change characteristics (addition, deletion, modification)
  of this PR in relation to all other PRs within the repository.

---

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

[pull-request-quantifier-deprecated]

This PR has 2 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

---

Quantification details

Label      : Extra Small
Size       : +1 -1
Percentile : 0.8%

Total files changed: 1

Change summary by file extension:
.yml : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

• Fast and predictable releases to production:
  • Optimal size changes are more likely to be reviewed faster with fewer
    iterations.
  • Similarity in low PR complexity drives similar review times.
• Review quality is likely higher as complexity is lower:
  • Bugs are more likely to be detected.
  • Code inconsistencies are more likely to be detected.
• Knowledge sharing is improved within the participants:
  • Small portions can be assimilated better.
• Better engineering practices are exercised:
  • Solving big problems by dividing them in well contained, smaller problems.
  • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

• Use the PullRequestQuantifier to quantify your PR accurately
  • Create a context profile for your repo using the context generator
  • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
• Change your engineering behaviors
  • For PRs that fall outside of the desired spectrum, review the details and check if:
    • Your PR could be split in smaller, self-contained PRs instead
    • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

• One line was added: +1 -0
• One line was deleted: +0 -1
• One line was modified: +1 -1 (git diff doesn't know about modified, it will
  interpret that line like one addition plus one deletion)
• Change percentiles: Change characteristics (addition, deletion, modification)
  of this PR in relation to all other PRs within the repository.

---

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud