@YoshikiKubotani Does this sound reasonable to you? Especially I want to hear your option about my assumption that use of image registry cache it rare case.

@gatheluck
As far as I see from the second link above, the cache action searches both branches that are included by the pull request.
So would it really be out of search if we create a new PR? I am unsure about where the caches are stored (so I might be saying a weird thing), but wouldn't it work fine if there is a cache key in the develop branch?

1. Key npm-feature-d5ea0750 in the feature branch
2. Key npm-feature- in the feature branch
3. Key npm- in the feature branch
4. Key npm-feature-d5ea0750 in the main branch
5. Key npm-feature- in the main branch
6. Key npm- in the main branch

Thank you for your comment!

As far as I see from the second link above, the cache action searches both branches that are included by the pull request.

Yes, but when brand new PR is created, basically there is no cache linked to the branch. So the first time you run CI by new PR, you cannot use cache. I faced this issue multiple times and find this issue report: https://stackoverflow.com/questions/69365200/github-actions-how-to-cache-dependencies-between-workflow-runs-of-different-bra

wouldn't it work fine if there is a cache key in the develop branch?

Unfortunately this is no. Because Cache scopes works first, then inside of the scope cache is searched based on cache key. So "caches belonging to the same branch name" and "caches belonging to the default branch" are only target of cache search.

Actually I tested these only my forked Ascender branch. When new PR is created first CI run tool long time because there is no cache hit.

• https://github.com/gatheluck/Ascender/actions/runs/3404844190/attempts/1 : 2m 44s
• https://github.com/gatheluck/Ascender/actions/runs/3404844190/attempts/2 : 59s

But after adding CI job for default branch it became:

• https://github.com/gatheluck/Ascender/actions/runs/3426982440/attempts/1: 1m 12s
• https://github.com/gatheluck/Ascender/actions/runs/3426982440/attempts/2: 1m 10s

Sure.
To sum up,

• We want to use a cache when raising a PR for merging a new branch with 'develop'
• But it cannot be possible because
  • the cache action only covers the default branch (i.e. in many cases 'main' or 'master') and the branch where that workflow is called, and
  • both branches do not have a cache in our case as the former is not relevant to the PR and the latter is the newly created branch.
• So we should create a cache in the default branch as well for the cache action to be able to find the cache when the CI runs.

Is my understanding correct?

As for the image registry cache, I also believe we do not often face the situation of using multiple containers in the research context.

We want to use a cache when raising a PR for merging a new branch with 'develop'
But it cannot be possible because
the cache action only covers the default branch (i.e. in many cases 'main' or 'master') and the branch where that workflow is called, and
both branches do not have a cache in our case as the former is not relevant to the PR and the latter is the newly created branch.
So we should create a cache in the default branch as well for the cache action to be able to find the cache when the CI runs.
Is my understanding correct?

Thank you! This is correct!

As for the image registry cache, I also believe we do not often face the situation of using multiple containers in the research context.

Thank you so much! Then I start working on this ticket.