-
Notifications
You must be signed in to change notification settings - Fork 71
Description
Describe the bug
Our current CI configuration forces full rebuilds on every workflow execution, even when running a small and targeted subset of tests (e.g. NodeJS and Python sample service tests). This significantly increases CI execution time and resource usage.
Ideally, build-related tasks (such as Java compilation) should be reused via Gradle up-to-date checks and build cache, and CI workflows should focus on executing only the relevant test suites when no related code has changed.
It appears there are different issues and inconsistencies involved. Firstly, Gradle remote build cache access is unreliable, sometimes failing with 401 or 403 responses when attempting to store/retrieve cache entries:
Could not store entry <cachekey> in remote build cache: Storing entry at 'https://zowe.jfrog.io/zowe/cache/<cachekey>' response status 401:
As a result, CI workflows are often unable to reliably reuse cached build outputs across multiple runs, reducing the effectiveness of the remote build cache.
In addition, many tasks explicitly disable Gradle’s incremental build and caching mechanisms by using:
outputs.upToDateWhen { false }
outputs.cacheIf { false }
This probably causes Gradle to always recompile and always rerun tests and skip any caching.
The Verify that all services can register is the slowest workflow (runStartUpCheck), taking around 20 minutes to be completed. In this case, probably the slowness goes beyond the caching issue.
Additional context
Add any other context about the problem here.
Willingness to help
If you are willing to help with debugging and reproducing the problem or
with fixing the problem, please state your willingness to assist in the created issue.
Metadata
Metadata
Assignees
Type
Projects
Status