[EMB-589] Support automated development package builds and Cloudsmith commit tagging

.github/workflows/prepare_env.yml

@@ -92,6 +92,19 @@ jobs:
               echo "Success, this is a development release"
               RELEASE_REPO="packages-dev"
             fi
+          else
+            # For pushes to dev branches or PR review commits, check for a JIRA ticket prefix/pattern
+            DEV_BRANCH="${GITHUB_HEAD_REF:-${CURRENT_BRANCH}}"
+            echo "Checking development branch '${DEV_BRANCH}' for JIRA ticket..."
+
+            # Match JIRA project keys (e.g., EMB-589, SEM-1234, CES_1234, CURA-10111)
+            if [[ "${DEV_BRANCH}" =~ (^|/)([A-Za-z]{2,10})[-_]([0-9]+) ]]; then
+              JIRA_TICKET="${BASH_REMATCH[2]}-${BASH_REMATCH[3]}"
+              JIRA_NUMBER="${BASH_REMATCH[3]}"
+              echo "Found JIRA ticket '${JIRA_TICKET}' (number: ${JIRA_NUMBER})"
+              RELEASE_REPO="packages-dev"
+              RELEASE_VERSION="${JIRA_NUMBER}.$(date +%m%d.%H%M%S)-dev"
+            fi
           fi
 
           if [[ "${RELEASE_REPO}" == "none" ]]; then

.github/workflows/release_pkg.yml

@@ -36,13 +36,20 @@ jobs:
 
       - name: Upload Debian Packages
         shell: bash
+        env:
+          COMMIT_SHA: ${{ github.event.pull_request.head.sha || github.sha }}
         run: |
+          SHORT_SHA="${COMMIT_SHA:0:7}"
+          TAG_ARGS=""
+          if [[ -n "${SHORT_SHA}" ]]; then
+            TAG_ARGS="--tags ${SHORT_SHA}"
+          fi
           for package in *.deb; do
             echo " "
-            echo "########## Uploading ${package} ##########"
+            echo "########## Uploading ${package} (commit: ${SHORT_SHA}) ##########"
             echo " "
-            docker run -v "$(pwd):/build" cloudsmith-cli:latest cloudsmith push deb ultimaker/${{ env.RELEASE_REPO }}/debian/buster /build/${package} -k ${{ secrets.CLOUDSMITH_API_KEY }}
-            docker run -v "$(pwd):/build" cloudsmith-cli:latest cloudsmith push deb ultimaker/${{ env.RELEASE_REPO }}/debian/bookworm /build/${package} -k ${{ secrets.CLOUDSMITH_API_KEY }}
+            docker run -v "$(pwd):/build" cloudsmith-cli:latest cloudsmith push deb ultimaker/${{ env.RELEASE_REPO }}/debian/buster /build/${package} ${TAG_ARGS} -k ${{ secrets.CLOUDSMITH_API_KEY }}
+            docker run -v "$(pwd):/build" cloudsmith-cli:latest cloudsmith push deb ultimaker/${{ env.RELEASE_REPO }}/debian/bookworm /build/${package} ${TAG_ARGS} -k ${{ secrets.CLOUDSMITH_API_KEY }}
           done;
 
       - name: Dump GitHub context

README.md

@@ -5,14 +5,14 @@ Do not forget this is **PUBLIC** repository.
 Implemented Reusable Workflows:
 
 - **Prepare Environment** (prepare_env.yml): By parsing the github context, it sets the variables `RELEASE_VERSION` and `RELEASE_REPO` for the next workflows.
-The `RELEASE_VERSION` will be `999.999.999` for a regular commit to a non-master branch. For a merge to a master branch, it will get the nightly build format `<yyyy.mm.dd>-merge-<branch>`. For a tag in a branch, it will take the tag version (if properly formatted).
-The `RELEASE_REPO` will have the Cloudsmith target repository to upload the package: `night-builds` for a merge to a master branch, `packages-released` for a tag without the `-dev` in a master branch suffix and `packages-dev` for a tag with the `-dev` suffix in a non-master branch.
+The `RELEASE_VERSION` will be `999.999.999` for a regular commit to a non-master branch without a JIRA ticket. If the development branch matches a JIRA ticket prefix/pattern (e.g. `EMB-589-feature`), it will be formatted as `<ticket_number>.<mmdd>.<hhmmss>-dev`. For a merge to a master branch, it will get the nightly build format `<yyyy.mm.dd>-merge-<branch>`. For a tag in a branch, it will take the tag version (if properly formatted).
+The `RELEASE_REPO` will have the Cloudsmith target repository to upload the package: `night-builds` for a merge to a master branch, `packages-released` for a tag without the `-dev` in a master branch suffix, and `packages-dev` for a development branch with a JIRA ticket or a tag with the `-dev` suffix.
 If the `BUILD_DOCKER_CACHE` input boolean is set to `true`, it will also login in the `Github Container Registry` and call `build_for_ultimaker.sh -a build_docker_cache` in order to cache the docker image. This technique is currently used by (and can be copied from) `Opinicus` to cache the docker image.
 
 - **Shellcheck** (shellcheck.yml): Call `./build_for_ultimaker.sh -a shellcheck` for the repository.
 - **Build Package** (build.yml): Uses the `RELEASE_VERSION` from *Prepare Environment* to make a package by calling `./build_for_ultimaker.sh -a build`. The resulting package is uploaded as an artifact.
 - **Unit Test** (unit_test.uml): Might be used to run the unit tests for the repository if this can be encapsulated using `./build_for_ultimaker.sh -a unittest`.
-- **Release Package** (release_pkg.yml): Downloads the artifact generated in the *Build Package* workflow and uploads to Cloudsmith in the repository defined by `RELEASE_REPO`. It will only run if `RELEASE_REPO` is not `none`.
+- **Release Package** (release_pkg.yml): Downloads the artifact generated in the *Build Package* workflow and uploads to Cloudsmith in the repository defined by `RELEASE_REPO`. It will only run if `RELEASE_REPO` is not `none`. Packages are tagged in Cloudsmith with the short git commit hash.
 - **Release Docker Image** (release_docker_img.yml): Build and Release to Github Packages a docker image. You need to specify two inputs to this workflow: The docker image name (like `um-kernel` or `ultimoco`) and the tag prefix used to trigger the docker image build, e.g. `docker_img-`. In this case, if we tag the repository with `docker_img-v1`, the prefix will be stripped and the image will be released as version `v1`. **VERY IMPORTANT:** After upload, the image will be *INTERNAL* and NOT connected to any repository. You need to select the package in organizarion (Ultimaker->Packages->`package name`->Connect Repository) and make it *PUBLIC* (Ultimaker->Packages->`package name`->Package Settings->Change Visibility) because our workflows do not authenticate before downloading images - we dont store any private information in the docker images. It is also optional to *connect* the package to a repository. According to the current Github documentation, connecting a package to a public repository will not count its downloads from the organization bandwitdh, so it is a good idea doing so. The current procedure is to connect the package to this repo (`embedded-workflows`) and make it Public. 
 
 This repository also stores the Dockerfiles to build the images used by CI Linting Tools. These images are pushed to the Gitlab Packages repository (https://github.com/orgs/Ultimaker/packages?tab=packages)