Review on latest CI changes and how to move on

[david-luna]

• This only affects the JavaScript OpenTelemetry library
• This may affect other libraries, but I would like to get opinions here first

This is a follow up issue of the short analysis shared in the JS SIG. Recap:

• we got similar compilation times since most of the times we have to compile and test auto-instrumentations-node
  • this package depends on all node instrumentations so it needs to compile all of them
• we got faster builds when only code is changed
  • CI runs the unit and TAV test only for the affected package and auto-instrumentations
• when updating dependencies we usually got slower times
  • because package-lock.json is modified it runs unit and TAV for all

Diff with prev CI

• new CI uploads a report per package tested (more time)
• prev CI was doing TAV based on pkg:instrumentation-* labels so it was testing. That's where the mos time is saved.

Possible improvements

• create a build cache of last commit in main. Will help to reduce compilation time.
• go back to TAV testing based on labels
  • [@pichlermarc] and trigger TAV for all if a certain label is set

I've created this issue so anyone can discuss about the items on the list an add any idea that may help to speed up the review process.

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[david-luna]

some discussion about compile time #3162 (comment)

Options:

• compile cache in main to keep compiling affected packages
• remove auto-instrumentations-node and auto-instrumentations-web from the affected list

[pichlermarc]

• compile cache in main to keep compiling affected packages

I think this is the option that I'd prefer. Given that auto-instrumentaions-* public API can change with instrumentation package changes, this seems like the safest option to me. 🙂