-
Notifications
You must be signed in to change notification settings - Fork 32
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
Moveit2 build takes over 2.5 hours in GHA workflow #77
Comments
Here's a link for more details: |
We can change the build to only build Edit- I mean we can do that if we are pushing nightly builds to Dockerhub |
@EzraBrooks - what do you think of the idea of pushing the latest moveit2 build to docker and only re-building it if the /moveit2 files change? |
I think that makes sense as an immediate measure before we have time/energy to refactor our containers to take good advantage of Docker's layer caching so it handles that for us. |
This might get partially resolved during this next release but I'm not adding the milestone tag because we don't want to depend on it |
This is a common hack to avoid running out of memory while building a large C++ codebase. However, it's unnecessary in an era where users just need to be educated to configure `zram` on their system.
This is a common hack to avoid running out of memory while building a large C++ codebase. However, it's unnecessary in an era where users just need to be educated to configure `zram` on their system.
Don't limit parallel workers in moveit2 build (#77)
This is a performance issue. The Moveit2 build takes 2.5 hours in the GHA workflow, which makes it very painful to submit PR's and get them integrated in a timely fashion.
The simplest thing to fix this might be to push the image to dockerhub, so that if nothing in the Moveit2 build has changed, it will simply pull the latest image. However, we probably still want to work on getting the build down to an hour or less if possible.
The text was updated successfully, but these errors were encountered: