Migrate custom project test over to the new custom project environment workflows

Description

#2696 introduced new custom project workflows that we would like to adopt across all custom projects and to be able to remove the old pipeline. In https://github.com/openremote/custom-project-test/pull/21 I tried it out and resolved most of the issues for custom-review.yml (I think). Though we should also define what other requirements for processes like deploying and releasing there are in custom projects.

Acceptance criteria

We have the following custom projects pipelines:

https://github.com/openremote/openremote/blob/1644cf018d3b35fb0e61a53805f24fe363ce49a1/.github/workflows/custom-review.yml#L1

Jobs

detect-changes — Detects whether code changed in the backend or UI directories and outputs metadata about modifications
install-dist — Builds the distribution by calling the install-dist.yml reusable workflow
unit-tests — Runs unit tests via the unit-tests.yml reusable workflow (skipped if backend code didn't change)
integration-tests — Runs integration tests via the integration-tests.yml reusable workflow (skipped if backend code didn't change)

Commented out (inactive):

code-coverage — Would run code coverage analysis if uncommented
deployment — Would deploy the application if uncommented

https://github.com/openremote/openremote/blob/1644cf018d3b35fb0e61a53805f24fe363ce49a1/.github/workflows/custom-staging.yml#L1

Jobs

detect-changes — Detects whether code changed in the backend or UI directories, outputs metadata about what was modified
install-dist — Calls the install-dist.yml reusable workflow to build the distribution (can be skipped if no changes detected)
unit-tests — Calls the unit-tests.yml reusable workflow to run unit tests (skipped if backend code didn't change)
integration-tests — Calls the integration-tests.yml reusable workflow to run integration tests (skipped if backend code didn't change)

Commented out (inactive):

code-coverage — Would run code coverage analysis if uncommented

Will make deployments work for staging workflow
Keep install dist for review pipeline -> would be helpful to find issues before merging
Leave out code-coverage unless it easy to apply (without taking too much time to integrate it everywhere)
Leave out other lint jobs from the main job and create an issue for it.

We need to address dispatching deployments (manually) as well.

Related #2958 (comment)

Also we should pin the hash of the workflows on the master repo in custom projects and have an action that automatically updates this when we update custom projects.

We've decided this issue should only migrate custom-project-test to see if we can get it to work successfully.

I'll create a follow up issue for the remaining custom projects.

Most projects don't deploy on merge (ref org:openremote path:.ci_cd/ci_cd.json). Though I'll still make sure this remains functional.

It's more important the manual dispatching of deployments is tested well.

Test custom-review.yml
Test custom-staging.yml (without deployment)
Test a deployment from custom-staging.yml
- Test legacy support
Test manual deployment
Test deployment with a custom app and custom components.

Navigation Menu

Repository navigation

Migrate custom project test over to the new custom project environment workflows #2955

Description

Acceptance criteria

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Migrate custom project test over to the new custom project environment workflows #2955

Description

Description

Acceptance criteria

Activity

Ekhorn commented on Jun 30, 2026

Ekhorn commented on Jun 30, 2026

Ekhorn commented on Jun 30, 2026

Ekhorn commented on Jul 28, 2026

Ekhorn commented on Oct 5, 2026

Ekhorn commented on Oct 16, 2026

Ekhorn commented on Oct 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions