-
Notifications
You must be signed in to change notification settings - Fork 82
ci: run Git's entire test suite #83
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
Conversation
ad01166 to
725b84b
Compare
One particularly important part of Git for Windows' MSYS2 runtime is that it is used to run Git's tests, and regressions happened there: For example, the first iteration of MSYS2 runtime v3.5.5 caused plenty of hangs. This was realized unfortunately only after deploying the msys2-runtime Pacman package, and some painful vacation-time scrambling was required to revert to v3.5.4.This was realized unfortunately only after deploying the msys2-runtime Pacman package, and some painful vacation-time scrambling was required to revert to v3.5.4. To verify that this does not happen anymore, let's reuse what `setup-git-for-windows-sdk` uses in Git's very own CI: - determine the latest successful `ci-artifacts` workflow run in git-for-windows/git-sdk-64 - download its Git files and build artifacts - download its minimal-sdk - overwrite the MSYS2 runtime in the minimal-sdk - run the test suite and the assorted validations just like the `ci-artifacts` workflow (from which these jobs are copied) This obviously adds a hefty time penalty (around 7 minutes!) to every MSYS2 runtime PR in the git-for-windows org. Happily, these days we don't need many of those, and the balance between things like the v3.5.5 scramble and waiting a little longer for the CI to finish is clearly in favor of the latter. Signed-off-by: Johannes Schindelin <[email protected]>
3d65449 to
929a93e
Compare
ci: run Git's entire test suite
ci: run Git's entire test suite
ci: run Git's entire test suite
ci: run Git's entire test suite
ci: run Git's entire test suite
ci: run Git's entire test suite
ci: run Git's entire test suite
ci: run Git's entire test suite
|
The 'upstream' of these tests is git-for-windows/git? I ask because I think this could be a candidate for a callable/reusable workflow to avoid duplicating these jobs. I want to try that and possibly open some PRs to make it so if it works out. |
Define "upstream" ;-) This workflow downloads artifacts that are built by
I did try with Git for Windows' GitHub workflows to put logic into reusable workflows (or more like, composite Actions, because I find them easier to use and maintain), but I gave up. GitHub Actions' design is kind of recapitulating parts of the history of programming, where e.g. the value of inheritance and sub-classing was discovered and re-discovered, but since investment in GitHub Actions has all but stopped, it never got quite where I need it to be. Sure, I can emulate some reusable component design by moving logic into composite Actions with a gazillion inputs and then use
Sure, I won't stop you, and I will be delighted to see your beautiful solution! |
ci: run Git's entire test suite
ci: run Git's entire test suite
ci: run Git's entire test suite
ci: run Git's entire test suite
ci: run Git's entire test suite

One particularly important part of Git for Windows' MSYS2 runtime is that it is used to run Git's tests, and regressions happened there: For example, the first iteration of MSYS2 runtime v3.5.5 caused plenty of hangs. This was realized unfortunately only after deploying the
msys2-runtimePacman package, and some painful vacation-time scrambling was required to revert to v3.5.4.To verify that this does not happen anymore, let's reuse what
setup-git-for-windows-sdkuses in Git's very own CI:ci-artifactsworkflow run in git-for-windows/git-sdk-64ci-artifactsworkflow (from which these jobs are copied)This obviously adds a hefty time penalty to every MSYS2 runtime PR in the
git-for-windowsorg. Happily, these days we don't need many of those, and the balance between things like the v3.5.5 scramble and waiting a little longer for the CI to finish is clearly in favor of the latter.