Replies: 1 comment
-
OK figured out I was being dumb, but only because of the output from enabling Nx's extra logging. So it turns out our projects package.json version property gets dynamically set via a setup step in our pipeline script which of course means it gets a different computed hash from the previous build. Removing that step now gives me the behaviour I expected to see with Nx retrieving cached build results. Lesson Learnt! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We have Nx cloud setup for our organisation and I have successfully retrieved cached build results when trying out commands locally.
I am now experimenting with the
nx affected
command and am using it for building pull requests as part of our Jenkins pipeline script like so:npx nx affected --base=origin/master --head=HEAD --target=build --parallel
I made a single file change to a lib and see its affected one of my projects as per the build output in first run
But when I re-run the same job without making any further changes, I see the same output above but with a new NX Cloud run results URL.
I would expect to see the previous build results retrieved from our Nx cloud cache.
I enabled logging and can see there's clearly a cache miss when I rebuild the PR job
and later after it completes the build task I see output showing
> NX NOTE Nx Cloud: Storing ff22a76441f5051d4f9ee1c637987b8b1285f11b863d16704dff84a4bb74c614
On each rebuild I try, with logging enabled I can see the computed hash changes, but no further changes are made to any files in between rebuilds, so I guess that answers why I am seeing cache misses.
Am I misunderstanding how this is meant to work?
Beta Was this translation helpful? Give feedback.
All reactions