-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci: merge staging to master #21
Conversation
…rformance and disabled CPU boost
Pipeline Attempt on 593247826 for 349927b https://gitlab.com/MatrixAI/open-source/js-logger/-/pipelines/593247826 |
👇 Click on the image for a new way to code review
Legend |
This failed on windows because tag pipeline which uses its own cache was attempting to install from chocolatey. However chocolatey is currently offline: https://community.chocolatey.org/packages/nodejs. I realised that the cache is not shared between pipelines here. Each tag has its own Ideally the tag pipelines should cache and share their cache between tag pipelines as well. It sort of depends, since a tag doesn't correspond to any branch, but conventionally we create tags off the staging branch. |
This also means every new branch like feature branches have their own cache as well which is not as bad because it only runs the check stage. But still it would be good to share "feature" branch caching for feature branches. |
At the same time different runners have different caches. I believe windows and macos have their own caching that is separate. Ok one solution to this is to use a fallback key. The fallback key is used whenever a cache for the main key is not found. So for a new tag, no cache will be found always at the beginning. It can then fallback on a key designed to cache "globally", for the tag pipelines, and also for new feature branches. Actually I'm not sure if the fallback key would work here. If we fallback to a key, does it also push cache to the fallback key or to the main key? It would make sense to push to the main key even if the fallback key was used. That way branches can then use their own cache separately from the fallback key. But that would mean no job would ever push to the fallback key. |
|
…` for `nix-shell --run`
Pipeline Succeeded on 593247826 for 349927b https://gitlab.com/MatrixAI/open-source/js-logger/-/pipelines/593247826 |
Pipeline Attempt on 593417996 for 9ec21de https://gitlab.com/MatrixAI/open-source/js-logger/-/pipelines/593417996 |
Pipeline Succeeded on 593417996 for 9ec21de https://gitlab.com/MatrixAI/open-source/js-logger/-/pipelines/593417996 |
This is an automatic PR generated by the pipeline CI/CD. This will be automatically fast-forward merged if successful.