Allow caching for deployment events or other events without GITHUB_REF

[localheinz]

As suggested in #317 and #318, I would like to be able to use actions/cache for events where the GITHUB_REF environment variable is not necessarily defined.

For example, I currently have decoupled the creation and the processing of deployments.

• one ore more workflows create deployment (with differing payloads) using the Deployments API
• a workflow is triggered by a deployment event and process the actual deployment to different environments

Currently, even with #263, it is not possible to use caching for the deployment event (see @joshmgross' comments in #317). Consequently, deployments using a workflow setup describes as above either take a lot longer, or are not feasible.

It would be really nice to be able to use actions/cache with a setup as described!

Let me know if there is anything I can do to help push this feature through the door.

🌱

[RichiCoder1]

Would love this for the exact reason of deployment events.

[BrendanSChang]

Any news on this? I have the same use case/workflow and would love to see this enhancement as well.

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity. Leave a comment to avoid closing this issue in 5 days.

[RichiCoder1]

Leaving a comment to avoid closing this issue in 5 days.

[jimCresswell]

I'm running into the same issue with deployment_status events.

[Fedeorlandau]

This would be massive for us. We're running cypress after Vercel's deployment.

name: Run E2E Tests
on: [deployment_status]
jobs:
  e2e:
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '14'
          cache: 'yarn'
      - run: yarn
      - run: yarn cypress:headless --env host=${{ github.event.deployment_status.target_url }}

[jimCresswell]

@Fedeorlandau I have a very similar issue. I need to run various checks after a @Vercel deployment_status event, but their event sets the ref field to have the value of the SHA rather than of the branch that triggered their Github app, so the environment variable GITHUB_REF is undefined. I don't know if there is a good reason for that. I've started a related discussion in the Vercel repo https://github.com/vercel/vercel/discussions/7581 .

I've created a custom action to figure out the ref for a pull request from the SHA (under the assumption that there are unlikely to be multiple PRs with the same head SHA), but unfortunately (and probably sensibly) it's not possible to override the value of GITHUB_REF. It would be useful if actions/cache supported an override value that could be set, e.g. OVERRIDE_GITHGUB_REF=refs/heads/some_branch.

[Magellol]

We're running onto this issue as well. We have two workflows:

• build.yml which creates a deployment on Github with a ref attached to the current commit being built
• deploy.yml which runs on event: deployment and actually deploys the app

Currently we'd want to restore yarn dependencies on deploy.yml but the action/cache is skipped because of the aforementioned issue so it takes longer to run.

[joegaudet]

Hey all, I use github actions to deploy my apps, would really love it if this action worked for it.

Currently a process that takes 1m on all the other branches, takes 15min on deployment.

There must be some way to avoid this.

[adiqa]

Hey everyone, it would be really beneficial to have it, we are also running cypress after Vercel's deployment.

Besides that, I'm experiencing this issue when I implement matrix for parallelization

[donhessman]

Any updates or recommended workarounds on this issue?

[Benchingco25]

• name: Cache uses: actions/cache@v1.2.1

[aylton-almeida]

Is there any update on this? Would be really helpful here too

[Benchingco25]

Duplicate of #

[jimCresswell]

Duplicate of #

Hi @Benchingco25 , that link is missing an issue number

[andobolocco]

+1 hard to keep track of a feature-request with this being spread in duplicated issues https://github.com/actions/cache/issues/598 https://github.com/actions/cache/discussions/516

[tymocoder]

The same: Run cypress-io/github-action@v5 Warning: Failed to restore: Cache service responded with 403

========================= yml below ======= on: [ deployment_status ]

jobs: e2e: if: github.event.deployment_status.state == 'success' runs-on: ubuntu-latest

steps:
  - name: Checkout
    uses: actions/checkout@v3
  - name: Use NodeJS
    uses: actions/setup-node@v3
    with:
      node-version: '18.x'
      cache: 'npm'
  - name: Cypress tests run
    uses: cypress-io/github-action@v5
    with:
      browser: chrome
    env:
      CYPRESS_BASE_URL: ${{ github.event.deployment_status.target_url }}
      CYPRESS_RETRIES: 1

[theodiablo]

It would be a real improvement for us. At the moment, we can't use any caching at all on our GHA workflows given that they are all triggered from Seed. (Could potentially save us around 10 mins per build) Given the amount of people on this thread, and the multiple issues related to it, it seems that we are not alone and there is a real need from the community here.

aparna-ravindra I've seen you commented in another thread, so I tag you here too. What would be the changes required to allow this to work? Is there anyone who has enough knowledge to propose a design to solve this, even if delegating the implementation to someone else by providing enough guidance to do it?

[theodiablo]

Trying to ping some of the latest maintainers of this project to see if they have enough knowledge about this issue, or point us to someone else who has and could propose a design to solve this: @Phantsure, @chkimes, @dhadka, @kotewar

[jimCresswell]

Fundamentally Vercel needs to know the name of the branch that triggered the build, and to report that back as part of the deployment/deployment_status event. I may well be oversimplifying, and I have no idea about the Vercel architecture, but I've done similar work for a Netlify plugin that reports deployments back to GitHub.

[theodiablo]

Thanks for your answer @jimCresswell So, does that mean that we can already solve this without touching the actions/cache workflow?

Do you know by any chance which parameter should be set to allow this to work when creating the deployment_status event? I'm not seeing it in the Deployment Status API Doc

[jimCresswell]

@theodiablo my bad, the ref is set when the deployment is created, then that deployment ID is passed in the deployment status events. The issue can be solved without touching actions/cache, but it could also potentially be solved by altering which paramters are used in actions/cache to create the cache key in workflows triggered by deployment events.

[jimCresswell]

Fundamentally Vercel needs to know the name of the branch that triggered the build, and to report that back as part of the deployment/deployment_status event. I may well be oversimplifying, and I have no idea about the Vercel architecture, but I've done similar work for a Netlify plugin that reports deployments back to GitHub.

[ucheol2]

any progress?

[SinaKarimi7]

Any news on this?

I want to have caching for dependencies that e2e needs in the deployment_status related workflow. But the GITHUB_REF is not available.

[lavoiesl]

This action explicitly looks for the GITHUB_REF env var: https://github.com/actions/cache/blob/0c45773b623bea8c8e75f6c82b208c3cf94ea4f9/src/utils/actionUtils.ts#L27-L31

I suspect the best course of action would be to get github to set the GITHUB_REF var. I assume that a deployment must be deploying a ref? 🤔 It may not be a branch, but it would at least be a sha.

Alternatively, I wonder if the check above could use GITHUB_SHA instead.

[saiichihashimoto]

Could we use whatever hash actions/cache must be using? I can't imagine that works without a ref.

[lukepearson]

The deployment_status event does pass through both ref and sha, but they are in the deployment object in the event, while the cache only looks at the top level for ref.

{
    "action": "created",
    "check_run": null,
    "deployment": {
      ...
      "environment": "Preview",
      "ref": "a45bc4d0c93424ef3e166a4aea8e0b5530938306",
      "sha": "a45bc4d0c93424ef3e166a4aea8e0b5530938306",
  }
}

If the could use github.event.deployment.ref for deployment and deployment_status events instead of the top level ref, it should work? I'm not sure if there are any security restrictions preventing the use of the deployment ref instead of the top level ref though.