Error on outlining if we use multiple directories with same go modules
kranurag7 opened this issue · comments
Anurag commented
What happened:
I'm using bom to generate SBOM for kubearmor project. Here's the issue I'm facing.
I have a config file .sbom.yaml
namespace: https://kubearmor.io # an URI that serves as namespace for the SPDX doc
license: Apache-2.0 # SPDX license identifier to declare in the SBOM
name: kubearmor sbom #name for the document, in contrast to URLs, intended for humans
creator:
person: Anurag
tool: bom
artifacts:
- type: directory # Valid choices are "directory" or "file" or "image"
source: ./KubeArmor # Path to container in registry if type is "image" else path to directory or file
gomodules: true # Boolean. Set it to true if this artifact is a gomodule.
- type: directory
source: ./deployments
gomodules: true
- type: directory
source: ./KubeArmor/BPF/tests
gomodules: true
- type: directory
source: ./pkg/KubeArmorAnnotation
gomodules: true
- type: directory
source: ./pkg/KubeArmorController
gomodules: true
- type: directory
source: ./pkg/KubeArmorHostPolicy
gomodules: true
- type: directory
source: ./pkg/KubeArmorPolicy
gomodules: true
- type: image # Valid choices are "directory" or "file" or "image"
source: kubearmor/kubearmor:latest # Path to container in registry if type is "image" else path to directory or file
license: Apache-2.0 # SPDX identifier of the license
- type: image
source: kubearmor/kubearmor-init:latest
license: Apache-2.0
- type: file # Valid choices are "directory" or "file" or "image"
source: Dockerfile # Path to container in registry if type is "image" else path to directory or file
license: Apache-2.0 # SPDX identifier of the license
- I generate the SBOM using the command
bom generate --config .sbom.yaml >> bomsbom.md
Now, when I use bom document outline bomsbom.md
and the error I'm getting is
$ bom document outline bomsbom.md
FATA opening doc: duplicate SPDXID SPDXRef-Package-gomod-k8s.io-utils-v0.0.0-20220823124924-e9cbc92d1a73
What you expected to happen:
- I think there should be an alternate approach to handle duplicate go-modules instead of throwing error.
How to reproduce it (as minimally and precisely as possible):
- The steps to reproduce are listed above.
Anything else we need to know?:
- bom version: v0.4.0
Environment:
- Cloud provider or hardware configuration: aaaaaaaaaaaaa
- OS (e.g:
cat /etc/os-release
): Ubuntu 20.04 - Kernel (e.g.
uname -a
): 5.4.0-1090-azure - Others:
Tasks
No tasks being tracked yet.
Kubernetes Triage Robot commented
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale
- Mark this issue or PR as rotten with
/lifecycle rotten
- Close this issue or PR with
/close
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale