Conversation
| @@ -0,0 +1 @@ | |||
| yarn-offline-mirror "../kibana-extra/kibana-offline-mirror" | |||
There was a problem hiding this comment.
probably should replace this with a ci only config
There was a problem hiding this comment.
We could use yarn config set yarn-offline-mirror during the CI setup
| } | ||
|
|
||
| checkout_sibling "elasticsearch" "${PARENT_DIR}/elasticsearch" "USE_EXISTING_ES" | ||
| checkout_sibling "kibana-offline-mirror" "${KIBANA_EXTRA_DIR}/kibana-offline-mirror" "USE_EXISTING_KIBANA_OFFLINE_MIRROR" |
There was a problem hiding this comment.
Curious, why put it in the kibana-extras directory and not a Kibana sibling, like the elasticsearch checkout?
There was a problem hiding this comment.
no reason other than our previous convention. given the kibana prefix i think it makes sense to move it up one
💚 Build Succeeded |
| const offline = options.offline === true; | ||
| const extraArgs = [ | ||
| frozenLockfile ? '--frozen-lockfile' : '', | ||
| offline ? '--offline' : '', |
There was a problem hiding this comment.
Does --offline require that we update the cache repo with new dependencies before they will pass CI? Should we perhaps use --prefer-offline?
There was a problem hiding this comment.
it does, good call. do we use prefer-offline here, and keep it at offline for builds? the idea being that we do want to fail somewhere if we're not cached?
the more it i think about it -offline sounds like maintenance nightmare. what if we based it on the release flag?
--release ? '--offline' : '--prefer-offline'
|
More ideas:
|
4 participants
This uses the yarn-offline-mirror feature to cache our dependencies. Roughly, the setup involves a separate repo that has archives for all of our dependencies. That repo is cloned, and yarn installs using the packages in that folder.
There's several options for caching, including our own mirror, but I think this gives us the most flexibility. When we branch kibana to target a release we can update and branch the cache. We'll have a clear archive of dependencies needed to run a build for that branch. We can add tags if necessary for patch releases.
A cache server would need regular, long term backups to be consistent in addition to protecting the availability and integrity of the packages. I'd push for avoiding that complexity if we can.
Closes #15874