It cannot be restored by the base branch or other pull requests targeting that base branch. Because of this, the cache will have a limited scope and can only be restored by re-runs of the pull request. When a cache is created by a workflow run triggered on a pull request, the cache is created for the merge ref ( refs/pull/./merge). For example, a cache created for the tag release-a with the base main would not be accessible to a workflow run triggered for the tag release-b with the base main. Workflow runs also cannot restore caches created for different tag names.
Similarly, a cache created for the feature-a branch with the base main would not be accessible to its sibling feature-c branch with the base main. For example, a cache created for the child feature-b branch would not be accessible to a workflow run triggered on the parent main branch. Workflow runs cannot restore caches created for child branches or sibling branches. For example, if the branch feature-b has the base branch feature-a, a workflow run triggered on a pull request would have access to caches created in the default main branch, the base feature-a branch, and the current feature-b branch. If a workflow run is triggered for a pull request, it can also restore caches created in the base branch, including base branches of forked repositories. Workflow runs can restore caches created in either the current branch or the default branch (usually main).
Use artifacts when you want to save files produced by a job to view after a workflow run has ended, such as built binaries or build logs.įor more information on workflow run artifacts, see " Storing workflow data as artifacts." Restrictions for accessing a cache #Īccess restrictions provide cache isolation and security by creating a logical boundary between different branches or tags. Use caching when you want to reuse files that don't change often between jobs or workflow runs, such as build dependencies from a package management system. A customer-owned storage solution is only available with GitHub Enterprise Server.Ĭomparing artifacts and dependency caching #Īrtifacts and caching are similar because they provide the ability to store files on GitHub, but each feature offers different use cases and cannot be used interchangeably. When using self-hosted runners, caches from workflow runs are stored on GitHub-owned cloud storage. Forks of a repository can also create pull requests on the base branch and access caches on the base branch. Anyone with read access can create a pull request on a repository and access the contents of a cache. Also, command line interface (CLI) programs like docker login can save access credentials in a configuration file. For example, sensitive information can include access tokens or login credentials stored in a file in the cache path. We recommend that you don't store any sensitive information in the cache. Warning: Be mindful of the following when using caching with GitHub Actions: Alternatively, if you are caching the package managers listed below, using their respective setup-* actions requires minimal configuration and will create and restore dependency caches for you. The action creates and restores a cache identified by a unique key. To cache dependencies for a job, you can use GitHub's cache action. To help speed up the time it takes to recreate files like dependencies, GitHub can cache files you frequently use in workflows. 
#Large amount of private cache download
Jobs on GitHub-hosted runners start in a clean runner image and must download dependencies each time, causing increased network utilization, longer runtime, and increased cost. For example, package and dependency management tools such as Maven, Gradle, npm, and Yarn keep a local cache of downloaded dependencies. Workflow runs often reuse the same outputs or downloaded dependencies from one run to another.
0 kommentar(er)
