ROS project packaging in Debian format ready for installation.
See also Wiki Docs
- Build from ros:melodic base Docker image for high integrity slow builds
- Build from amros-melodic base Docker image for fast builds with pretty good integrity
- Generates a debian package available for subsequent actions to access (presumably install or deploy)
- Generates changelog based on the version provided
- Version can be provided directly
- Version can be generated automatically using timestamp
- Version can be built from a combination of pull-request-number, build-number, branch
- Can download dependencies from the AM private package repository
name: Package Example
on: push
jobs:
package:
runs-on: [x64, self-hosted,linux,build]
name: Example of creating a debian package
steps:
- uses: actions/checkout@v2
- name: Package
id: package
uses: AutoModality/action-package-debian-ros@v3
with:
version: 1.3.0
release-repo-entitlement: ${{ secrets.CLOUDSMITH_READ_RELEASE_ENTITLEMENT }}
- name: The generated package
run: echo "The artifact is ${{ steps.package.outputs.artifact-path }}"
- name: The version
run: echo "The artifact version is ${{ steps.package.outputs.version }}"
See action.yml for more options.
Uses Semantic Release to publish releases.
Although a bit confusing, this repository comes in two flavors:
- ROS - slow with high integrity
- AMROS - fast with medium integrity
The AMROS build is packaged with all the necessary packages saving time installing dependencies. Otherwise, they are fairly similar since AMROS docker is based on ros:melodic.
The Dockerfile points to either docker/ros/Dockerfile or docker/amros/Dockerfile providing the flavor.
ls -l Dockerfile
shows the linked file
lrwxrwxrwx 1 amros amros 23 Sep 28 17:38 Dockerfile -> docker/amros/Dockerfile
If improvements must be made to the other flavor than is currently set, you can simply link it to the other file:
ln -sf docker/amros/Dockerfile Dockerfile
or
ln -sf docker/ros/Dockerfile Dockerfile
When you make the commit, you should increment a minor release. Although it breaks the convention since it should be a breaking change, it will help group related versions of amros and ros docker bases.
feat: switching base to AMROS
The tags should identify which base is being used:
v5-amros
Such a tag moves to the latest stable release so we do not need to update to the latest.
git tag -f v5-amros
git push -f origin v5-amros
The docker image is available for quick download from Cloudsmith. It is deployed with new releases and may be used per the Development instructions below.
Tests are run by the Actions and demonstrate the features provided.
Build locally like github actions so you can debug build errors in the most accurate way.
Use the amros cli to run locally builds like github:
amros dev build docker run
At the prompt:
/release-build.sh
The build should look very similar to the output from Github Actions.
Building with only releases
No access to Cloudsmith Dev Repository. Entitlement not provided.
Hit:1 http://packages.ros.org/ros/ubuntu bionic InRelease
Get:2 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Hit:3 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:4 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Most should use the AMROS CLI described previously. The insructions are here for manual applications.
You will need to build packages in your local development environment.
Build the Docker Image so you can run a container locally.
docker build -t amros-build-melodic .
Provide access to package repository by exporting Cloudsmith entitlements to environment variables.
or using the cloudsmith cli
cloudsmith entitlements list automodality/dev --show-tokens
cloudsmith entitlements list automodality/release --show-tokens
Export the variables into your session or add them to your .bash_profile.
export CLOUDSMITH_READ_DEV_ENTITLEMENT={your entitlement}
export CLOUDSMITH_READ_RELEASE_ENTITLEMENT={your entitlement}
Change to the root of your project
Each github repo builds individually so change to the root of the project.
For example:
cd ~/am/github/visbox
Run the build like Github
docker run -v `pwd`/:/github/workspace -w /github/workspace \
--env CLOUDSMITH_READ_DEV_ENTITLEMENT \
--env CLOUDSMITH_READ_RELEASE_ENTITLEMENT \
-t amros-build-melodic
Run the build interactively
docker run --entrypoint=/bin/bash -v `pwd`/:/github/workspace -w /github/workspace \
--env CLOUDSMITH_READ_DEV_ENTITLEMENT \
--env CLOUDSMITH_READ_RELEASE_ENTITLEMENT \
-it amros-build-melodic
Run the Build Script in the container.
/entrypoint.sh None None None None $CLOUDSMITH_READ_DEV_ENTITLEMENT $CLOUDSMITH_READ_RELEASE_ENTITLEMENT
The package is available at /github.
Or run the debian build manually:
cd /github/workspace
debian/rules binary
Or run catkin_make:
Recommended: Run Build Script first to download dependencies.
ln -s /github/workspace ~/catkin_ws/src
cd ~/catkin_ws
catkin_make
From action.yml.
version:
description: 'The version of the package to be generated. Other inputs ignored if provided.'
required: false
default: 'None'
branch:
description: 'Optional: The branch name used in the minor version. Paths will be escaped.'
required: false
default: 'None'
build-number:
description: 'Optional: Corresponds to the build number that invoked this. Patch version. '
required: false
default: 'None'
pull-request-number:
description: 'Optional: Corresponds to the pull request that invoked this. Major version.'
required: false
default: 'None'
dev-repo-entitlement:
description: 'Optional. If provided, will have access to the Cloudsmith dev repository for dependency download.'
required: false
default: 'None'
release-repo-entitlement:
description: 'Optional. If provided, will have access to the Cloudsmith release repository for dependency download.'
required: false
default: 'None'
outputs:
artifact-path:
description: 'The file path where the artifact can be found'
version:
description: 'The version of the artifact.'