Skip to content

Fix: Docker deployment issue with frontend resources#240

Merged
kklldog merged 5 commits into
dotnetcore:masterfrom
milkandpotato:master
Jul 26, 2026
Merged

Fix: Docker deployment issue with frontend resources#240
kklldog merged 5 commits into
dotnetcore:masterfrom
milkandpotato:master

Conversation

@milkandpotato

Copy link
Copy Markdown
Contributor

No description provided.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

This PR aims to resolve Docker deployments missing/breaking the admin console frontend by building the React (Umi) UI during the Docker image build and copying the generated dist assets into the ASP.NET app’s wwwroot/ui folder. It also aligns several UI locale imports to use umi exports and normalizes the init-password route casing for Linux/container environments.

Changes:

  • Add a dedicated Docker build stage for the React UI and copy dist into AgileConfig.Server.Apisite/wwwroot/ui.
  • Switch several useIntl/getIntl/getLocale imports to come from umi instead of Umi-generated temp paths / react-intl.
  • Normalize init-password navigation/redirect path to /user/initPassword.

Reviewed changes

Copilot reviewed 7 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
src/AgileConfig.Server.UI/react-ui-antd/src/pages/User/login/index.tsx Adjusts init-password redirect route casing.
src/AgileConfig.Server.UI/react-ui-antd/src/pages/User/comps/updateUser.tsx Updates useIntl import to umi.
src/AgileConfig.Server.UI/react-ui-antd/src/pages/Configs/index.tsx Consolidates intl imports to umi.
src/AgileConfig.Server.UI/react-ui-antd/src/pages/Apps/comps/userAuth.tsx Updates useIntl import to umi.
src/AgileConfig.Server.UI/react-ui-antd/src/pages/Apps/comps/updateForm.tsx Updates useIntl import to umi.
src/AgileConfig.Server.Apisite/Controllers/HomeController.cs Updates init-password redirect route casing.
Dockerfile Adds UI build stage and copies built assets into server wwwroot/ui.
.gitignore Ignores local .worktrees/ directory.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread Dockerfile
Comment thread Dockerfile
WORKDIR /app
EXPOSE 5000

FROM node:16 AS ui-build
@kklldog

kklldog commented Jun 1, 2026

Copy link
Copy Markdown
Collaborator

@copilot 如果前端代码也在docker镜像构建的时候build,那我原本来 workflow 里编译前端的步骤是不是不需要了?

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
@kklldog

kklldog commented Jul 26, 2026

Copy link
Copy Markdown
Collaborator

Reviewed the diff. All three fixes are correct and address real breakage — thanks for this.

Verified as genuine bugs:

  • Route casing. config/routes.ts:17 declares /user/initPassword, and umi/react-router matching is case-sensitive — both redirect sites (HomeController.cs:39, login/index.tsx:34) were dead links to a 404. No other lowercase route references remain (the pages.initpassword.* entries are i18n message ids, unrelated).
  • @/.umi/ imports. .umi is umi's generated temp dir; importing from it breaks under a clean npm ci && npm run build in Docker since nothing has generated it yet at type-check time. umi re-exports useIntl/getIntl/getLocale, so behavior is unchanged. Swapping react-intl's useIntl for umi's in Configs/index.tsx is also right — umi's variant is locale-provider-aware.
  • Dockerfile stage ordering is sound. COPY src/. . runs before COPY --from=ui-build, so the UI output isn't clobbered. npm ci works — package-lock.json is tracked and lockfileVersion: 2 is compatible with the npm 8 shipped in node 16. Copying package*.json first for layer caching is the right call.

Two things I'd like addressed before merge:

  1. Duplicated UI build in the publish pipeline. publish.yml already builds the UI in a separate job and downloads the artifact into src/AgileConfig.Server.Apisite/wwwroot/ui before docker build. With this PR the UI gets built twice on every release, and the in-Docker build silently wins. I'd delete the build-reactapp job + artifact download from publish.yml / arm32.yml / arm64.yml — a self-contained Dockerfile is the better invariant and is what makes local builds reproducible.

  2. node:16 is long past EOL (Sep 2023), so no security patches in the build stage. It matches the existing CI matrix so it's not a regression, but pinning a dead base image into the release path is worth fixing here. Suggest node:20-alpine (or node:22) with a matching CI matrix bump. If the umi 3.x toolchain won't build on 20, that's a signal worth surfacing rather than burying.

Minor:

  • The .gitignore .worktrees/ entry is unrelated local-tooling noise — consider splitting it out.
  • login/index.tsx:32 still has a console.log(resp) right above the changed line; free cleanup while the file is open.

Testing: none added, and realistically none is warranted for build plumbing plus two string fixes. The meaningful check is a docker build . && docker run smoke test confirming /ui serves and the HasSa() == false path lands on the init-password page rather than a 404. If you want a regression guard for this class of casing bug, an integration assert that HomeController.IndexAsync redirects to a route present in routes.ts would catch it.

Security: nothing introduced; npm ci is strictly better than the npm install used in CI. Unrelated to this PR, but noting for the record: this Dockerfile downgrades OpenSSL security levels (SECLEVEL=21, TLSv1) — pre-existing and untouched here, but worth a separate issue.

Approve with the two follow-ups above.

@kklldog
kklldog merged commit 1a0a265 into dotnetcore:master Jul 26, 2026
2 checks passed
@kklldog

kklldog commented Jul 26, 2026

Copy link
Copy Markdown
Collaborator

Thanks for your contribution

pull Bot pushed a commit to weiyilai/AgileConfig that referenced this pull request Jul 26, 2026
The Dockerfile now builds the React admin UI itself in a dedicated
ui-build stage (added in dotnetcore#240), so building it again in a separate CI
job and shipping the result via artifact was doing the same work twice
per release — and the in-Docker build silently won anyway.

Dropping the CI job leaves a single UI build path and keeps
'docker build .' reproducible outside of CI.

master-ci / master-pr-ci keep their build-reactapp job: those are
compile-only checks that gate frontend errors on PRs and never produce
an artifact. release-xxx keeps its job too, since its zip release
artifact comes from 'dotnet publish' and never goes through Docker.
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.

3 participants