refactor: use google/wire for cache

[knqyf263]

Description

This PR simplifies the cache initialization process in the artifact scanning. Previously, we initialized the cache.Cache instance within pkg/commands/artifact/run.go to support --clear-cache and --reset operations. However, these operations have been moved to the trivy clean command.

With this change, we can now generate the cache.Cache instance through google/wire, which is consistent with other instances in the project.

Changes

• Remove the initCache function from pkg/commands/artifact/run.go
• Update the wire injection to include cache.Cache generation
• Adjust the artifact scanning initialization process to use the wire-generated cache instance

Benefits

• Improved consistency in scanner initialization across the project
• Simplified code structure in the artifact scanning module
• Better alignment with the project's dependency injection pattern using wire

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[DmitriyLewen]

LGTM
left a couple comments.

[DmitriyLewen]

i am not sure that we need to add this here.
We show cache dir for server mode:

trivy/pkg/commands/server/run.go

Line 27 in 5751870

log.Debug("Cache", log.String("dir", opts.CacheDir))

(perhaps it make sense to move this to

trivy/pkg/cache/remote.go

Lines 31 to 47 in 5751870

	func NewRemoteCache(opts RemoteOptions) *RemoteCache {
	ctx := client.WithCustomHeaders(context.Background(), opts.CustomHeaders)
	httpClient := &http.Client{
	Transport: &http.Transport{
	Proxy: http.ProxyFromEnvironment,
	TLSClientConfig: &tls.Config{
	InsecureSkipVerify: opts.Insecure,
	},
	},
	}
	c := rpcCache.NewCacheProtobufClient(opts.ServerAddr, httpClient)
	return &RemoteCache{
	ctx: ctx,
	client: c,
	}
	}

)

Also we show this log for redis cache (cache directory information when using redis can be confusing for users).

But we need to add this log to

trivy/pkg/cache/fs.go

Line 22 in 5751870

func NewFSCache(cacheDir string) (FSCache, error) {

[knqyf263]

Also we show this log for redis cache (cache directory information when using redis can be confusing for users).

--cache-dir is effective more than the scan cache. It also affects the vulnerability DB and the Java DB.

[knqyf263]

We show cache dir for server mode:

Deleted 1ab584e

[DmitriyLewen]

--cache-dir is effective more than the scan cache. It also affects the vulnerability DB and the Java DB.

hm... you are right.
Let's update redis log then (e.g. Redis scan cache):

trivy/pkg/cache/redis.go

Line 91 in 1ab584e

log.Info("Redis cache", log.String("url", opts.BackendMasked()))

[knqyf263]

BTW, I'm not sure scan cache is a good name. I tentatively named it "scan cache" because we needed a different name to distinguish between a general cache, including DB, and a specific cache for storing analysis results (fanal cache), but there are other candidates, such as "layer cache" or "analysis cache". What do you think?

[DmitriyLewen]

I don't like layer cache. User may think that we store layers (I mean files from layers), but we only store layer IDs.

analysis cache looks good.

[knqyf263]

I don't like layer cache. User may think that we store layers (I mean files from layers), but we only store layer IDs.

Right. That's why I didn't choose it.

While "analysis cache" describes the internal logic well, the "analyzer" concept is not exported to end users. I'm not sure people understand "analysis cache". Anyway, I'll change it to Redis scan cache for now. I'll open another issue to discuss the naming.

[knqyf263]

Fixed 2868b08

[DmitriyLewen]

the "analyzer" concept is not exported to end users. I'm not sure people understand "analysis cache"

We, as maintainers, constantly work with analyzers and are accustomed to this term, so perhaps scan cache does not seem to be best choice for us, but perhaps it will be clearer for users

I'll open another issue to discuss the naming.

Anyway, let's listen to the users

[knqyf263]

@DmitriyLewen Please feel free to leave any comments.
#7034