Skip to content

Release Process

Jump to bottom
Erik Jaegervall edited this page Feb 7, 2024 · 1 revision

Note! Description partially outdated due to migration

This page describes the release process for artifacts in this repository. The term release here refers to

  • Testing content and when passed tag the repository
  • Release docker containers for all artifacts

All docker artifacts are listed at: https://github.com/orgs/eclipse/packages?repo_name=kuksa.val.feeders

Release Preparations

  • Make sure that wanted versions of KUKSA.val components have been released (Databroker, kuksa-client pypi package and so on). See KUKSA.val release process

A suggested approach when it is time to release a kuksa.val.feeder component is to:

  • Make sure that a stable new kuksa-clientexists in pypi.
  • Adapt all requirements.in, requirements.txt (search for requirements* files) so they use the official version, for example kuksa-client ~= 0.4.0 to assure that only 0.4 version can be used. Alternativetely we can keep > 0.3 if we like to allow also even newer kuksa-clients, like 0.5, but then we should anyway regenerate requirements.txt (with pip-compile -U requirements.in instead of pip-compile --pre requirements.in) to include an official version.
  • Review all .in/.txt-files; check if there is a need to do any update in dependencies. In the future check for known vulnerabilities
  • Remove all --pre statements from e.g. Dockerfileand *.yml (search for --pre in all files) to make sure that not we by mistake get pre-releases.

Preferred kuksa-client dependency criteria is:

  • >=X.YaN during development if we cannot use last released version, remeber to add --pre where needed
  • ~=X.Y for releases and master/main, to make sure we use a compatible version. Upgrading shall always be a deliberate action

This means - for a release we first change to a fix version, test, tag and release. Then we may change to a >=dependency.

File What to do
*.txt, *.in Search for kuksa-client and update version
*.in Regenerate *.txt with pip-compile --pre requirements.in or pip-compile requirements.in
Dockerfile Search for pip install and pip3 install and add/remove --pre as needed for installation of requirements.txt 
find . -name "*.txt" -exec egrep -ni kuksa {} /dev/null \;
find . -name "*.in" -exec egrep -ni kuksa {} /dev/null \;
find . -name "Dockerfile" -exec egrep -ni pip {} /dev/null \;

Test

See CSV Provider Release testing

Tag repo

erik@debian3:~/kuksa.val.feeders$ git checkout erik_main
Switched to branch 'erik_main'
Your branch is behind 'upstream/main' by 4 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)
erik@debian3:~/kuksa.val.feeders$ git rebase upstream/main
Successfully rebased and updated refs/heads/erik_main.
erik@debian3:~/kuksa.val.feeders$ git tag 0.4.0
erik@debian3:~/kuksa.val.feeders$ git push upstream 0.4.0
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/eclipse/kuksa.val.feeders
 * [new tag]         0.4.0 -> 0.4.0

Create Docker releases

Trigger manually for all packages we have at https://github.com/orgs/eclipse/packages?repo_name=kuksa.val.feeders by selecting the corresponding action in https://github.com/eclipse/kuksa.val.feeders/actions and trigger for the used tag.

currently: image

Note: For SOMEIP no reason to build binaries, does not affect docker build!

Create Github release

For now we keep it simple and try to reuse kuksa.val format

  • Use the form KUKSA.val.feeders 0.4.0 Release
  • Tick the "Set as a pre-release" box
  • Select Previous release tag and generate release note
  • Add a "What is new" section, make a summary based on git history
Clone this wiki locally