maddoscientisto-net/README.md

# 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.