Add Infisical Secrets Check Workflow

[guibranco]

Description

• Introduced a new GitHub Actions workflow to check for secrets in the repository using Infisical.
• The workflow runs on pull requests and can be triggered manually.
• It scans for secrets, generates reports, and uploads them as artifacts.
• Comments are added to the PR with the scan results, indicating whether secrets were found.

---

Changes walkthrough 📝

	Relevant files
Enhancement	infisical-secrets-check.yml Add Infisical Secrets Check Workflow                                          .github/workflows/infisical-secrets-check.yml Added a GitHub Actions workflow for Infisical secrets checking. Configured steps for scanning secrets and generating reports. Implemented artifact uploads for logs and reports. Included PR comment updates based on scan results. +112/-0

[penify-dev]

PR Review 🔍

⏱️ Estimated effort to review [1-5]	4, because the workflow is complex with multiple steps and conditions, requiring careful review to ensure all scenarios are handled correctly.
🧪 Relevant tests	No
⚡ Possible issues	Potential Bug: The workflow assumes that the Infisical CLI installation will always succeed. If it fails, the subsequent steps may not execute as expected.
	Error Handling: The workflow does not appear to handle cases where the scan might fail without producing a CSV file, which could lead to misleading PR comments.
🔒 Security concerns	No

[penify-dev]

PR Code Suggestions ✨

Category	Suggestion	Score
Possible issue	Add error handling for the installation command to manage potential failures It is advisable to check the exit status of the apt-get install command to handle any potential installation failures gracefully. .github/workflows/infisical-secrets-check.yml [32] -- sudo apt-get install -y infisical +- sudo apt-get install -y infisical || { echo "Installation failed"; exit 1; } Suggestion importance[1-10]: 9 Why: Adding error handling to the installation command is important for robustness, as it ensures that the workflow fails gracefully if the installation does not succeed.	9
Best practice	Use a specific version tag for the checkout action to ensure stability Consider using a specific version tag for the actions/checkout action to ensure consistency and avoid unexpected changes in behavior due to updates. .github/workflows/infisical-secrets-check.yml [21] -- uses: actions/checkout@v4 +- uses: actions/checkout@v2 Suggestion importance[1-10]: 8 Why: Using a specific version tag for actions helps maintain stability and predictability in CI/CD workflows, which is crucial for avoiding unexpected behavior.	8
Enhancement	Refine the condition for executing steps to ensure they only run under specific circumstances Consider using a more specific condition for the if statements to avoid unnecessary execution of steps when the previous steps succeed. .github/workflows/infisical-secrets-check.yml [58] -- if: failure() +- if: ${{ failure() && github.event_name == 'pull_request' }} Suggestion importance[1-10]: 7 Why: Refining the condition for executing steps can improve efficiency, but the current use of failure() is already a common practice in CI workflows.	7
Maintainability	Standardize the indentation style for better readability To improve readability, consider using a consistent indentation style for the with parameters in the upload artifact steps. .github/workflows/infisical-secrets-check.yml [53-67] +- with: +- name: report-log +- path: secrets-result.log - Suggestion importance[1-10]: 5 Why: While consistent indentation improves readability, this is a minor stylistic change that does not significantly impact functionality or performance.	5

[github-actions]

Infisical secrets check: ✅ No secrets leaked!

Scan results:

11:03AM INF scanning for exposed secrets...
11:03AM INF 145 commits scanned.
11:03AM INF scan completed in 99ms
11:03AM INF no leaks found

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.00% (target: -1.00%)	✅ ∅

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (569b58e)	75	1	1.33%
Head commit (92485ef)	75 (+0)	1 (+0)	1.33% (+0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#119)	0	0	∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[AppVeyorBot]

✅ Build PIX-BACEN-SDK-dotnet 1.1.343 completed (commit f6cb076c7e by @gstraccini[bot])

[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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 1.33%. Comparing base (569b58e) to head (92485ef).
Report is 1 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main    #119   +/-   ##
=====================================
  Coverage   1.33%   1.33%           
=====================================
  Files         17      17           
  Lines         75      75           
=====================================
  Hits           1       1           
  Misses        74      74           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.