Wrong ref set for cache on release.type.published with explicit branch checkout

[iamolegga]

I have a workflow that is triggered on release

on:
  release:
    types: [published]

And I set ref to main branch explicitly for checkout action, because cache with tags' refs are cannot be reused for feature branches, see #556 . Checking out for main branch is ok for me as it's the same code version as the last release.

      - name: Checkout main branch
        uses: actions/checkout@v3
        with:
          ref: main

Anyway the cache is created with the tag ref

curl \
  -H "Accept: application/vnd.github.v3+json" \
  -H "Authorization: token MY_TOKEN" \
  https://api.github.com/repos/org/repo/actions/caches

{
  "total_count": 5,
  "actions_caches": [
    {
      "id": 8,
      "ref": "refs/tags/<TAG>",
      "key": "MY_KEY",
      "version": "...",
      "last_accessed_at": "2022-07-04T11:58:15.810000000Z",
      "created_at": "2022-07-04T11:58:15.810000000Z",
      "size_in_bytes": 76343
    },
    ...
  ]
}

And for the feature branch the cache is not visible anyway:

Run actions/cache@v3
Cache not found for input keys: MY_KEY

[iamolegga]

Anyway for those who struggle I found a workaround, make a separate workflow with

on:
  workflow_run:
    types: [completed]
    workflows: [Original workflow]

then the cache is created successfully.

[bishal-pdMSFT]

@iamolegga a tag can only read caches from the base branch from which it was cut off. This is by design. A branch can share cache from its base branch but a tag is not that.

[iamolegga]

I create release (= git tag) on main branch, within this release workflow I create cache, this is still main branch. But this cache on main branch which creation was triggered by release is not available for feature-branches that are rebased on top of it. I'm not sure that such behavior is correct. If so, I believe this should be mentioned in the docs if it's not yet

[bishal-pdMSFT]

This is mentioned in the doc

Access restrictions provide cache isolation and security by creating a logical boundary between different branches. For example, a cache created for the branch feature-a (with the base main) would not be accessible to a pull request for the branch feature-c (with the base main).

This same behavior holds true for tags as well. Agree that tags behavior is explicitly not mentioned in the docs but probably it was not deemed necessary to do so separately.

[bishal-pdMSFT]

This is mentioned in the doc

Access restrictions provide cache isolation and security by creating a logical boundary between different branches. For example, a cache created for the branch feature-a (with the base main) would not be accessible to a pull request for the branch feature-c (with the base main).

This same behavior holds true for tags as well. Agree that tags behavior is explicitly not mentioned in the docs but probably it was not deemed necessary to do so separately.

[iamolegga]

For me it's not clear that cache created on default branch is not accessible for child branches when it's created by the tag. It's up to you, if you believe that this should not be mentioned in the docs let it be so

[bishal-pdMSFT]

Got it. It wouldn't harm to mention this explicitly in the docs. Let me plan for that.

[bishal-pdMSFT]

The doc section is updated to call out the scope restrictions more clearly. Also added a sentence about tags scope.