Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Compile with 4 threads on Jenkins builds, the build slaves were upgraded
- Loading branch information
e77a4abThere 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.
Can we do the same here?
cuberite/Jenkinsfile
Line 24 in 3e8c945
e77a4abThere 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.
cuberite/travisbuild.sh
Line 38 in 3e8c945
cuberite/travisbuild.sh
Line 46 in 3e8c945
e77a4abThere 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.
The machine doing the Jenkins testing is only rented with 3 cores. So that makes sense.
We ditched any travis stuff. This should be gone.
I actually don't know which sever is doing the release builds. I can't tell you anything about that
e77a4abThere 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.
Yes, it would be a good idea to make this consistent.
I'm not sure if this would have a positive effect or not, because both the GCC and clang builds run at the same time on the same build slave, adding up to 4 threads at once. This would probably be better tested empirically.
re 4 threads on a 3 core machine - it shouldn't have much of any negative performance impact to use more cores than the machine has available, as long as there's enough memory that we don't get exhaustion.
re the existence of travisbuild.sh - it's not quite right that we can just delete it now: the builds were moved on to the cuberite buildserver, but they still run travisbuild.sh - I will rename to something more appropriate.
re build slaves: as a security measure, builds have been disabed on the build master, so all builds are performed on the slaves. At present, that means that builds are performed on @12xx12's build slave, with additional slaves being provisioned from OVH cloud to handle spikes in demand (i.e. when there's a commit to master or multiple PRs to build at once)