fix: resolve 5 SonarQube issues in credential-guard tests

[sonarqube-agent]

This change fixes magic number warnings by introducing named constants for file permissions (AWS_DIR_PERMISSIONS and AWS_FILE_PERMISSIONS) and updates Node.js built-in module imports to use the node: protocol prefix. These improvements enhance code maintainability and follow current Node.js best practices.

View Project in SonarCloud

---

Fixed Issues

typescript:S109 - No magic number: 0o700. • MAJOR • View issue

Location: __tests__/credential-guard.test.ts:142

Why is this an issue?

Magic numbers make the code more complex to understand as it requires the reader to have knowledge about the global context to understand the number itself. Their usage may seem obvious when writing the code, but it may not be the case for another developer or later once the context faded away. -1, 0, and 1 are not considered magic numbers.

What changed

This hunk introduces named constants AWS_DIR_PERMISSIONS = 0o700 and AWS_FILE_PERMISSIONS = 0o600 at the top of the file. By assigning these octal permission values to well-named constants, the magic numbers 0o700 and 0o600 that were previously used inline in test assertions are replaced with meaningful identifiers. This resolves the magic number warnings for all three occurrences (0o700 on the directory permission check, and 0o600 on both file permission checks).

--- a/__tests__/credential-guard.test.ts
+++ b/__tests__/credential-guard.test.ts
@@ -18,0 +19,3 @@ import * as core from '@actions/core';
+const AWS_DIR_PERMISSIONS = 0o700;
+const AWS_FILE_PERMISSIONS = 0o600;
+

typescript:S109 - No magic number: 0o600. • MAJOR • View issue

Location: __tests__/credential-guard.test.ts:146

Why is this an issue?

Magic numbers make the code more complex to understand as it requires the reader to have knowledge about the global context to understand the number itself. Their usage may seem obvious when writing the code, but it may not be the case for another developer or later once the context faded away. -1, 0, and 1 are not considered magic numbers.

What changed

This hunk introduces named constants AWS_DIR_PERMISSIONS = 0o700 and AWS_FILE_PERMISSIONS = 0o600 at the top of the file. By assigning these octal permission values to well-named constants, the magic numbers 0o700 and 0o600 that were previously used inline in test assertions are replaced with meaningful identifiers. This resolves the magic number warnings for all three occurrences (0o700 on the directory permission check, and 0o600 on both file permission checks).

--- a/__tests__/credential-guard.test.ts
+++ b/__tests__/credential-guard.test.ts
@@ -18,0 +19,3 @@ import * as core from '@actions/core';
+const AWS_DIR_PERMISSIONS = 0o700;
+const AWS_FILE_PERMISSIONS = 0o600;
+

typescript:S109 - No magic number: 0o600. • MAJOR • View issue

Location: __tests__/credential-guard.test.ts:178

Why is this an issue?

Magic numbers make the code more complex to understand as it requires the reader to have knowledge about the global context to understand the number itself. Their usage may seem obvious when writing the code, but it may not be the case for another developer or later once the context faded away. -1, 0, and 1 are not considered magic numbers.

What changed

This hunk introduces named constants AWS_DIR_PERMISSIONS = 0o700 and AWS_FILE_PERMISSIONS = 0o600 at the top of the file. By assigning these octal permission values to well-named constants, the magic numbers 0o700 and 0o600 that were previously used inline in test assertions are replaced with meaningful identifiers. This resolves the magic number warnings for all three occurrences (0o700 on the directory permission check, and 0o600 on both file permission checks).

--- a/__tests__/credential-guard.test.ts
+++ b/__tests__/credential-guard.test.ts
@@ -18,0 +19,3 @@ import * as core from '@actions/core';
+const AWS_DIR_PERMISSIONS = 0o700;
+const AWS_FILE_PERMISSIONS = 0o600;
+

typescript:S7772 - Prefer `node:path` over `path`. • MINOR • View issue

Location: __tests__/credential-guard.test.ts:3

Why is this an issue?

When importing Node.js built-in modules, using the node: protocol makes it explicitly clear that you’re importing a core Node.js module rather than a third-party package from npm.

What changed

This hunk changes the imports of Node.js built-in modules path and os (and also fs/promises) to use the node: protocol prefix. Specifically, 'path' becomes 'node:path' and 'os' becomes 'node:os', which resolves the static analysis warnings about preferring the node: protocol for built-in module imports. This makes it explicitly clear these are core Node.js modules rather than potentially third-party npm packages.

--- a/__tests__/credential-guard.test.ts
+++ b/__tests__/credential-guard.test.ts
@@ -2,3 +2,3 @@ import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest';
-import * as fs from 'fs/promises';
-import * as path from 'path';
-import * as os from 'os';
+import * as fs from 'node:fs/promises';
+import * as path from 'node:path';
+import * as os from 'node:os';

typescript:S7772 - Prefer `node:os` over `os`. • MINOR • View issue

Location: __tests__/credential-guard.test.ts:4

Why is this an issue?

When importing Node.js built-in modules, using the node: protocol makes it explicitly clear that you’re importing a core Node.js module rather than a third-party package from npm.

What changed

This hunk changes the imports of Node.js built-in modules path and os (and also fs/promises) to use the node: protocol prefix. Specifically, 'path' becomes 'node:path' and 'os' becomes 'node:os', which resolves the static analysis warnings about preferring the node: protocol for built-in module imports. This makes it explicitly clear these are core Node.js modules rather than potentially third-party npm packages.

--- a/__tests__/credential-guard.test.ts
+++ b/__tests__/credential-guard.test.ts
@@ -2,3 +2,3 @@ import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest';
-import * as fs from 'fs/promises';
-import * as path from 'path';
-import * as os from 'os';
+import * as fs from 'node:fs/promises';
+import * as path from 'node:path';
+import * as os from 'node:os';

Have a suggestion or found an issue? Share your feedback here.

---

SonarQube Remediation Agent uses AI. Check for mistakes.

[sonar-review-alpha]

Summary

⚠️ The PR description exceeded the analysis limit and was truncated. The review may not reflect all context.

This PR fixes 5 SonarQube issues in the credential-guard test file:

1. Node.js module imports — Updates all three Node.js built-in module imports (fs/promises, path, os) to use the node: protocol prefix, following current Node.js best practices and resolving SonarQube warnings.

2. Magic number constants — Extracts the file permission values (0o700 for directories, 0o600 for files) into named constants (AWS_DIR_PERMISSIONS and AWS_FILE_PERMISSIONS), replacing three inline magic numbers in test assertions and improving code readability.

All changes are confined to the test file with no modifications to production code.

What reviewers should know

Scope: Single file change (__tests__/credential-guard.test.ts) — all modifications are additive and low-risk.

What to verify:

• The permission values (0o700 for directories, 0o600 for files) are standard Unix permissions for AWS credential storage and correctly match the assertions they replace.
• The node: protocol prefix is applied consistently across all three built-in module imports.

Testing: These are test-only changes with no impact on runtime behavior. Existing tests will continue to validate the same permission assertions; they're just more readable now.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

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

See analysis details on SonarQube Cloud

[sonarqube-cloud-us]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

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

See analysis details on SonarQube Cloud

[sonar-review-alpha]

LGTM! ✅

Clean change with no issues found. The permission constants (AWS_DIR_PERMISSIONS = 0o700, AWS_FILE_PERMISSIONS = 0o600) correctly match the values used in the production source (src/credential-guard-post.ts, src/credential-setup.ts), so the tests remain accurate.

🗣️ Give feedback