This Week in Beagle #12

By

Hello everyone. A typical week for development. Let’s go over everything.

GitLab CI Components

I have been using GitLab Package Registry for most of my projects. It allows a permanent registry to store packages and create releases, in a persistent fashion. Initially, I started with manually uploading the packages in the CI. However, this turned out to be difficult to maintain in bb-imager-rs, which has a lot of release packages.

Since I wanted the solution to be shareable across different repositories, I started looking around for solutions. I stumbled across GitLab CI Components. I would have preferred using GitLab CI Steps, but since it is still experimental, I went with CI components.

Initially, I wanted to write the actual functionality in Python but quickly realized that it is not possible to depend on external files in CI components. You can download any external script in the CI from a URL, or you can create a custom container that already includes the script, but I decided to just go with writing everything in bash.

The CI Components are being used in bb-imager-rs and MicroBlocks and working pretty well. It should be fairly simple for other projects to start using them as well.

Let us now go over different CI Components present in the repository.

Package Registry Upload

Upload all files in the directory following proper conventions to GitLab Package Registry.

The release directory packages should follow the following format: {RELEASE_DIR}/{PACKGE_NAME}/{PACKAGE_VERSION}/{PACKAGE_FILE}. Here is an example of a release directory:

release/testpkg/0.0.1/abc.txt
release/testpkg/0.0.1-alpha/abc.txt
release/testpkg/0.0.1-alpha/abc.txt.bb.imager.json

Note: Any packages in a directory other than depth 3 will just be ignored.

The CI component also does some extra stuff:

  1. Generate and upload sha256 checksum for all files.
  2. Generate release.yml file which can be used by release-from-file to create a release.

Here is an example of using the CI component:

include:
  - component: openbeagle.org/ayush1325/ci-components/package-registry-upload@$<VERSION>
    inputs:
      job-name: package-registry-upload-job
      job-stage: deploy
      job-needs: ["test-build"]
      release_dir: ${CI_PROJECT_DIR}/release
      release_template: ${CI_PROJECT_DIR}/release.yml
Input Default Value Description
job-name package-registry-upload-job Name of the upload job
job-stage deploy Job stage
job-needs [] Job dependencies
release_dir release The directory containing packages to push to package registry
release_template Template with basic release information

Release from file

Create a release using release-cli from the yaml file. It is possible to either use the file generated by package-registry-upload or just supply one manually.

The format of the file is not all that well defined, but I used the following testfile in the repository as reference.

The component optionally also supports generating Changelog entries which is controlled by changelog_generation boolean variable.

Here is an example of using the CI component:

include:
  - component: openbeagle.org/ayush1325/ci-components/release-from-file@$<VERSION>
    inputs:
      job-name: package-registry-upload-job
      job-stage: deploy
      job-needs: ["test-build"]
      release_file: ${CI_PROJECT_DIR}/release.yml
Input Default Value Description
job-name release-from-file-job Name of the job
job-stage deploy Job stage
job-needs [] Job dependencies
release_file File to use to generate release
changelog_generation false Enable changelog generation

Os List

Create OS Lists subitems for use with bb-imager config. This should prove useful for the subitems list of testing packages, which would need to be updated much more than stable images.

Note: Entries are only created for packages having associated {package}.bb.imager.json files with the following fields:

  • name
  • description
  • icon
  • devices
  • tags

Here is an example of using the CI component:

- component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/os-list@$CI_COMMIT_SHA
  inputs:
    job-name: os-list-template
    job-needs: ["build-release-dir"]
    job-stage: deploy
    release_dir: release
    os_list_template: release/os_list_template.json
    os_list_suffix: "os_list/stable/os_list_template.json"
Input Default Value Description
job-name package-registry-upload-job Name of the upload job
job-stage deploy Job stage
job-needs [] Job dependencies
release_dir release The directory containing packages to push to package registry
os_list_template Template with entries that will be appended to final os_list
os_list_url_suffix Suffix used to generate Package Registry URL for OS List

BeagleBoard Rust Imager

More work went into the BeagleBoard Rust imager this week. I hope to get the v1.0.0 release out by the end of this month and replace the old bb-imager.

Remote Subitems

Similar to Raspberry Pi Imager, BeagleBoard Rust Imager now supports having subitems JSON list in a remote location. Os List Component can be used to generate the subitems JSON list in CI.

Release v0.0.3

To test the new CI components (and since a new release has been long overdue), BeagleBoard Rust Imager v0.0.3 was released.

Ending Thoughts

This was it for this week. Hopefully, this helps bring transparency regarding where the development efforts are concentrated, and how the community can help. Look forward to next update.

Helpful links