refactor: re-export scanfailure types from armoapi-go#98
refactor: re-export scanfailure types from armoapi-go#98
Conversation
Canonical types now live in armoapi-go/scanfailure. This package re-exports them for backward compatibility. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
📝 WalkthroughWalkthroughGo toolchain and dependencies upgraded (Go 1.24.1); local scanfailure types replaced by type aliases to github.com/armosec/armoapi-go/scanfailure, removing local implementations and String() method. Changes
Sequence Diagram(s)(omitted — changes are dependency and type-alias updates without new multi-component control flow) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
pulsar/common/scanfailure/types.go (1)
3-10: Clean backward compatibility implementation using type aliases.The use of type aliases (
=) rather than type definitions ensures full interchangeability with upstream types. Existing consumers won't need any code changes.Consider adding an import alias for clarity since both packages share the same name:
import upstream "github.com/armosec/armoapi-go/scanfailure"This makes it explicit which
scanfailureis being referenced throughout the file.♻️ Optional: Use import alias for clarity
-import "github.com/armosec/armoapi-go/scanfailure" +import upstream "github.com/armosec/armoapi-go/scanfailure" // Re-export types from armoapi-go for backward compatibility. // New code should import from github.com/armosec/armoapi-go/scanfailure directly. -type ScanFailureCase = scanfailure.ScanFailureCase -type WorkloadIdentifier = scanfailure.WorkloadIdentifier -type ScanFailureReport = scanfailure.ScanFailureReport +type ScanFailureCase = upstream.ScanFailureCase +type WorkloadIdentifier = upstream.WorkloadIdentifier +type ScanFailureReport = upstream.ScanFailureReport const ( - ScanFailureCVE = scanfailure.ScanFailureCVE - ScanFailureSBOMGeneration = scanfailure.ScanFailureSBOMGeneration - ScanFailureOOMKilled = scanfailure.ScanFailureOOMKilled - ScanFailureBackendPost = scanfailure.ScanFailureBackendPost + ScanFailureCVE = upstream.ScanFailureCVE + ScanFailureSBOMGeneration = upstream.ScanFailureSBOMGeneration + ScanFailureOOMKilled = upstream.ScanFailureOOMKilled + ScanFailureBackendPost = upstream.ScanFailureBackendPost )🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pulsar/common/scanfailure/types.go` around lines 3 - 10, The public type aliases (ScanFailureCase, WorkloadIdentifier, ScanFailureReport) currently import github.com/armosec/armoapi-go/scanfailure without an alias; change the import to use an explicit alias (e.g., upstream) and update the aliases to reference upstream.ScanFailureCase, upstream.WorkloadIdentifier, and upstream.ScanFailureReport so it’s clear which package is being re-exported and avoids name confusion.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@go.mod`:
- Line 3: Update the Go toolchain line in go.mod from "go 1.24.1" to a newer
1.24.x patch (e.g., 1.24.13) to pick up recent security and bug fixes; after
changing the "go 1.24.1" entry, regenerate module metadata by running the usual
Go module upkeep (e.g., go mod tidy) and verify builds/tests to ensure
compatibility with the new patch release.
In `@pulsar/common/scanfailure/types.go`:
- Around line 12-17: The code references a non-existent package `scanfailure`
and re-exports constants `ScanFailureCVE`, `ScanFailureSBOMGeneration`,
`ScanFailureOOMKilled`, and `ScanFailureBackendPost`, which causes build
failures; remove the import/usages of `scanfailure` and either define these
constants locally in types.go (e.g., string/typed constant values that match the
expected enum names) or import the correct existing package that actually
defines them; update any places that reference the re-exported symbols
(ScanFailureCVE, ScanFailureSBOMGeneration, ScanFailureOOMKilled,
ScanFailureBackendPost) to use the new local constants or the correct package
name so the code compiles.
---
Nitpick comments:
In `@pulsar/common/scanfailure/types.go`:
- Around line 3-10: The public type aliases (ScanFailureCase,
WorkloadIdentifier, ScanFailureReport) currently import
github.com/armosec/armoapi-go/scanfailure without an alias; change the import to
use an explicit alias (e.g., upstream) and update the aliases to reference
upstream.ScanFailureCase, upstream.WorkloadIdentifier, and
upstream.ScanFailureReport so it’s clear which package is being re-exported and
avoids name confusion.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 59610f2b-f1f1-4777-a966-b0e4f27ffdee
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (2)
go.modpulsar/common/scanfailure/types.go
| go 1.23.2 | ||
|
|
||
| toolchain go1.23.3 | ||
| go 1.24.1 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if there are any Go version constraints in CI configuration files
fd -e yml -e yaml | xargs -I {} sh -c 'echo "=== {} ===" && grep -n "go-version\|golang" {} 2>/dev/null || true'Repository: kubescape/messaging
Length of output: 1745
🌐 Web query:
Go 1.24.1 release date stability
💡 Result:
- Release date: Go 1.24.1 was released on March 4, 2025. [1]
- Stability: 1.24.1 is a “minor revision” (patch release)—intended to be a safe, production upgrade within the Go 1.24 line, with security fixes (notably in
net/http) and bug fixes, not breaking changes. [1] - Practical guidance (today): If you’re asking whether 1.24.1 is stable, yes—but it’s outdated; the Go team shipped many subsequent 1.24 patch releases (e.g., go1.24.13 on Feb 4, 2026). In general you should run the latest Go 1.24.x patch for the best security/stability. [1]
Sources:
[1] Go “Release History” (go1.24.1 entry and later 1.24.x entries) — go.dev.
Consider using a newer Go 1.24.x patch release.
Go 1.24.1 is a stable patch release with security fixes and bug fixes. However, as of March 2026, newer patch releases in the 1.24 line are available (e.g., 1.24.13 from February 2026). Consider upgrading to the latest patch release for better security coverage and stability.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@go.mod` at line 3, Update the Go toolchain line in go.mod from "go 1.24.1" to
a newer 1.24.x patch (e.g., 1.24.13) to pick up recent security and bug fixes;
after changing the "go 1.24.1" entry, regenerate module metadata by running the
usual Go module upkeep (e.g., go mod tidy) and verify builds/tests to ensure
compatibility with the new patch release.
| const ( | ||
| // ScanFailureCVE — have SBOM, can't match against vulnerability DBs. | ||
| ScanFailureCVE ScanFailureCase = 1 | ||
| // ScanFailureSBOMGeneration — can't build SBOM from image. | ||
| ScanFailureSBOMGeneration ScanFailureCase = 2 | ||
| // ScanFailureOOMKilled — scanner process was OOM-killed. | ||
| ScanFailureOOMKilled ScanFailureCase = 3 | ||
| // ScanFailureBackendPost — scan succeeded but results couldn't be posted. | ||
| ScanFailureBackendPost ScanFailureCase = 4 | ||
| ScanFailureCVE = scanfailure.ScanFailureCVE | ||
| ScanFailureSBOMGeneration = scanfailure.ScanFailureSBOMGeneration | ||
| ScanFailureOOMKilled = scanfailure.ScanFailureOOMKilled | ||
| ScanFailureBackendPost = scanfailure.ScanFailureBackendPost | ||
| ) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for consumers of these constants in the codebase to understand usage
rg -n "ScanFailure(CVE|SBOMGeneration|OOMKilled|BackendPost)" --type go -g '!vendor/*'Repository: kubescape/messaging
Length of output: 1745
🏁 Script executed:
#!/bin/bash
# First, let's read the file being reviewed to understand the imports
cat -n pulsar/common/scanfailure/types.goRepository: kubescape/messaging
Length of output: 1837
🏁 Script executed:
#!/bin/bash
# Search for the import statement to confirm the upstream package
rg -n "armoapi-go|scanfailure" --type go pulsar/common/scanfailure/types.goRepository: kubescape/messaging
Length of output: 1837
🏁 Script executed:
#!/bin/bash
# Check go.mod to see if armoapi-go is a dependency
cat go.mod | grep -i armoapiRepository: kubescape/messaging
Length of output: 1837
🌐 Web query:
armoapi-go scanfailure package constants export
💡 Result:
In Go (including in armoapi-go), a package-level constant is exported (public) only if its identifier starts with an uppercase letter.
So if the scanfailure package has something like:
package scanfailure
const scanTimeout = "timeout"…it will not be accessible as scanfailure.scanTimeout from another package. Rename it to start with uppercase:
package scanfailure
// ScanTimeout ...
const ScanTimeout = "timeout"Then other packages can use it as:
import "github.com/armosec/armoapi-go/scanfailure"
_ = scanfailure.ScanTimeoutThis is the same pattern used elsewhere in armoapi-go (e.g., containerscan exports constants like UnknownSeverity, CriticalSeverity, etc.). [1]
If you’re running golint, exported constants should also have a doc comment (either per-const or on the const (...) block). [2]
Sources:
[1] https://github.com/armosec/armoapi-go/blob/main/containerscan/consts.go
[2] https://stackoverflow.com/questions/37887756/exported-const-should-have-a-comment
🌐 Web query:
github.com armoapi-go scanfailure ScanFailureCVE
💡 Result:
I looked in armosec/armoapi-go and couldn’t find any identifier or type named ScanFailureCVE (or ScanFailure / scanfailure) in the public source I was able to access.
What is in the repo (relevant to CVEs / scan results):
- The repo exists at
armosec/armoapi-go; its latest GitHub release is v0.0.688 (Mar 12, 2026). [1] - The
containerscanpackage defines scan-result and vulnerability data structures such asVulnerability(with fields likeName,Severity,Fixes, etc.) andScanResultReport, but noScanFailure*types/fields. [2] [3] - There is an errors-oriented stub type:
CommonContainerScanSummaryResultStubincludesErrorsList []string. [2]
If you meant a scan-failure concept in ARMO/Kubescape, it may live in a different repository (e.g., armosec/kubescape) or under a different name than ScanFailureCVE.
Sources: GitHub repo landing/release info [1], raw Go source for containerscan structs [2] [3].
[1] (github.com)
[2] (raw.githubusercontent.com)
[3] (raw.githubusercontent.com)
Citations:
- 1: https://github.com/armosec/armoapi-go
- 2: https://raw.githubusercontent.com/armosec/armoapi-go/main/containerscan/commondatastructures.go
- 3: https://raw.githubusercontent.com/armosec/armoapi-go/main/containerscan/rawdatastrucutres.go
🌐 Web query:
site:github.com/armosec/armoapi-go scanfailure
💡 Result:
GitHub code search shows no matches for scanfailure in armosec/armoapi-go (0 files). [1]
Likewise, searching for ScanFailure (and scanFailure) in the same repo also returns 0 files. [2]
Sources: [1] [2]
Remove the non-existent imports from armoapi-go/scanfailure.
The scanfailure package does not exist in armosec/armoapi-go. GitHub code search shows zero matches for both scanfailure and ScanFailure* across the entire repo. This code will fail to compile because armoapi-go/scanfailure cannot be imported and the constants ScanFailureCVE, ScanFailureSBOMGeneration, ScanFailureOOMKilled, and ScanFailureBackendPost do not exist there.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@pulsar/common/scanfailure/types.go` around lines 12 - 17, The code references
a non-existent package `scanfailure` and re-exports constants `ScanFailureCVE`,
`ScanFailureSBOMGeneration`, `ScanFailureOOMKilled`, and
`ScanFailureBackendPost`, which causes build failures; remove the import/usages
of `scanfailure` and either define these constants locally in types.go (e.g.,
string/typed constant values that match the expected enum names) or import the
correct existing package that actually defines them; update any places that
reference the re-exported symbols (ScanFailureCVE, ScanFailureSBOMGeneration,
ScanFailureOOMKilled, ScanFailureBackendPost) to use the new local constants or
the correct package name so the code compiles.
Add missing zero-value constant to backward-compat re-exports. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Summary:
|
Pin to efa4ba6 which adds the zero-value constant. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pulsar/common/scanfailure/types.go`:
- Line 13: The build fails because ScanFailureUnknown re-export refers to
scanfailure.ScanFailureUnknown which doesn't exist in the pinned armoapi-go;
either update the dependency to a version that exports
scanfailure.ScanFailureUnknown, or add a local backward-compatible fallback in
this package: detect the missing symbol and define a local ScanFailureUnknown
constant equal to the zero value of the scanfailure enum (use the same type as
other re-exports), e.g., mirror how other constants are re-exported in this file
but assign the zero value when scanfailure.ScanFailureUnknown is absent so the
package builds on older armoapi-go versions.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 58e61677-df99-4d46-9220-ddab6b9adb1f
📒 Files selected for processing (1)
pulsar/common/scanfailure/types.go
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Summary:
|
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Summary:
|
1 similar comment
|
Summary:
|
|
Superseded — moving to a two-struct approach: armoapi-go owns the flat wire format, messaging owns the notification struct with workload lists. |
2 participants
Summary
scanfailuretypes fromarmoapi-go/scanfailurefor backward compatibilityarmosec/armoapi-go/scanfailure(PR feat: add scanfailure types for scan failure reporting armosec/armoapi-go#620)kubescape/messaging/pulsar/common/scanfailurecontinue to work unchangedContext
Part of SUB-7074 (scan failure notifications). Moving API contract types to armoapi-go where they belong.
Test plan
go build ./...passesSummary by CodeRabbit
Chores
Refactor