-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Use Artifactory remote in nix workflow #4556
Conversation
@thejohnfreeman can you confirm that this is ready for review? I think the IP-based URL is fine for now; it can be updated to a human-readable DNS name, when available, in a separate future PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Worked quick!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work!
There is now an Artifactory (thanks @shichengripple001 and team!) to hold dependency binaries for the builds. * Rewrite the `nix` workflow to use it and cut the time down to a mere 21 minutes. * This workflow should continue to work (just more slowly) for forks that do not have access to the Artifactory.
There is now an Artifactory (thanks @shichengripple001 and team!) to hold dependency binaries for the builds. * Rewrite the `nix` workflow to use it and cut the time down to a mere 21 minutes. * This workflow should continue to work (just more slowly) for forks that do not have access to the Artifactory.
There is now an Artifactory (thanks @shichengripple001 and team!) to hold dependency binaries for the builds. * Rewrite the `nix` workflow to use it and cut the time down to a mere 21 minutes. * This workflow should continue to work (just more slowly) for forks that do not have access to the Artifactory.
There is now an Artifactory (thanks @shichengripple001 and team!) to hold dependency binaries for the builds. * Rewrite the `nix` workflow to use it and cut the time down to a mere 21 minutes. * This workflow should continue to work (just more slowly) for forks that do not have access to the Artifactory.
Artifactory support was added to the `nix` builds with #4556. This extends that support to the Windows build. Now the Windows build works; CI will build and test a Windows release build. This only affects CI and does not change any C++ code. * Copy the remote setup step outcome fix from #4716 discussion * Allow the Windows job to succeed if tests fail: * Currently the tests do not always pass, even on a single threaded run on the GitHub runners. So we are using parallel runs and mark the test step as allowed to fail (continue-on-error). * At this point, it's more important that the build succeeds than that the tests succeed, because: * We've got plenty of test coverage on the other jobs. * Test failures are much rarer than build failures because of cross-platform issues. * Having a test failure locally doesn't interrupt a workflow nearly as much as a build failure. Note that Conan Center cannot hold the binaries we need. They do not build the configurations we need, and they will not add them. ## Future Tasks This introduces a new bottleneck since the build and test takes over an hour. Speed up the job by: * Making this job run on heavy Windows runners. * Increasing the number of hardware threads.
Artifactory support was added to the `nix` builds with XRPLF#4556. This extends that support to the Windows build. Now the Windows build works; CI will build and test a Windows release build. This only affects CI and does not change any C++ code. * Copy the remote setup step outcome fix from XRPLF#4716 discussion * Allow the Windows job to succeed if tests fail: * Currently the tests do not always pass, even on a single threaded run on the GitHub runners. So we are using parallel runs and mark the test step as allowed to fail (continue-on-error). * At this point, it's more important that the build succeeds than that the tests succeed, because: * We've got plenty of test coverage on the other jobs. * Test failures are much rarer than build failures because of cross-platform issues. * Having a test failure locally doesn't interrupt a workflow nearly as much as a build failure. Note that Conan Center cannot hold the binaries we need. They do not build the configurations we need, and they will not add them. ## Future Tasks This introduces a new bottleneck since the build and test takes over an hour. Speed up the job by: * Making this job run on heavy Windows runners. * Increasing the number of hardware threads.
Ripple has created a semi-public Artifactory (thanks @shichengripple001 and team!) to hold dependency binaries for our builds. I was able to rewrite our
nix
workflow to use it and cut the time down to a mere 21 minutes. This workflow should continue to work (just more slowly) for forks that do not have access to the Artifactory.The new bottleneck is the
macos
workflow which took 31 minutes. There is no low-hanging fruit to reduce that time though. AWS sells only one size of macOS instance. The next best improvement we can make is to fix parallel testing on macOS