Skip to content

Enhance container management and UI with version info and fixes - #464

Open
cmyers-mieweb wants to merge 4 commits into
mainfrom
issue-449-453-358-restart-confirm-jobs-back-version-footer
Open

Enhance container management and UI with version info and fixes#464
cmyers-mieweb wants to merge 4 commits into
mainfrom
issue-449-453-358-restart-confirm-jobs-back-version-footer

Conversation

@cmyers-mieweb

@cmyers-mieweb cmyers-mieweb commented Aug 25, 2026

Copy link
Copy Markdown
Collaborator

Resolves:
#358
#449
#453

This pull request introduces two main improvements: (1) a new application footer that displays the running version and provides a "Report a bug" link pre-filled with contextual information, and (2) a significant change to container update behavior, ensuring containers are only restarted when the user explicitly requests it, never implicitly. It also improves user feedback and API documentation to reflect this behavior, and enhances navigation in the job detail page.

User Interface Enhancements:

  • Added a new AppFooter component to the UI, which displays the running version (linked to its GitHub commit) and a "Report a bug" link that pre-fills the GitHub issue template with the current URL, username, and version. The footer is now included in the main layout. (AppFooter.tsx, AppLayout.tsx, auth.ts, index.js) [1] [2] [3] [4] [5] [6]
  • The job detail page "Back" button now returns to the current site's containers list (or sites list as a fallback), improving navigation. (JobDetailPage.tsx) [1] [2] [3]

Container Update and Restart Behavior:

  • Changed the backend and API so that updating container configuration (environment variables or entrypoint) never implicitly restarts the container. A restart is only performed when explicitly requested by the user. (containers.js, openapi.v1.yaml) [1] [2] [3]
  • The API response now includes a pendingRestart flag when changes are saved but not yet applied, and the user interface displays clear feedback when changes require a restart to take effect. (containers.js, ContainerFormPage.tsx, openapi.v1.yaml) [1] [2] [3] [4] [5]
  • When editing a container, if the user chooses to "restart after saving", a confirmation modal is now shown to prevent accidental disruptive restarts. (ContainerFormPage.tsx) [1] [2] [3] [4]

API and Documentation Updates:

  • Updated the OpenAPI documentation to clarify that restarts only occur when explicitly requested, and documented the new pendingRestart response property. (openapi.v1.yaml) [1] [2] [3]
  • The server /health endpoint now includes version information for the frontend footer. (index.js) [1] [2]

PUT /containers/:id no longer enqueues an implicit restart job when env/entrypoint change - a restart happens only when restart:true is sent. The edit form now shows a confirmation modal before saving with restart enabled, and the response/toast tell the user saved changes apply on the next restart.
The Back button linked to '..' which resolves to /jobs (no route). It now returns to the current site's containers list, falling back to /sites.
GET /api/v1/health now includes the startup-cached git version info. New AppFooter shows the version (linked to its commit) plus a Report a bug link that pre-fills the GitHub bug template with the current URL, username, and version.

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 improves the operator/user experience around container changes by (a) making container restarts strictly explicit (no more implicit restarts on config changes), and (b) enhancing the UI with version reporting + easier bug reporting, plus a small navigation improvement on job details.

Changes:

  • Backend: update-container no longer enqueues restart jobs due to env/entrypoint changes unless restart: true is explicitly provided; adds pendingRestart to the update response.
  • Frontend: adds a global footer showing running version + a prefilled “Report a bug” link; adds a restart confirmation modal on edit when “restart after saving” is enabled; improves jobs “Back” navigation.
  • Docs: updates OpenAPI container update endpoint docs to reflect the explicit-restart behavior and pendingRestart.

Reviewed changes

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

