|
1 | 1 | # Adobe API Mesh CI/CD Template |
2 | 2 |
|
| 3 | +> ⚠️ **Important:** Starting from version 2.x, a custom container is required. The Dockerfile can be found in `.github/images/aio-mesh-runner/Dockerfile`. If you prefer to use a standard GitHub runner without a custom container, please use version 1.x of this template. |
| 4 | +
|
3 | 5 | This repository is a lightweight starting point for teams that want a repeatable GitHub Actions pipeline for provisioning and updating Adobe API Mesh configurations. Fork it, drop in your mesh definition files, wire up the required Adobe Developer Console credentials, and you will have a push-button deployment path for staging and production meshes. |
4 | 6 |
|
5 | 7 | --- |
@@ -69,6 +71,74 @@ If these variables are present, the workflow writes them to `.env` before runnin |
69 | 71 |
|
70 | 72 | --- |
71 | 73 |
|
| 74 | +### Runner image requirements |
| 75 | +This template is designed to run the deploy workflow inside a lightweight Docker image that already contains Node.js 20.x and the Adobe AIO CLI, but does not bake in the API Mesh plugin. The plugin is installed on each run inside the GitHub Actions job so that it is always available under the correct `$HOME` and CLI config scope. |
| 76 | + |
| 77 | +Dockerfile used by the workflow: |
| 78 | + |
| 79 | +``` |
| 80 | +FROM node:20-bullseye-slim |
| 81 | +
|
| 82 | +RUN apt-get update && apt-get install -y \ |
| 83 | + git \ |
| 84 | + ca-certificates \ |
| 85 | + && rm -rf /var/lib/apt/lists/* |
| 86 | +
|
| 87 | +RUN npm install -g @adobe/aio-cli && \ |
| 88 | + npm cache clean --force && \ |
| 89 | + rm -rf /root/.npm /tmp/* |
| 90 | +
|
| 91 | +WORKDIR /workspace |
| 92 | +
|
| 93 | +``` |
| 94 | +Build and push the AMD64 image: |
| 95 | +``` |
| 96 | +docker buildx build \ |
| 97 | + --platform linux/amd64 \ |
| 98 | + -t ghcr.io/<org-or-user>/aio-mesh-runner:latest \ |
| 99 | + --push \ |
| 100 | + -f .github/images/aio-mesh-runner/Dockerfile . |
| 101 | +``` |
| 102 | + |
| 103 | +Reference it in `deploy.yaml`: |
| 104 | +``` |
| 105 | +jobs: |
| 106 | + deploy: |
| 107 | + runs-on: ${{ matrix.os }} |
| 108 | + container: |
| 109 | + image: ghcr.io/<org-or-user>/aio-mesh-runner:latest |
| 110 | + strategy: |
| 111 | + matrix: |
| 112 | + node-version: ["20"] |
| 113 | + os: [ubuntu-latest] |
| 114 | + # ... |
| 115 | +
|
| 116 | +``` |
| 117 | +#### Why the API Mesh plugin is installed in the runner |
| 118 | +The API Mesh plugin (`@adobe/aio-cli-plugin-api-mesh`) is not installed in the Docker image. Instead, the workflow installs it inside the job, for example: |
| 119 | +``` |
| 120 | + - name: Install API Mesh plugin |
| 121 | + run: aio plugins:install @adobe/aio-cli-plugin-api-mesh |
| 122 | +
|
| 123 | +``` |
| 124 | +This is required because: |
| 125 | + |
| 126 | +- AIO plugins are resolved per user via the CLI config directory under `$HOME` (for example `~/.config/@adobe/aio`), not from a global shared path. |
| 127 | +- In GitHub container jobs, the runner forcibly sets `HOME=/github/home`, which is different from the `HOME` used at image build time (typically `/root`). |
| 128 | +- If the plugin is only installed during `docker build`, it ends up wired to the build-time home and config; when the job runs with `HOME=/github/home`, `aio` does not see those plugins and `aio api-mesh:*` commands fail. |
| 129 | + |
| 130 | +By installing `@adobe/aio-cli-plugin-api-mesh` inside the GitHub Actions job (with the final `$HOME` already set by the runner), the CLI always discovers the plugin correctly, regardless of how the container image was built. |
| 131 | + |
| 132 | +**If you do not have such a runner image, use the 1.x version of this template, where:** |
| 133 | + |
| 134 | +- The job runs directly on `ubuntu-latest` (no `container`: stanza). |
| 135 | +- `aio` and the API Mesh plugin are installed inside the workflow steps (for example using `adobe/aio-cli-setup-action` plus an explicit `aio plugins:install @adobe/aio-cli-plugin-api-mesh`). |
| 136 | + |
| 137 | +In short: |
| 138 | + |
| 139 | +- 2.x template – requires a prebuilt runner image with `aio`; no CLI installation steps in the workflow. |
| 140 | +- 1.x template – no custom image required; CLI and plugin are installed at runtime in the job, which is slower but does not depend on Docker image management. |
| 141 | + |
72 | 142 | ## Quick Start |
73 | 143 |
|
74 | 144 | 1. **Fork this repo** or use it as a template inside your organization. |
|
0 commit comments