-
Notifications
You must be signed in to change notification settings - Fork 2.8k
refactor(cli): Rework Trivy Cloud integration logic #9717
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
refactor(cli): Rework Trivy Cloud integration logic #9717
Conversation
📊 API Changes DetectedSemver impact: |
4834c6c to
17dbf9a
Compare
76475e3 to
d319541
Compare
pkg/cloud/config.go
Outdated
| return &config, nil | ||
| configFilename := filepath.Join(configDir, "config.yaml") | ||
| // Return cached config if it was updated within the last hour | ||
| if stat, err := os.Stat(configFilename); err == nil && stat.ModTime().After(time.Now().Add(configCacheTTL)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correct me, if i an wrong or missing something.
I see two problems with this:
1. After one hour, we’ll download the file again.
2. If the user finds an issue in the config on the server and updates the file there, they’ll need to remove the local file to download the new one from the server.
Maybe we could send the hash of the local file to the server?
Server will have the hash of the config file and will compare it.
If the hash is empty (config file doesn’t exist) or doesn’t match, the server will send a new config file.
If the config is still valid, there’s no need to send the file again (unwrap it, etc.).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll give this some thought - The config isn't user maintainable so we will have prepared and tested it, but I can see the argument for wanting to invalidate the cache quickly if there is a network issue during download or similar.
I'll have a think
d319541 to
a80a0fa
Compare
a80a0fa to
756a70c
Compare
c1ea59a to
b406f73
Compare
DmitriyLewen
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
d319e19 to
a027e52
Compare
8a4e75f to
ed7587f
Compare
ed7587f to
9442b38
Compare
After having discussions internally, the logic for working with the Trivy Cloud integration is going to be simplified greatly. This involves removing the Cloud specific config file and bringing the config into the existing Trivy config. The `cloud config` commands will be removed as they aren't needed anymore. As the focus is going to be on CI/CD integration with the Trivy Cloud platform, there isn't currently a need to have the Login and Logout mechanisms.
Updates based on the PR comments and regeneration of the docs
Co-authored-by: DmitriyLewen <[email protected]>
Updates to logging and tests based on the PR comments
Co-authored-by: DmitriyLewen <[email protected]>
9442b38 to
d04c73f
Compare
Description
After having discussions internally, the logic for working with the Trivy Cloud integration is going to be simplified greatly. This involves removing the Cloud specific config file and bringing the config into the existing Trivy config. The
cloud configcommands will be removed as they aren't needed anymore.As the focus is going to be on CI/CD integration with the Trivy Cloud platform, there isn't currently a need to have the
LoginandLogoutand credential storage, so this has been removed.Docs have been updated to remove the
cloud configdocs.Related issues
Remove this section if you don't have related PRs.
Checklist