Closing without merging. After further investigation (prompted by a good catch from the user), mcpo/ was never actually wired into this repo's deploy pipeline correctly:
ai.yaml's bind mounts point at /volume1/docker/mcpo/config.json on the host, but nothing in stack-deploy.sh or the Woodpecker pipeline syncs compose-files/mcpo/ there — the git copy was a stale, unmanaged mirror of a hand-edited host file.
Worse: merging this PR as-is would have made .woodpecker/deploy.yml's changed-file stack-detection (cut -d/ -f1 on changed paths) treat mcpo/ as a stack name and call stack-deploy.sh mcpo, which errors (mcpo has no mcpo.yaml/mcpo.yml main compose file) and would have failed the whole pipeline run.
All content from this PR (Dockerfile, entrypoint.sh, secrets doc) has moved to the new homelab/mcp-config repo, which also absorbs the previously-orphaned mcpo/config.json and woodpecker-mcp.mjs, replaces every plaintext secret in that config with ${VAR} templating (Pattern C), and adds a real dedicated deploy pipeline that finally closes the "hand-edited on host" gap. See that repo's README for full details.
Follow-up in this repo: mcpo/config.json and mcpo/woodpecker-mcp.mjs should be deleted here once mcp-config's pipeline is confirmed working, to avoid two stale sources of truth existing simultaneously.
**Closing without merging.** After further investigation (prompted by a good catch from the user), `mcpo/` was never actually wired into this repo's deploy pipeline correctly:
- `ai.yaml`'s bind mounts point at `/volume1/docker/mcpo/config.json` on the host, but nothing in `stack-deploy.sh` or the Woodpecker pipeline syncs `compose-files/mcpo/` there — the git copy was a stale, unmanaged mirror of a hand-edited host file.
- Worse: merging this PR as-is would have made `.woodpecker/deploy.yml`'s changed-file stack-detection (`cut -d/ -f1` on changed paths) treat `mcpo/` as a stack name and call `stack-deploy.sh mcpo`, which errors (`mcpo` has no `mcpo.yaml`/`mcpo.yml` main compose file) and would have failed the whole pipeline run.
All content from this PR (Dockerfile, entrypoint.sh, secrets doc) has moved to the new **[homelab/mcp-config](https://git.bryanmail.net/homelab/mcp-config)** repo, which also absorbs the previously-orphaned `mcpo/config.json` and `woodpecker-mcp.mjs`, replaces every plaintext secret in that config with `${VAR}` templating (Pattern C), and adds a real dedicated deploy pipeline that finally closes the "hand-edited on host" gap. See that repo's README for full details.
Follow-up in this repo: `mcpo/config.json` and `mcpo/woodpecker-mcp.mjs` should be deleted here once `mcp-config`'s pipeline is confirmed working, to avoid two stale sources of truth existing simultaneously.
Part 1/3 of FlowAgent (Power Automate MCP) integration into the mcpo service
(NOT mcpo-critical). This PR only adds the image build artifacts; it does not
modify ai.yaml, mcpo/config.json, or the Woodpecker deploy pipeline, so no live
service is affected by merging this alone.
Background: mcpo/config.json previously had a dead/abandoned "powerautomate"
entry (npm package powerautomate-mcp, never onboarded to the secrets pipeline)
that will be replaced by this in a follow-up PR. This build produces a
self-contained image with:
- azure-cli, for non-interactive `az login --service-principal` at container
start (see entrypoint.sh)
- FlowAgent's self-contained MCP engine (server/mcp.mjs from
microsoft/power-platform-skills — official MIT-licensed Microsoft repo),
pinned via FLOWAGENT_REF build arg rather than tracking `main`, so builds
stay reproducible until deliberately bumped.
Requires (added in follow-up PRs, not yet live):
- Woodpecker secrets: flowagent_azure_client_id, flowagent_azure_tenant_id,
flowagent_azure_client_secret (Pattern C, Docker secrets via _FILE)
- Azure AD App Registration with Power Automate + Dataverse permissions,
admin-consented (manual, outside GitOps — see secrets/flowagent.secrets.example)
Reads the three _FILE-convention secrets (mounted by Swarm from Docker secrets
provisioned by Woodpecker — see secrets/flowagent.secrets.example), performs
`az login --service-principal`, then execs into whatever command mcpo invokes
(node /app/flowagent/mcp.mjs). No secret value is ever written to disk outside
the ephemeral Docker secret mount, logged, or baked into the image.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closing without merging. After further investigation (prompted by a good catch from the user),
mcpo/was never actually wired into this repo's deploy pipeline correctly:ai.yaml's bind mounts point at/volume1/docker/mcpo/config.jsonon the host, but nothing instack-deploy.shor the Woodpecker pipeline syncscompose-files/mcpo/there — the git copy was a stale, unmanaged mirror of a hand-edited host file..woodpecker/deploy.yml's changed-file stack-detection (cut -d/ -f1on changed paths) treatmcpo/as a stack name and callstack-deploy.sh mcpo, which errors (mcpohas nomcpo.yaml/mcpo.ymlmain compose file) and would have failed the whole pipeline run.All content from this PR (Dockerfile, entrypoint.sh, secrets doc) has moved to the new homelab/mcp-config repo, which also absorbs the previously-orphaned
mcpo/config.jsonandwoodpecker-mcp.mjs, replaces every plaintext secret in that config with${VAR}templating (Pattern C), and adds a real dedicated deploy pipeline that finally closes the "hand-edited on host" gap. See that repo's README for full details.Follow-up in this repo:
mcpo/config.jsonandmcpo/woodpecker-mcp.mjsshould be deleted here oncemcp-config's pipeline is confirmed working, to avoid two stale sources of truth existing simultaneously.Part 1/3 of FlowAgent (Power Automate MCP) integration into the mcpo service (NOT mcpo-critical). This PR only adds the image build artifacts; it does not modify ai.yaml, mcpo/config.json, or the Woodpecker deploy pipeline, so no live service is affected by merging this alone. Background: mcpo/config.json previously had a dead/abandoned "powerautomate" entry (npm package powerautomate-mcp, never onboarded to the secrets pipeline) that will be replaced by this in a follow-up PR. This build produces a self-contained image with: - azure-cli, for non-interactive `az login --service-principal` at container start (see entrypoint.sh) - FlowAgent's self-contained MCP engine (server/mcp.mjs from microsoft/power-platform-skills — official MIT-licensed Microsoft repo), pinned via FLOWAGENT_REF build arg rather than tracking `main`, so builds stay reproducible until deliberately bumped. Requires (added in follow-up PRs, not yet live): - Woodpecker secrets: flowagent_azure_client_id, flowagent_azure_tenant_id, flowagent_azure_client_secret (Pattern C, Docker secrets via _FILE) - Azure AD App Registration with Power Automate + Dataverse permissions, admin-consented (manual, outside GitOps — see secrets/flowagent.secrets.example)FlowAgent MCP (Power Automate) — PR 1/3: image build artifacts only, nothing wired liveto [SUPERSEDED — see homelab/mcp-config] FlowAgent MCP (Power Automate) — PR 1/3Pull request closed