[Fleet] Use staging registry for SNAPSHOT builds

[ruflin]

Today in Fleet for builds off the master branch, the snapshot registry is used, for all other environments the production registry:

kibana/x-pack/plugins/fleet/server/services/epm/registry/registry_url.ts

Line 20 in d8f7997

const getDefaultRegistryUrl = (): string => {

This makes it hard to test against staging in Cloud as the registry URL cannot be modified.

The proposal here is to use the staging registry for all -SNAPSHOT builds. The logic would then be something like:

if (branch === 'master') {
  return SNAPSHOT_REGISTRY_URL_CDN;
} else if (string_contains(version, '-SNAPSHOT)){
  return STAGING_REGISTRY_URL_CDN;
{ else }
  return PRODUCTION_REGISTRY_URL_CDN;
}

This would allow to test the staging branch with elastic-package and on Cloud by selecting a -SNAPSHOT build. For example to test staging for 7.11.0, the container 7.11.0-SNAPSHOT would be used, to test against production, 7.11.0.

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[elasticmachine]

Pinging @elastic/fleet (Feature:Fleet)

[ruflin]

@EricDavisX Would be great to get your feedback on the above if this would be helpful.

[EricDavisX]

This is excellent, and I had the same idea myself last night! I see no real risk here, as the logic is still quite simple. This fits in well with what our desired process is and allows better (#CloudFirst) testing across the needed releases, excellent indeed!

[ph]

@ruflin This looks like a good idea to reduce some of the concerns with what version is out or not. I am not sure there is a way to detect if you are in master other than for checking for 8.0.0 but @jen-huang might know more :)

[ruflin]

The build contains the branch and this check already exists today. So only change needed is for staging.

[skh]

What @ruflin says, we have kibanaVersion and kibanaBranch in our app context. kibanaVersion may contain -SNAPSHOT, see for example here: https://github.com/elastic/kibana/blob/master/x-pack/plugins/fleet/server/services/epm/registry/index.ts#L68

So the information is there, and can be used when deciding which registry to use.

[ruflin]

Based on the reference from @skh seems like all the info is available also in Fleet in existing variables 🎉

@skh Do you know if I build Kibana from source if there is a way to specify if it should be SNAPSHOT or not? I'm wondering how to test an implementation before it is backported 🤔

[EricDavisX]

Does Kibana CI build the Kibana Docker container that we could reference / use?

[skh]

@ruflin node scripts/build --release should build without -SNAPSHOT but I haven't tried.

[EricDavisX]

As I see the risk, the test goal is to build Kibana with -SNAPSHOT in the version. So from SKH's note, if we remove --release then that would solve it I guess. Excellent!

[jen-huang]

@skh Handing ownership of this to you as @ruflin is PTO this week :) I left an approval on #90327 so feel free to merge and backport that when you're ready.

[EricDavisX]

@skh can you backport to 7.11.1+ as well? This will help testing during the next cycle of Integrations (which need to work on 7.11.x). the setup work (time) and complexity is proving a real blocker for us to test them, even though it seems like we have it sorted out now. the backport would save us significant time and give much confidence in the test effort.

[skh]

@EricDavisX backport to 7.11 is here: #91088

[skh]

@EricDavisX It looks like 7.11.1 is already final, so this backport will probably land in 7.11.2.

[EricDavisX]

they incremented the Kibana commit in 7.11.1 so, I guess it got picked up. it is all good