Skip to content
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

[ci] Consider consistent Drake version pinning and/or canary builds #245

Open
EricCousineau-TRI opened this issue Mar 6, 2023 · 1 comment

Comments

@EricCousineau-TRI
Copy link
Collaborator

At present, CMake can use latest nightly binaries, whereas Bazel is currently pinned.

Possible options for consistency:

  • Use pinning for both CMake and Bazel. Make an explicit optional "canary" set of builds so that we can preview breakages as they come in.
    • This is similar to what we do in Anzu - explicit updates to Drake, but with canary integration CI to test Anzu master against Drake master.
    • Ideally, this setup should be applied to rolling builds too.
  • Make both CMake and Bazel "bleeding edge" and require fixes, a la `drake-external-examples.

See @sloretz's additional notes here:
#242 (review)

@jwnimmer-tri
Copy link
Contributor

My 2c:

As much as possible, for GitHub actions use a pre-compiled Drake. I guess the actions don't have a lot of cores, so it takes a long time to get everything built. Plausibly, it would be best to pin to latest stable (tagged) Drake for this case. Steady-state, I don't think that drake-ros should depend on bleeding-edge Drake (unless a user opts-in to that).

For a canary build / integration test, I can offer our https://drake-jenkins.csail.mit.edu/ service so that we're using Drake-funded machines that are fast enough to rebuild the whole world from scratch. It could do a nightly build to cross-check that the most recent drake and drake-ros sources play well together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants