Skip to content

Instantly share code, notes, and snippets.

@SteveMacenski
Last active December 5, 2022 01:40
  • Star 8 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save SteveMacenski/1c321d1c9edca096ae4d763d8327c2ee to your computer and use it in GitHub Desktop.
*** Steve's ROS Bloom Guide ***
A Release your project using GitHub releases.
Name the release the version (e.g. `0.4.3`) off the branch (e.g. diamondback-devel).
This version must also match the `package.xml` version number.
- If this is the first time releasing, you need to make a release repository.
It should be of name `<project_name>-release` (e.g. https://github.com/ros-planning/navigation2-release.git).
- Run `bloom-release navigation2 --track diamondback --rosdistro diamondback --edit`
track and rosdistro should be the distribution.
First argument is the package name.
For later releases, you don't need the `--edit` flag.
If you want to add a new distribution to an existing package,
use `--new-track`(e.g. `bloom-release navigation2 --track electric --rosdistro electric --new-track`).
- Its going to look at the `distributions.yaml` file for your project key.
If it doesn't find it, it'll look in other distributions.
If it finds one, it'll prompt you to approve it.
If not, it'll ask you to input the release repository URL.
- Its going to ask for the repository name, this is the key that will go into rosdistro.
Make it the same as the first argument in the original step.
- Then it'll ask for the repo URL, input it.
- If on github, use git as the VCS type next.
- On version, use the default :{auto} so that it'll find the latest github release (e.g. `0.4.3`) with matching package.xml version `0.4.3`.
- On release tag, also use :{version}
- For the devel branch, select the distribution branch (e.g. `diamondback-devel`)
- Select the ros distribution (e.g. diamondback)
- Leave patches directory as None
- Leave repository push URL as None
- Its going to then try to find the release, check in the package.xml that all the keys are valid.
It will ask you some questions about whether to set up PR building, maintenance status and docs.
This is all optional and up to your discretion.
If you do enable PR builders, please give write access to the ROS PR builder account.
If OK, release to your release repository.
If everything is correct, it'll prompt you to submit a PR to rosdistro.
Once this PR is merged, it'll build on build.ros2.org so you can see the build statuses.
It'll create the bin jobs for the binaries for install via `apt`.
It'll also have the src job to build and test code.
Dev builds are the branch's of CI.
If you enabled PR testing, then the pr jobs are the PR builders against the branch selected.
- Once the bin job succeed, they go into shadow-fixed for edge testing.
Once a month-ish OSRF will do a sync and all new packages in shadow-fixed will go into `apt` for main-release.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment