Include Git branch in CircleCI cache keys and bump key version

[benjamn]

This should resolve an issue affecting the 2.7.5 release, where an old federation-2/target/ cache was restored from an unrelated PR branch build (because Cargo.lock was the same), causing the compiled supergraph binary to call op_composition_result with a string rather than an object in some cases, triggering a panic on the Rust side.

I would have liked to disable this caching completely when publishing an official release, to prioritize correctness over build speed, but it doesn't seem like conditional caching is supported by CircleCI: https://circleci.com/docs/caching/#clearing-cache

We could potentially run cargo clean conditionally for release builds, after restore_cache (thereby throwing away the cache), but that doesn't seem ideal. Open to ideas!

[benjamn]

On @dariuszkuc's suggestion, I was able to SSH into a CircleCI runner and reproduce the error with slightly more information:

$ RUST_BACKTRACE=1 ../target/aarch64-apple-darwin/release/supergraph compose repro.yaml 
thread 'main' panicked at harmonizer/src/lib.rs:117:10:
unable to invoke composition in JavaScript runtime: TypeError: Error parsing args at position 0: serde_v8 error: invalid type; expected: object, got: string
    at done (<init>:12:43)
    at do_compose:8:5

This is why I think done (which calls Deno.core.ops["op_composition_result"]) must have been called with a string, though I still don't have a complete theory of how that could happen.

[dariuszkuc]

could we just wrap this in condition to save cache from main branch?

     - when:
          condition:
            matches: // or equal
              pattern: "/main/"
              value: << get target branch >> 
          steps:
            - save_cache:
                key: *target-cache-key
                paths:
                  - target/

[dariuszkuc]

*not a circle ci expert so unsure if it is even possible but I think we might be able to get some condition to match the main branch OR something like tag value

[benjamn]

Yeah, I'm no expert either, so I decided to keep it simple and disable caching instead of having to wait for the next release to find out if we did it correctly.

[abernix]

I fully support the change, though I feel like caching is such an under-needed ... need ... on this repository that we could and should just remove it completely. This repository's velocity is only meant to trend down, and is mostly just a fresh branch + release workflow anyhow. The taxes of compiling v8 twice vs once are high, but the rewards of the safest releases are higher.

[abernix]

Btw, it's relatively important that you DO bump to v3 here (as you did) because without it, CircleCI does this "tiered disposal" of arguments on the cache key until it gets a hit, which means without the bump, you might still get a previous cache segment based on just platform.

[benjamn]

@abernix @dariuszkuc After sleeping on it, I've come around to disabling the caching completely, to prioritize correctness.