Show a summary per file
File Description
create-a-container/routers/api/v1/index.js Extends /health response to include cached server version info for the SPA footer.
create-a-container/routers/api/v1/containers.js Makes restart enqueue strictly opt-in; returns pendingRestart and updated messaging.
create-a-container/openapi.v1.yaml Updates container PUT docs to reflect explicit restart behavior and documents pendingRestart.
create-a-container/client/src/pages/jobs/JobDetailPage.tsx Adjusts Back navigation to go to the current site’s containers (or sites list fallback).
create-a-container/client/src/pages/containers/ContainerFormPage.tsx Adds restart confirmation modal and surfaces pending-restart messaging on save.
create-a-container/client/src/lib/auth.ts Adds VersionInfo typing and wires /health’s version into the typed ServerInfo.
create-a-container/client/src/app/AppLayout.tsx Adds the new footer to the app layout.
create-a-container/client/src/app/AppFooter.tsx New footer component with version link + “Report a bug” issue-form prefill.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment on lines +352 to +356
toast.success(
isEdit
? pendingRestart
? 'Container updated — changes take effect on the next restart'
: 'Container updated'
Comment on lines 875 to 879
containerId: { type: integer }
jobId: { type: integer, nullable: true, description: 'Restart job id, when a restart was enqueued' }
dnsWarnings: { type: array, items: { type: string } }
pendingRestart: { type: boolean, description: 'true when env/entrypoint changes were saved but no restart was requested — they apply on the next restart' }
message: { type: string }
isDev: process.env.NODE_ENV !== 'production',
oidcEnabled: isOidcEnabled(),
banner,
// Cached at startup in app.locals (see app.js); the SPA footer shows it.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

The server-side getVersionInfo relies on the local filesystem the server is running from being a git repository. This assumption does not hold once the software is packaged and deployed to the live system. As it stands, the source of truth for the current version would be the version of the installed deb package, but trying to read that would be overkill. Since the server and client are distributed in the same package, we should bake the version into the client build in the packaging workflow.

  1. A release is generated with the version in the tag
  2. .github/workflows/release.yml builds images/builder which generates the deb packages
  3. Within images/builder, make deb is ran from the repo root
  4. make deb delegates to the Makefile in each major component, the create-a-container Makefile runs npm build for the client component
  5. npm build in the client delegates to vite build

https://github.com/mieweb/ozwell-studio also uses vite build and a Github-releases driven versioning. This sets the version in the package.json just before the final build and bakes the value into the final artifact so there is no live-query required.

Implement this same idea in the build workflow here, then remove the existing logic to interogate the version from the local git repo.

const needsRestart = forceRestart || envChanged || entrypointChanged;
// Never restart implicitly (issue #449): a restart job is enqueued only
// when the caller explicitly asks for one. Saved env/entrypoint changes
// are applied by reconfigure-container.js on the next restart.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I know this is doing exactly what the ticket asked for but I don't fully agree with the logic. The real problem with the implicit restart is that if, for example, the admin changed the default container vars, that would queue a restart regardless of the change the user made (possibly even if they made no changes). In reality, the implicit restart is good if the user intentionally changes entrypoint/environment because otherwise they may be left to wonder why their changes didn't take effect. Really there's 2 problems here:

  1. Invisible (to the user) changes by the admin can make a restart nessecary
  2. The user is not properly informed of changes requiring a restart

We can hook into this new solution to fix both of these, but we need one more layer on top. We keep this new "no restarts by default" logic to keep admin changes from bleeding into the container lifecycle behavior BUT if the user makes environment or entrypoint changes (or anything else requiring a restart) then some sort of noticable but unobtrusive UI affordance informs the user that this change requires a restart and the "restart" toggle is switched on. The user can still switch this off manually afterwards but another warning (under the toggle maybe) "this change requires a restart but a restart will not be performed".

…start-requiring edits

Per PR #464 review (runleveldev):

- Version: the deployed system has no git checkout, so getVersionInfo (runtime git interrogation) is removed. The packaging build now writes the release version into the client package.json (new 'node' semver format in package-version, applied in the create-a-container Makefile build target) and vite bakes it into the bundle as __APP_VERSION__. The footer shows it (dev builds show 'Development build') and /health no longer returns version.

- Restart UX: saving still never restarts implicitly, but when the user edits env vars or the entrypoint the 'Restart after saving' toggle switches on automatically; turning it back off shows an inline warning that the change only applies on the next restart.

Also per copilot review: the save toast now uses the server's message so update-status wording lives in one place.
@cmyers-mieweb

Copy link
Copy Markdown
Collaborator Author

Recent changes in commit e3cb7ad

Version is now baked into the client build (review feedback from @runleveldev)

The deployed system has no git checkout, so the runtime git interrogation
(getVersionInfo) is gone entirely — /health no longer returns version
(which also brings it back in line with the OpenAPI schema).

  • package-version gained a node format that emits clean semver
    (2026.8.1, prerelease as -rc1, snapshots as +N.ghash build metadata)
  • The packaging build (make build, hit by images/buildermake deb)
    writes that version into the client package.json right before
    vite build; vite bakes it in as __APP_VERSION__ — same pattern as
    ozwell-studio
  • The footer renders the baked version (linked to GitHub releases) and shows
    "Development build" for dev builds (0.0.0)

Restart toggle follows restart-requiring edits (review feedback from @runleveldev)

Backend stays "no restarts by default" so admin-side changes never bleed into
the container lifecycle, but now:

  • Editing env vars or the entrypoint automatically switches the
    "Restart after saving" toggle on (compared against the saved container,
    so reverting an edit switches it back off)
  • Manually flipping the toggle takes over from the auto behavior
  • Toggle off with restart-requiring changes shows an inline warning:
    the change is saved but only applies on the next restart

Also per copilot review: the save toast now uses the backend's message, so
update-status wording lives in one place.

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

Labels

None yet

Projects

None yet

3 participants