You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, it's easy to push a commit that breaks something without one realizing it, especially when the breakage is on another platform. If more commits are laid on top, then once the issue is detected, it's harder to find out what change caused it.
Suggested solution
We should set up GitHub Actions for this monorepo, just like we do for the lokinit repo. This provides feedback across platforms mere minutes after push, and makes it possible to quickly detect what set of commits caused the problem, hugely speeding up debugging.
This being a monorepo, it means that we should take care not to build packages that are unaffected, to speed up build time. The best solution to this might just be to cache CI runs and let Cargo figure out what to rebuild.
Build minutes should not be a concern, as GitHub doesn't limit us in this regard as long as we aren't straight up abusing Actions. The limit for the cache is 10 GB, so we should also be somewhat safe there.
Alternatives
We could not do this, and live with the problem laid out above. This would probably not be a huge deal, but CI is nice to have.
Additional information
No response
Checks
I have checked for existing issues about this, and did not
find any.
The text was updated successfully, but these errors were encountered:
Area
Monorepo
Problem
At the moment, it's easy to push a commit that breaks something without one realizing it, especially when the breakage is on another platform. If more commits are laid on top, then once the issue is detected, it's harder to find out what change caused it.
Suggested solution
We should set up GitHub Actions for this monorepo, just like we do for the lokinit repo. This provides feedback across platforms mere minutes after push, and makes it possible to quickly detect what set of commits caused the problem, hugely speeding up debugging.
This being a monorepo, it means that we should take care not to build packages that are unaffected, to speed up build time. The best solution to this might just be to cache CI runs and let Cargo figure out what to rebuild.
Build minutes should not be a concern, as GitHub doesn't limit us in this regard as long as we aren't straight up abusing Actions. The limit for the cache is 10 GB, so we should also be somewhat safe there.
Alternatives
We could not do this, and live with the problem laid out above. This would probably not be a huge deal, but CI is nice to have.
Additional information
No response
Checks
find any.
The text was updated successfully, but these errors were encountered: