Revision inconsistent during workflow

Currently, we save and restore node_modules based on the {{ .Revision }} pipeline variable (see react/config.yml at 0652bdbd10f6192e10f6cab9602f6bbfe5fd2c8e · facebook/react · GitHub).

However, during a workflow for a single commit, the value of {{ .Revision }} changes. On almost all jobs have 6_85-96bfb2c7ac8832896c2ad0bab4d27c96d7c9735e has the .Revision. However, has 6_106-96bfb2c7ac8832896c2ad0bab4d27c96d7c9735e as the .Revision.

Is there another value that we could use to compute the cache key based on the git commit.

Hi @eps1lon,

I see the dynamic part of your cache key is actually referencing two templates: -{{ arch }}-{{ .Revision }}.

The {{ .Revision }} part appears consistent across jobs: 96bfb2c7ac8832896c2ad0bab4d27c96d7c9735e.

Rather, it’s the {{ arch }} part that appears to switch between arch1-linux-amd64-6_85 and arch1-linux-amd64-6_106.

I’m bringing this behaviour to the attention of our engineering teams, and I’ll get back to you.

1 Like


I have an explanation for the discrepancy you’ve observed.

As mentioned in our documentation, the {{ arch }} template captures:

  • architecture
  • family
  • model

The underlying machines on which Docker jobs run are usually EC2 instances with chipsets “Family 6, Model 85”. In some cases, where there isn’t sufficient capacity of these instances, Docker jobs might instead run on EC2 instances with chipsets “Family 6, Model 106”.

Our approach is that we prefer to run on instances with a slightly different CPU than to delay the job, or potentially not run it at all.

We’re currently assessing whether or not we can/should simplify the {{ arch }} template’s granularity to prevent occurrences of the behaviour you’ve observed across your Docker jobs.

For now, I suggest relying on other templates when using the cache feature in Docker jobs.

Let me know if you have further questions.


Thank you very much for the explanation, I needed it since I had no idea what this was due to

1 Like