mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-10-25 21:20:25 +00:00
Anso
ea905b758b
* feat(db): bind Blueprint content origin to a GitOps application Pair Git-managed Blueprints one-to-one with an application at the schema layer, and retain the original Direct stack identity so conversion can reuse credentials without minting a second live application. * feat(gitops): add guarded Blueprint binding transitions Reconfigure a live Direct application in place to Blueprint mode through a replay-safe store update, keeping identity and generation lineage stable while recording the mode change in history. * feat(gitops): convert Blueprints onto a live GitOps application Move an existing Direct application in place, freeze Inline YAML as a detach snapshot, and refuse compose edits and deletes while content is Git-managed. Previews expose non-secret source fields and rollback limitations only. * fix(blueprints): refuse Git-managed deploy, apply, and delete Skip reconciler and service apply paths, return 409 before withdraw or approval, and mint a blocked rollout candidate so a converted application stays visible as not executable. * feat(gitops): keep converted applications on the source controller Widen poll and retry scans to converted Blueprint sources, route accepted generations from the live target mode, and refuse Git-tab mutations while a Blueprint still holds the source stack. * feat(api): add Blueprint GitOps content-binding endpoints Expose convert, detach, and adopt so a Blueprint can bind a live Direct application without leaking retained source-stack identity. * feat(ui): add Git-managed Blueprint editor and binding dialogs Operators can convert, adopt, and detach Blueprint content onto a live Git source. The editor and Git tab stay read-only while rollout is blocked. * chore: document Git-managed Blueprint content binding Operator docs and What's New cover convert, detach, and the blocked rollout state. Marker parse keeps optional binding evidence, and Git-managed dispatch uses the operator-facing blocked reason. * test: type BlueprintEditor submit mocks without unused params * fix(gitops): close Blueprint binding audit gaps before QA Expose Retire routes and UI, return 409 on Git-managed blueprint PUT edits, and render binding preview markers and node actions in convert, adopt, detach, and retire dialogs. * fix(gitops): make claimed sheet, adopt, and retire paths production-safe Project blueprint-claimed sources on git-source GET. Adopt tombstones inline apps like convert. Retire restores the original stack identity and clears evidence. * chore(gitops): close non-blocking binding follow-ups Refresh stale projection comments, document Retire, include converted sources in polling settings, and remove unused blueprintModePromoted. * docs: mention Retire in Blueprint intro copy Keep the overview consistent with Detach-or-Retire exit paths.
100 lines
7.9 KiB
Plaintext
100 lines
7.9 KiB
Plaintext
---
|
|
title: Deploy Compose Changes by Pulling From Git Instead of Editing by Hand
|
|
sidebarTitle: Deploy compose changes from Git
|
|
description: Link a running stack to a Git repository, pull a real commit, review the classified change plan, and deploy it, instead of hand-editing the compose file in the browser.
|
|
---
|
|
|
|
Say `marketing-site` is a small nginx stack you created directly in Sencho, and your team has decided the compose file should live in a Git repository instead, so changes go through a commit and a pull request before they reach the stack. This walks through connecting that already-running stack to a repository, pulling a real commit a teammate pushed, reviewing the classified change plan Sencho builds against what is on disk, and applying it, which both writes the new files and redeploys the container.
|
|
|
|
This tutorial covers linking an existing stack to a Git source and running one manual pull-review-apply cycle. It doesn't cover creating a brand-new stack directly from a repository, the three webhook-driven apply modes, polling, suspend, multi-file compose sources, or converting the source onto a Git-managed Blueprint; see the [Git Sources](/features/git-sources) and [Blueprints](/features/blueprint-model) feature pages for those.
|
|
|
|
## Prerequisites
|
|
|
|
- The `admin` or `node-admin` role. Linking a source and running a pull or apply needs the `stack:edit` permission, which `deployer`, `viewer`, and `auditor` do not hold.
|
|
- A running stack to link. If you don't have one, select **Create Stack**, name it `marketing-site`, and replace its compose file with:
|
|
|
|
```yaml
|
|
services:
|
|
web:
|
|
image: nginx:1.27-alpine
|
|
restart: always
|
|
ports:
|
|
- "8098:80"
|
|
```
|
|
|
|
Select **Save & Deploy**. This tutorial's steps and screenshots use this exact stack, so if you use a different name or port, adjust accordingly.
|
|
- A public Git repository over HTTPS that you control, with a compose file committed at its root. The screenshots below use a small throwaway demo repository; any repository with the same shape works.
|
|
- Available on every tier, including Community; no Admiral requirement.
|
|
|
|
<Steps>
|
|
<Step title="Open the Git Source sheet">
|
|
Open the `marketing-site` stack and select **Git Source** in the editor toolbar. The sheet opens from the right, empty, since nothing is linked yet.
|
|
|
|
<Frame>
|
|
<img src="/images/tutorials/connect-a-git-source/git-source-panel-empty.png" alt="Empty Git Source sheet for the marketing-site stack, with crumb Stack, marketing-site, Git source, heading Git source, meta Not linked, a Save toolbar button, and Repository fields for URL, Ref, compose.yaml, Public (no auth), and Review only." />
|
|
</Frame>
|
|
</Step>
|
|
<Step title="Point it at your repository">
|
|
Paste your repository's HTTPS URL into **Repository URL** (for example `https://github.com/your-org/your-repo.git`). Leave **Ref** on its default, `main`, unless your repository uses a different branch, tag, or pinned commit SHA.
|
|
|
|
Select **Browse** to confirm Sencho can actually reach the repository and see its files, rather than trusting the URL is correct. The browser lists every file in the repository; `compose.yaml` is already ticked as the primary compose file, since that name matches the picker's default.
|
|
|
|
<Frame>
|
|
<img src="/images/tutorials/connect-a-git-source/browse-picker.png" alt="Git Source sheet with a Repository URL filled in and the Browse file picker open below the Compose files list, showing a checked compose.yaml and an unchecked README.md fetched live from the repository." />
|
|
</Frame>
|
|
|
|
Leave **Authentication** on **Public (no auth)** for a public repository, and **Apply behavior** on **Review only**, the safest default: a pull only stages a change plan for you to review, it never writes or deploys on its own. Select **Save**. Sencho runs a reachability check against the repository before persisting anything; if that check fails, nothing is saved and the sheet reports why.
|
|
</Step>
|
|
<Step title="Pull the latest commit">
|
|
Now make a change the way your team actually would: edit the compose file in your repository (not in Sencho) and push a commit. For this tutorial, bump the pinned tag from `nginx:1.27-alpine` to `nginx:1.28-alpine` and push it to the ref you configured.
|
|
|
|
Back in the Git Source sheet, select **Pull now**. Sencho fetches the ref's current commit and opens a classified change plan against what's on disk.
|
|
|
|
<Frame>
|
|
<img src="/images/tutorials/connect-a-git-source/pull-preview-diff.png" alt="GIT · CHANGE PLAN dialog for marketing-site, listing a Modify row for compose.yaml (image tag change) with Deploy after apply and Apply in the footer." />
|
|
</Frame>
|
|
|
|
The plan lists only the files that actually change. If the incoming compose file failed `docker compose config` validation, an error banner would appear here and the **Apply** button would stay disabled; since this pull is clean, Apply is enabled.
|
|
</Step>
|
|
<Step title="Apply and deploy in one step">
|
|
Tick **Deploy after apply** at the bottom of the dialog, then select **Apply**. This both writes the incoming file to disk and runs `docker compose up -d` against it, so the running container picks up the new tag immediately instead of just staging the file for a later manual deploy.
|
|
|
|
Sencho shows the deploy's progress the same way any other deploy does, ending in a health check on the recreated container.
|
|
</Step>
|
|
</Steps>
|
|
|
|
## Verify it worked
|
|
|
|
Check from two places, since neither alone proves the pull was actually applied and deployed.
|
|
|
|
**The Git Source sheet.** Reopen it. The Status section now shows the short SHA of the commit you just pulled, a **Source state** of `accepted`, meaning Sencho took that commit as the current generation rather than merely writing its files, and the footer shows when the source was last updated. Nothing is listed as pending at the top of Status, which is what a stack with complete evidence looks like.
|
|
|
|
<Frame>
|
|
<img src="/images/tutorials/connect-a-git-source/last-applied-commit.png" alt="Git Source sheet for marketing-site with Apply behavior still on Review only, Status showing a short commit SHA and Source state accepted, and a freshness line in the footer." />
|
|
</Frame>
|
|
|
|
**The stack itself.** Reopen `marketing-site`. The container recreated on the new image: a fresh uptime, and its logs now start with `nginx/1.28.3` instead of `1.27.5`. The compose editor tab reflects the same change; if it still shows the old tag, reload the page, since the editor buffer doesn't refresh itself after a Git-driven write.
|
|
|
|
<Frame>
|
|
<img src="/images/tutorials/connect-a-git-source/stack-redeployed.png" alt="marketing-site stack page after redeploy, showing marketing-site-web-1 up about a minute, logs starting from nginx/1.28.3, and the compose editor showing image nginx:1.28-alpine." />
|
|
</Frame>
|
|
|
|
## If something goes wrong
|
|
|
|
**Saving the source fails with "The configured branch, tag, or commit was not found," even though the URL is right.** Ref names are case-sensitive, and a typo there (`Main` instead of `main`, for example) surfaces as a distinct not-found error rather than a repository error, because Sencho resolves the ref on the remote before fetching. Double-check the ref against what your Git host actually shows before assuming the URL itself is wrong.
|
|
|
|
<Frame>
|
|
<img src="/images/tutorials/connect-a-git-source/branch-error.png" alt="Git Source sheet with Ref set to the incorrect value Main, and a red error toast in the corner reading The configured branch, tag, or commit was not found." />
|
|
</Frame>
|
|
|
|
## Related
|
|
|
|
<CardGroup cols={2}>
|
|
<Card title="Git Sources" icon="code-branch" href="/features/git-sources">
|
|
Multi-file sources, the three webhook apply modes, private-repo authentication, and the full troubleshooting table.
|
|
</Card>
|
|
<Card title="Deploy a Stack Automatically From Your CI Pipeline" icon="satellite-dish" href="/tutorials/set-up-a-webhook">
|
|
Trigger a Git source pull and deploy from CI instead of pulling by hand from the sheet.
|
|
</Card>
|
|
</CardGroup>
|