-
-
Notifications
You must be signed in to change notification settings - Fork 17
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
Make 1.20 fast #103
Make 1.20 fast #103
Conversation
Pull Request Test Coverage Report for Build 4500226192
💛 - Coveralls |
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.
Relevant changes are in this file
❤️ 🧡 💛 💚 💙 💜 🖤 |
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.
It works well on my machine. Let's keep an eye out once we merge this
3fc98a9
to
4c858f3
Compare
It seems this is an issue with the build cache (see discussion in golang/go#59146). For that reason, I included a command to populate the build cache with the std lib and other packages related with go commands. This makes the initial build of the container a bit slower, but ensures the build cache is populated, meaning we should see more consistent builds. I plan on merging tomorrow when I have more time to monitor the test runs. |
We use the same approach in several other test runners. |
I tested use one of my Go solutions and that looked fine performance wise |
Same here. Tested in a variety of exercises and looks great. Maybe even faster than before? |
🚀 |
Follow up of: https://forum.exercism.org/t/tests-failing-with-an-error-occurred/4616/11
After trying several things (which I included in the forum thread), removing the special user and the
GOCACHE
env var fixed the problem. Both these changes seem to be necessary, also tried one without the other, and the problem persists.I'm still not sure why this fixes it. My best guess is these two bits of the 1.20 Release Notes:
My guess here is that running the test runner as a special user inside the container makes Go call the
os/user
package. SettingCGO_ENABLED=1
to explicitly enable cgo also seems to do nothing in this regard.We do compile the user solution in module mode, which uses the build cache set by
GOCACHE
, but it seems using/tmp
causes slowness, and letting the default Go uses is best.