Skip to content

feat: expose deployment log reader#54

Open
agentHits wants to merge 1 commit into
Dokploy:mainfrom
agentHits:feat/expose-deployment-logs
Open

feat: expose deployment log reader#54
agentHits wants to merge 1 commit into
Dokploy:mainfrom
agentHits:feat/expose-deployment-logs

Conversation

@agentHits

Copy link
Copy Markdown

Summary

Closes #53.

This syncs the generated Dokploy OpenAPI artifacts with the current published spec so the MCP server exposes deployment-readLogs.

That gives schedule users a direct way to read the deployment log created by a manual schedule run:

  • deployment-readLogs is now included in tools/list.
  • deployment-readLogs routes tools/call to GET /deployment.readLogs with deploymentId and optional tail.
  • TOOLS.md now documents the generated deployment log reader.

The sync also pulls in the other endpoints currently present in the published Dokploy OpenAPI spec but missing from src/generated/openapi.json.

Testing

  • corepack pnpm exec vitest run src/server.test.ts --reporter=verbose
  • corepack pnpm run lint
  • corepack pnpm run type-check
  • corepack pnpm run test
  • corepack pnpm run build
  • git diff --check

Note: pnpm run lint passes with the existing src/utils/responseFormatter.ts static-only class warning.

QA

Independent Agent Flow QA rechecked the final diff and returned pass.

Live Dokploy schedule execution was not tested because this PR does not use a real Dokploy instance, secrets, Docker, or deployment infrastructure.

Что:
- синхронизированы generated Dokploy OpenAPI tools с текущим upstream spec, включая `deployment-readLogs`;
- обновлена generated tools documentation;
- добавлены regression tests для `tools/list` и `tools/call` маршрутизации `deployment-readLogs`.
Зачем:
- MCP clients смогут читать deployment logs для вручную запущенных schedule runs и сохранять command output как audit evidence.
Риски:
- live Dokploy schedule execution не проверялся, потому что реальный instance, secrets и infrastructure не использовались.
Проверки:
- Команды и результаты: `corepack pnpm exec vitest run src/server.test.ts --reporter=verbose` прошел, 1 file / 6 tests; `corepack pnpm run lint` прошел с одним существующим warning в `src/utils/responseFormatter.ts`; `corepack pnpm run type-check` прошел; `corepack pnpm run test` прошел, 3 files / 27 tests; `corepack pnpm run build` прошел; `git diff --check` прошел; independent Agent Flow QA вернул pass.
- Ограничения: live Dokploy API schedule log retrieval не проверялся.

What:
- synchronized generated Dokploy OpenAPI tools with the current upstream spec, including `deployment-readLogs`;
- updated the generated tools documentation;
- added regression tests for `tools/list` exposure and `tools/call` routing for `deployment-readLogs`.
Why:
- MCP clients can read deployment logs for manually triggered schedule runs and capture command output as audit evidence.
Risks:
- live Dokploy schedule execution was not tested because no real instance, secrets, or infrastructure were used.
Checks:
- Commands and results: `corepack pnpm exec vitest run src/server.test.ts --reporter=verbose` passed, 1 file / 6 tests; `corepack pnpm run lint` passed with one existing warning in `src/utils/responseFormatter.ts`; `corepack pnpm run type-check` passed; `corepack pnpm run test` passed, 3 files / 27 tests; `corepack pnpm run build` passed; `git diff --check` passed; independent Agent Flow QA returned pass.
- Limitations: live Dokploy API schedule log retrieval was not exercised.

Closes Dokploy#53

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 23873361d9

ℹ️ 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".

Comment thread src/generated/tools.ts
method: "POST",
path: "/server.update",
schema: z.object({ "name": z.string().min(1), "description": z.union([z.string(), z.null()]), "serverId": z.string().min(1), "ipAddress": z.string(), "port": z.number(), "username": z.string(), "sshKeyId": z.union([z.string(), z.null()]), "serverType": z.enum(["deploy","build"]), "command": z.string().optional() }),
schema: z.object({ "name": z.string().min(1), "description": z.union([z.string(), z.null()]), "serverId": z.string().min(1), "ipAddress": z.string(), "port": z.number(), "username": z.string(), "sshKeyId": z.union([z.string(), z.null()]), "serverType": z.enum(["deploy","build"]), "enableDockerCleanup": z.boolean().default(true), "command": z.string().optional() }),

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Do not default cleanup on server updates

When a caller updates a server that currently has Docker cleanup disabled and omits enableDockerCleanup, this Zod default is applied before the handler posts the parsed arguments, so the request includes enableDockerCleanup: true and silently re-enables cleanup. The OpenAPI required list leaves this field optional for server-update, so the generated client should preserve omission or require/fetch the existing value rather than turning every update into true.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Expose logs/stdout for manually run schedules

1 participant