Allow to define cache ID explicitely

[realdadfish]

Jenkins and plugins versions report

not applicable

What Operating System are you using (both controller, and any agents involved in the problem)?

not applicable

Reproduction steps

1. Configure the jobcacher plugin with an ArbitraryFileCache pointing to a Jenkins workspace with an absolute path
2. See that default caches can't be re-used across builds because the cache identity changed

Expected Results

Cache identity should not be reliant on the path to the data that are stored, but just some unique, user-chosen identifier.

Actual Results

Cache identity is reliant on the path.

Anything else?

In ArbitraryFileCache.java the base name of the cache is generated as follows:

    public String createCacheBaseName() {
        String generatedCacheName = deriveCachePath(path);
        if (StringUtils.isEmpty(this.cacheName)) {
            return generatedCacheName;
        }

        return generatedCacheName + CACHE_FILENAME_PART_SEP + this.cacheName;
    }

Now, if one follows the documentation of the plugin stating

path | yes |   | The path to cache. It can be absolute or relative to the workspace.

and configures this variable to be $WORKSPACE/some-path, the absolute, node-specific and even more problematic, job-specific path to the workspace is set to path. This results in the problem that a fallback to a "default" cache can never succeed, as the new jobs / branches $WORKSPACE of course resides somewhere else. The plugin then outputs this, even though there does exist a cache in the configured S3 bucket for the default branch:

16:37:33  [Cache for /home/jenkins/workspace/repo_framework_serializer-bugfix/.gradle (gradle-framework) with id ae37528f1c8477b42d970ef4e4f10fa3] Searching cache in job specific caches...
16:37:33  [Cache for /home/jenkins/workspace/repo_framework_serializer-bugfix/.gradle (gradle-framework) with id ae37528f1c8477b42d970ef4e4f10fa3] Searching cache in default caches...
16:37:33  [Cache for /home/jenkins/workspace/repo_framework_serializer-bugfix/.gradle (gradle-framework) with id ae37528f1c8477b42d970ef4e4f10fa3] Skip restoring cache as no up-to-date cache exists

Are you interested in contributing a fix?

No response

[repolevedavaj]

@realdadfish I was not aware that some env vars are resolved before being passed to the plugin. Are you using the pipeline step or the wrapper?

[realdadfish]

I'm using the pipeline step. Again, I think the easiest would be to differentiate between cache path and cache identity. The cache path can be configured to be anything by the consumer, even some workspace-specific absolute path. The cache identity on the other hand should really be chosen explicitely and not be derived from something else implicitely.

[repolevedavaj]

I see your point, but I am not sure why you consider that as a bug. You can use absolute paths but if they differ from agent to agent, then this is it the way the plugin works right now. Instead of passing a absolute path, you could just use a relative one, no?

If you really need env vars you need to make sure that you are not evaluating them before passing the string to the plugin (e.g. instead of "$WORKSPACE/some-path", use '$WORKSPACE/some-path'). Before actually using the path, the plugin will evaluate all env vars, but this happens after generating the id.

[realdadfish]

Well, it's undocumented that the plugin behaves this way. IMHO it should be documented that the identity of the cache is computed from the path and the name of the cache. Am 10. Februar 2024 14:45:49 MEZ schrieb repolevedavaj ***@***.***>:

I see your point, but I am not sure why you consider that as a bug. You can use absolute paths but if they differ from agent to agent, then this is it the way the plugin works right now. Instead of passing a absolute path, you could just use a relative one, no? If you really need env vars you need to make sure that you are not evaluating them before passing the string to the plugin (e.g. instead of `"$WORKSPACE/some-path"`, use `'$WORKSPACE/some-path'`). Before actually using the path, the plugin will evaluate all env vars, but this happens after generating the id. -- Reply to this email directly or view it on GitHub: #257 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

-- Thomas Keller - https://thomaskeller.biz

[repolevedavaj]

Yes, I agree. The way the caching is actually working is quite undocumented.