Skip to content
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

feat: improve db update check #2020

Closed

Conversation

kzantow
Copy link
Contributor

@kzantow kzantow commented Jul 31, 2024

There have been multiple reports about issues while attempting to check for database updates. We think it will be good to address these on multiple fronts. One of the things we can do instead of downloading a listing file of ~150Kb every time Grype is run is to use the standard If-Modified-Since behavior and track a useable time we obtained the database to include in this header.

This PR adds an Updated field to the metadata, which is set at db download time and used when further requests are made for the database to prevent downloading the file when it won't be used anyway.

@kzantow kzantow force-pushed the feat/if-modified-since-header branch from 24439aa to 0942add Compare July 31, 2024 04:58
@@ -148,13 +152,14 @@ func (c *Curator) Update() (bool, error) {
defer downloadProgress.SetCompleted()
defer importProgress.SetCompleted()

updateAvailable, metadata, updateEntry, err := c.IsUpdateAvailable()
metadata := c.GetMetadata()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we always download the listing on grype db check and grype db update?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so, if we reliably know they are already up-to-date, why waste CPU cycles/network?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am pessimistically assuming that something will go wrong, and having a command that means, "no really, I mean it, download that database whether you need to or not" might be helpful.

The goal of this change is to alleviate traffic. Making rare commands less useful isn't going to alleviate traffic.

But I do see your point.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how this is making commands less useful, they all continue to function exactly as they do: if we downloaded a listing file and got the latest database, we have the latest database, so downloading a listing again and downloading the database again is rather pointless. I think I understand your point, though. I'll see about making this particular function isolated as much as possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think as a user, I would prefer grype db update to be efficient and use this function to eliminate unnecessary downloads if it's already up-to-date. Maybe we add a --force argument or similar to make it download everything anew?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants