71 lines
2.6 KiB
Markdown
71 lines
2.6 KiB
Markdown
# maddoscientisto.net
|
|
|
|
Blazor WebAssembly (.NET 10) static site packaged as an Nginx container and publishable to a Forgejo container registry.
|
|
|
|
## Project layout
|
|
|
|
- `src/MaddoScientisto.Web` - Blazor WebAssembly app
|
|
- `Dockerfile` - multi-stage build and Nginx runtime image
|
|
- `nginx.conf` - static hosting and SPA fallback
|
|
- `.forgejo/workflows/publish-container.yml` - Forgejo Actions workflow for build and push
|
|
|
|
## Local development
|
|
|
|
```powershell
|
|
dotnet restore
|
|
dotnet build src/MaddoScientisto.Web/MaddoScientisto.Web.csproj -c Release
|
|
dotnet run --project src/MaddoScientisto.Web/MaddoScientisto.Web.csproj
|
|
```
|
|
|
|
## Local publish check
|
|
|
|
```powershell
|
|
dotnet publish src/MaddoScientisto.Web/MaddoScientisto.Web.csproj -c Release -o .\artifacts\publish
|
|
```
|
|
|
|
Published static files are under `.\artifacts\publish\wwwroot`.
|
|
|
|
## Docker build and run
|
|
|
|
```powershell
|
|
docker build -t maddoscientisto-web:local .
|
|
docker run --rm -p 8080:80 maddoscientisto-web:local
|
|
```
|
|
|
|
Open `http://localhost:8080`.
|
|
|
|
## Forgejo registry configuration
|
|
|
|
Set these Forgejo Actions variables:
|
|
|
|
- `FORGEJO_REGISTRY` (example: `forgejo.example.com`)
|
|
- `IMAGE_NAMESPACE` (example: `maddo`)
|
|
- `IMAGE_NAME` (example: `maddoscientisto-web`)
|
|
- Optional: `DOCKER_HOST` (example: `tcp://forgejo-docker-in-docker:2375`)
|
|
|
|
Set these Forgejo Actions secrets:
|
|
|
|
- `FORGEJO_REGISTRY_USERNAME`
|
|
- `FORGEJO_REGISTRY_TOKEN`
|
|
|
|
## Workflow behavior
|
|
|
|
The workflow in `.forgejo/workflows/publish-container.yml` runs on pushes to `master` (and manual dispatch), builds the container image, and pushes:
|
|
|
|
- `${FORGEJO_REGISTRY}/${IMAGE_NAMESPACE}/${IMAGE_NAME}:latest`
|
|
- `${FORGEJO_REGISTRY}/${IMAGE_NAMESPACE}/${IMAGE_NAME}:sha-<12-char-commit>`
|
|
|
|
## Forgejo runner notes (Docker-in-Docker)
|
|
|
|
If the runner image does not contain the `docker` binary, the workflow bootstraps a Docker CLI in user space before login/build/push.
|
|
|
|
For dind-based runners, the workflow resolves `DOCKER_HOST` in this order:
|
|
|
|
- `vars.DOCKER_HOST` if explicitly set
|
|
- `/var/run/docker.sock` if mounted into the job
|
|
- `tcp://forgejo-docker-in-docker:2375` if that DNS name is visible inside the job container
|
|
- `tcp://<job-container-default-gateway>:2375` as a fallback for nested Docker bridge setups
|
|
|
|
If you still get connection failures after the CLI bootstrap step, set a repo variable named `DOCKER_HOST` to the daemon endpoint that is reachable from inside the job container.
|
|
|
|
Important: the Compose service name `forgejo-docker-in-docker` is often only resolvable from the outer runner container, not from the inner job container created by the Docker daemon. In that case, use the gateway-based fallback or set `DOCKER_HOST` explicitly.
|