Throwaway. One file, deleted once #237 has an answer either way. Nothing else changes.
Why a spike and not a design
#233 was designed on an assumption about the Docker build context, and it broke every Portainer deploy. The chosen fix for the commit stamp — build in Actions, push to Gitea's registry, Portainer pulls — rests on three more assumptions about your infrastructure that nothing in this repository can settle:
Can a job here run docker build at all? The other workflows use services:, which proves the runner can start containers — not that a job can build images. That needs a Docker socket or buildx.
Is the container registry usable? The packages API answers and lists nothing, so it has never been exercised here. Pushing also needs a token with package write scope.
What does the real build cost on this runner? Not a nice-to-know. backend-integration.yml is manual because a job once held this runner for 3h12m and queued everything behind it. A design that builds on every merge to main lands on that same runner.
Safe to merge
workflow_dispatch only — no push, no pull_request. Merging it changes nothing until you press the button. Verified: the trigger block contains only workflow_dispatch, and timeout-minutes: 25 bounds a hang the same way backend-integration.yml already documents.
What it does
Reports Docker capabilities first and never fails on that step, so a failure later is still informative rather than just "it didn't work"
Says whether a token is present as a boolean — never prints it
Builds and pushes a trivial image before the real one. That separates "can this runner build and push anything" from "does our Dockerfile work here", so a later failure tells you which half is broken
Builds the real image, times it, and pushes it tagged with the commit
Runs the pushed image and prints dist/buildInfo.json, proving the commit can actually be baked in — the entire reason for the exercise. In an Actions checkout .git is present, which is precisely the difference from Portainer's context that caused #235
After you run it
The last step prints the Portainer instructions. Roughly: Registries → Add registry → Custom, pointing at gitea.bermudalamb.synology.me with a token that has package read, then pull spike-trivial. That answers the third unknown — including whether the NAS's Docker trusts the certificate.
One thing to watch: some Gitea versions only offer the "Run workflow" button for workflows on the default branch. If you don't see it on this branch, merge first — it's manual-only, so that's still inert.
Report the output back and I'll turn it into a design, or into a recommendation not to do this.
Cleanup
Whichever way it goes: delete this file, and delete the spike-trivial and spike-<sha> packages. Nothing here is meant to survive.
**Throwaway.** One file, deleted once #237 has an answer either way. Nothing else changes.
## Why a spike and not a design
#233 was designed on an assumption about the Docker build context, and it broke every Portainer deploy. The chosen fix for the commit stamp — build in Actions, push to Gitea's registry, Portainer pulls — rests on three more assumptions about your infrastructure that nothing in this repository can settle:
1. **Can a job here run `docker build` at all?** The other workflows use `services:`, which proves the runner can *start* containers — not that a job can build images. That needs a Docker socket or buildx.
2. **Is the container registry usable?** The packages API answers and lists nothing, so it has never been exercised here. Pushing also needs a token with package write scope.
3. **What does the real build cost on this runner?** Not a nice-to-know. `backend-integration.yml` is manual because a job once held this runner for 3h12m and queued everything behind it. A design that builds on every merge to `main` lands on that same runner.
## Safe to merge
`workflow_dispatch` only — no `push`, no `pull_request`. Merging it changes nothing until you press the button. Verified: the trigger block contains only `workflow_dispatch`, and `timeout-minutes: 25` bounds a hang the same way `backend-integration.yml` already documents.
## What it does
- Reports Docker capabilities first and **never fails** on that step, so a failure later is still informative rather than just "it didn't work"
- Says whether a token is present as a boolean — never prints it
- Builds and pushes a **trivial** image before the real one. That separates "can this runner build and push anything" from "does our Dockerfile work here", so a later failure tells you which half is broken
- Builds the **real** image, times it, and pushes it tagged with the commit
- Runs the pushed image and prints `dist/buildInfo.json`, proving the commit can actually be baked in — the entire reason for the exercise. In an Actions checkout `.git` is present, which is precisely the difference from Portainer's context that caused #235
## After you run it
The last step prints the Portainer instructions. Roughly: Registries → Add registry → Custom, pointing at `gitea.bermudalamb.synology.me` with a token that has package read, then pull `spike-trivial`. That answers the third unknown — including whether the NAS's Docker trusts the certificate.
**One thing to watch:** some Gitea versions only offer the "Run workflow" button for workflows on the default branch. If you don't see it on this branch, merge first — it's manual-only, so that's still inert.
Report the output back and I'll turn it into a design, or into a recommendation not to do this.
## Cleanup
Whichever way it goes: delete this file, and delete the `spike-trivial` and `spike-<sha>` packages. Nothing here is meant to survive.
Ref #237
Throwaway. Deleted once #237 has an answer, whichever way it goes.
#233 was designed on an assumption about the Docker build context and broke every Portainer deploy. The chosen fix for the commit stamp — build in Actions, push to Gitea's registry, have Portainer pull — rests on three more assumptions about infrastructure that nothing in this repository can confirm. This probes them instead of designing around them.
Whether a job here can run `docker build` at all is genuinely unknown: the other workflows use `services:`, which proves the runner can start containers, not that it can build images. Whether the registry is usable is likewise unconfirmed — the packages API answers but lists nothing, so it has never been exercised. And the real build is timed because backend-integration.yml is manual after a job once held this runner for 3h12m, so what an image build costs here is part of deciding whether building on every merge is tenable at all.
The trivial image is built and pushed before the real one on purpose. It separates "can this runner build and push anything" from "does our Dockerfile work here", so a later failure still says which half is broken.
workflow_dispatch only, with no push or pull_request trigger, so merging this changes nothing until somebody presses the button. Bounded by timeout-minutes on the same reasoning backend-integration.yml already documents.
Ref #237
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.
Throwaway. One file, deleted once #237 has an answer either way. Nothing else changes.
Why a spike and not a design
#233 was designed on an assumption about the Docker build context, and it broke every Portainer deploy. The chosen fix for the commit stamp — build in Actions, push to Gitea's registry, Portainer pulls — rests on three more assumptions about your infrastructure that nothing in this repository can settle:
docker buildat all? The other workflows useservices:, which proves the runner can start containers — not that a job can build images. That needs a Docker socket or buildx.backend-integration.ymlis manual because a job once held this runner for 3h12m and queued everything behind it. A design that builds on every merge tomainlands on that same runner.Safe to merge
workflow_dispatchonly — nopush, nopull_request. Merging it changes nothing until you press the button. Verified: the trigger block contains onlyworkflow_dispatch, andtimeout-minutes: 25bounds a hang the same waybackend-integration.ymlalready documents.What it does
dist/buildInfo.json, proving the commit can actually be baked in — the entire reason for the exercise. In an Actions checkout.gitis present, which is precisely the difference from Portainer's context that caused #235After you run it
The last step prints the Portainer instructions. Roughly: Registries → Add registry → Custom, pointing at
gitea.bermudalamb.synology.mewith a token that has package read, then pullspike-trivial. That answers the third unknown — including whether the NAS's Docker trusts the certificate.One thing to watch: some Gitea versions only offer the "Run workflow" button for workflows on the default branch. If you don't see it on this branch, merge first — it's manual-only, so that's still inert.
Report the output back and I'll turn it into a design, or into a recommendation not to do this.
Cleanup
Whichever way it goes: delete this file, and delete the
spike-trivialandspike-<sha>packages. Nothing here is meant to survive.Ref #237