Repo sync

.github/actions/retry-command/action.yml

@@ -7,11 +7,11 @@ inputs:
   max_attempts:
     description: 'Maximum number of retry attempts'
     required: false
-    default: '8'
+    default: '12'
   delay:
     description: 'Delay between attempts in seconds'
     required: false
-    default: '15'
+    default: '30'
 
 runs:
   using: 'composite'

content/actions/concepts/workflows-and-actions/dependency-caching.md

@@ -0,0 +1,33 @@
+---
+title: Dependency caching
+shortTitle: Dependency caching
+intro: 'Learn about dependency caching for workflow speed and efficiency.'
+versions:
+  fpt: '*'
+  ghes: '*'
+  ghec: '*'
+type: overview
+topics:
+  - Workflows
+---
+
+## About workflow dependency caching
+
+Workflow runs often reuse the same outputs or downloaded dependencies from one run to another. For example, package and dependency management tools such as Maven, Gradle, npm, and Yarn keep a local cache of downloaded dependencies.
+
+{% ifversion fpt or ghec %} Jobs on {% data variables.product.prodname_dotcom %}-hosted runners start in a clean runner image and must download dependencies each time, causing increased network utilization, longer runtime, and increased cost. {% endif %}To help speed up the time it takes to recreate files like dependencies, {% data variables.product.prodname_dotcom %} can cache files you frequently use in workflows.
+
+{%- ifversion fpt or ghec %}
+
+> [!NOTE]
+> When using self-hosted runners, caches from workflow runs are stored on {% data variables.product.company_short %}-owned cloud storage. A customer-owned storage solution is only available with {% data variables.product.prodname_ghe_server %}.
+
+{%- endif %}
+
+{% data reusables.actions.comparing-artifacts-caching %}
+
+For more information on workflow run artifacts, see [AUTOTITLE](/actions/using-workflows/storing-workflow-data-as-artifacts).
+
+## Next steps
+
+To implement dependency caching in your workflows, see [AUTOTITLE](/actions/reference/dependency-caching-reference).

content/actions/concepts/workflows-and-actions/index.md

@@ -13,6 +13,7 @@ children:
   - /about-custom-actions
   - /contexts
   - /expressions
+  - /dependency-caching
   - /about-monitoring-workflows
   - /notifications-for-workflow-runs
   - /about-troubleshooting-workflows

content/actions/how-tos/managing-workflow-runs-and-deployments/managing-workflow-runs/index.md

@@ -15,9 +15,9 @@ children:
   - /deleting-a-workflow-run
   - /downloading-workflow-artifacts
   - /removing-workflow-artifacts
+  - /manage-caches
   - /approving-workflow-runs-from-public-forks
   - /approving-workflow-runs-from-private-forks
 redirect_from:
   - /actions/managing-workflow-runs-and-deployments/managing-workflow-runs
 ---
-

content/actions/how-tos/managing-workflow-runs-and-deployments/managing-workflow-runs/manage-caches.md

@@ -0,0 +1,84 @@
+---
+title: Managing caches
+intro: 'You can monitor, filter, and delete dependency caches created from your workflows.'
+versions:
+  fpt: '*'
+  ghes: '*'
+  ghec: '*'
+shortTitle: Manage caches
+allowTitleToDifferFromFilename: true
+---
+
+This article describes managing caches with the {% data variables.product.prodname_dotcom %} web interface, but you can also manage them:
+
+* Using the REST API. See [AUTOTITLE](/rest/actions/cache).
+* With the `gh cache` subcommand from the command line. See the [GitHub CLI documentation](https://cli.github.com/manual/gh_cache).
+
+## Viewing cache entries
+
+You can use the web interface to view a list of cache entries for a repository. In the cache list, you can see how much disk space each cache is using, when the cache was created, and when the cache was last used.
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.actions-tab %}
+{% data reusables.repositories.actions-cache-list %}
+1. Review the list of cache entries for the repository.
+
+   * To search for cache entries used for a specific branch, click the **Branch** dropdown menu and select a branch. The cache list will display all of the caches used for the selected branch.
+   * To search for cache entries with a specific cache key, use the syntax `key: key-name` in the **Filter caches** field. The cache list will display caches from all branches where the key was used.
+
+   ![Screenshot of the list of cache entries.](/assets/images/help/repository/actions-cache-entry-list.png)
+
+## Deleting cache entries
+
+Users with `write` access to a repository can use the {% data variables.product.prodname_dotcom %} web interface to delete cache entries.
+
+{% data reusables.repositories.navigate-to-repo %}
+{% data reusables.repositories.actions-tab %}
+{% data reusables.repositories.actions-cache-list %}
+1. To the right of the cache entry you want to delete, click {% octicon "trash" aria-label="Delete cache" %}.
+
+   ![Screenshot of the list of cache entries. A trash can icon, used to delete a cache, is highlighted with a dark orange outline.](/assets/images/help/repository/actions-cache-delete.png)
+
+## Force deleting cache entries
+
+Caches have branch scope restrictions in place, which means some caches have limited usage options. For more information on cache scope restrictions, see [AUTOTITLE](/actions/reference/dependency-caching-reference#restrictions-for-accessing-a-cache). If caches limited to a specific branch are using a lot of storage quota, it may cause caches from the `default` branch to be created and deleted at a high frequency.
+
+For example, a repository could have many new pull requests opened, each with their own caches that are restricted to that branch. These caches could take up the majority of the cache storage for that repository. {% data reusables.actions.cache-eviction-policy %} In order to prevent cache thrashing when this happens, you can set up workflows to delete caches on a faster cadence than the cache eviction policy will. You can use the {% data variables.product.prodname_cli %} to delete caches for specific branches.
+
+The following example workflow uses `gh cache` to delete up to 100 caches created by a branch once a pull request is closed.
+
+To run the following example on cross-repository pull requests or pull requests from forks, you can trigger the workflow with the `pull_request_target` event. If you do use `pull_request_target` to trigger the workflow, there are security considerations to keep in mind. For more information, see [AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows#pull_request_target).
+
+```yaml
+name: Cleanup github runner caches on closed pull requests
+on:
+  pull_request:
+    types:
+      - closed
+
+jobs:
+  cleanup:
+    runs-on: ubuntu-latest
+    permissions:
+      actions: write
+    steps:
+      - name: Cleanup
+        run: |
+          echo "Fetching list of cache keys"
+          cacheKeysForPR=$(gh cache list --ref $BRANCH --limit 100 --json id --jq '.[].id')
+
+          ## Setting this to not fail the workflow while deleting cache keys.
+          set +e
+          echo "Deleting caches..."
+          for cacheKey in $cacheKeysForPR
+          do
+              gh cache delete $cacheKey
+          done
+          echo "Done"
+        env:
+          GH_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
+          GH_REPO: {% raw %}${{ github.repository }}{% endraw %}
+          BRANCH: refs/pull/{% raw %}${{ github.event.pull_request.number }}{% endraw %}/merge
+```
+
+Alternatively, you can use the API to automatically list or delete all caches on your own cadence. For more information, see [AUTOTITLE](/rest/actions/cache#about-the-cache-in-github-actions).

content/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/index.md

@@ -21,6 +21,5 @@ children:
   - /using-environments-for-deployment
   - /control-the-concurrency-of-workflows-and-jobs
   - /running-variations-of-jobs-in-a-workflow
-  - /caching-dependencies-to-speed-up-workflows
   - /storing-and-sharing-data-from-a-workflow
 ---