Repository navigation
Conversation
|
@codex review |
There was a problem hiding this comment.
Pull request overview
Adds a new developer-guide documentation page describing OpenRemote’s CI/CD pipeline concepts introduced during the pipeline migration referenced in openremote/core#2696, addressing the documentation request in Issue #161.
Changes:
- Introduces a new
CI/CD Pipelinedeveloper-guide page covering pipeline modification/testing, workflow structure, artifacts, Gradle vs workflow responsibilities, and best/worst practices. - Documents optimization strategies (detect-changes, minimal dependency installs, Git LFS usage, artifact reuse).
- Summarizes GitHub Actions concepts relevant to the pipeline (composite actions, reusable workflows, conditional expressions).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5ef00fa8ea
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
c4d762a to
b9ec506
Compare
MartinaeyNL
left a comment
MartinaeyNL
left a comment
There was a problem hiding this comment.
⚠️ Initial review by an AI agent ⚠️
Read through it against the actual workflows — checks, skip inputs, detect-changes outputs, sharding + UI App Tests Status, the tsbuildinfo trick, type=gha, the or-manager-build exception, deploy in .ci_cd/ci_cd.json, and the IS_MAIN_REPO/openremote/.ci_cd compat note all match the code, and all of #161's acceptance criteria are covered. Only open point is the merge-order dependency on openremote/core#3448 (inline at the Custom Projects section).
| - `review.yml` for Pull Requests and the merge queue. | ||
| - `staging.yml` for pushes to `main` and release tags. It builds, tests and publishes the Docker images, Maven artifacts and npm packages. | ||
| - `deploy.yml` for manual [deployments](#deployments). | ||
| - `custom-review.yml`, `custom-staging.yml` and `custom-deploy.yml`, which [custom projects](#custom-projects) call from their own workflows. |
There was a problem hiding this comment.
This section (and the table below) documents custom-deploy.yml, custom-install-dist.yml and custom-staging.yml deploying on push — none of that exists on openremote/core@main yet; it's all in openremote/core#3448 (draft). Side effect: if this merges first, readers are sent to workflows that don't exist. Could you note "merge after openremote/core#3448" in the PR description?
| - `custom-review.yml`, `custom-staging.yml` and `custom-deploy.yml`, which [custom projects](#custom-projects) call from their own workflows. | ||
| - **Job Workflows**: These are reusable workflows (`workflow_call`) that contain the actual steps for specific tasks (like running tests, building dists, or publishing artifacts). Environment workflows call these job workflows, which prevents duplication. | ||
|
|
||
| The previous pipeline, `ci_cd.yml`, is kept for custom projects that have not migrated to the new workflows yet. |
There was a problem hiding this comment.
Now that this page documents the new workflows, 025-code-formatting.md still tells custom projects to use ci_cd.yml@main/@sha — so the docs will contradict each other. Fine as a follow-up issue, just flagging it so it isn't lost.
There was a problem hiding this comment.
This could be done here but the related changes have not yet been merged to master (ref openremote/core#3441).
| @@ -111,6 +111,8 @@ Custom projects deploy with `custom-staging.yml` and `custom-deploy.yml`, see [C | |||
|
|
|||
| Reference the core workflows by commit SHA rather than a branch like `main`, so changes to the core pipeline don't unexpectedly break custom projects. | |||
There was a problem hiding this comment.
Ideally by version, but we need to test this once the new custom project pipelines are adopted.
Description