Document and polish a bit.

oci-image/Containerfile

@@ -1,7 +1,7 @@
 # syntax=docker/dockerfile:1.7
 
-ARG GO_VERSION=1.25
-ARG TEMPORAL_IMAGE=temporalio/auto-setup:1.29.0
+ARG GO_VERSION
+ARG TEMPORAL_IMAGE
 
 FROM golang:${GO_VERSION} AS build
 WORKDIR /workspace
@@ -12,10 +12,9 @@ RUN --mount=type=cache,target=/go/pkg/mod \
 	go mod download
 
 COPY . .
+ARG TARGETOS TARGETARCH
 RUN --mount=type=cache,target=/go/pkg/mod \
-	CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o /workspace/bin/temporal-server .
+	CGO_ENABLED=0 GOOS=${TARGETOS} GOARCH=${TARGETARCH} go build -o /workspace/bin/temporal-server .
 
 FROM ${TEMPORAL_IMAGE} AS runtime
 COPY --from=build /workspace/bin/temporal-server /usr/local/bin/temporal-server
-
-ENTRYPOINT ["/usr/local/bin/temporal-server"]

oci-image/README.md

@@ -0,0 +1,125 @@
+# Wiki Cafe's Temporal OCI Image
+
+This directory contains an OCI image definition for a Temporal server binary with an authorizer plugin enabled.
+
+## Why Not Use the Default Image?
+
+Without a configured `Authorizer`, Temporal defaults to `noopAuthorizer`, which permits all API requests without authentication or access restrictions. This means any client with network access to your Temporal Server can execute any operation, including critical administrative tasks. Such an open configuration is unsuitable for production environments or systems exposed to untrusted networks.
+
+The authorizer plugin enables fine-grained access control based on user roles, groups, and claims from your identity provider. It supports namespace-aware and operation-specific permissions, which allows you to enforce restrictions on UI access, workflow visibility, and API operations.
+
+We developed this image following the documentation for the [Temporal Authorizer plugin](https://docs.temporal.io/self-hosted-guide/security#authorizer-plugin) and examples from the [samples-server/extensibility/authorizer](https://github.com/temporalio/samples-server/tree/main/extensibility/authorizer).
+
+## Integrating with your OIDC Provider
+
+The authorizer evaluates claims issued by your identity provider. Configure your provider to issue claims that map to Temporal namespaces and permissions. How you structure those claims (roles, groups, attributes) is up to you.
+
+### Example: Keycloak client roles
+
+1. Create client-scoped roles that mirror the permissions you plan to grant. For example:
+   ```
+   default:admin
+   default:read
+   default:worker
+   default:write
+   temporal-system:admin
+   temporal-system:read
+   temporal-system:write
+   ```
+2. In the client's scope, add a mapper of type **User Client Role** that collects those roles into a claim (we use `permissions`).
+3. Verify the generated access/ID tokens expose the `permissions` claim:
+   ```json
+   {
+     "permissions": [
+       "temporal-system:admin"
+     ]
+   }
+   ```
+
+The Temporal authorizer configuration maps these claim values (like `temporal-system:admin`) to specific permissions. Providers like Authentik, Okta, or Auth0 can produce similar claims through group mappings, custom scopes, or policy rules.
+
+## Tagging Convention
+
+We tag images based on the version of the Temporal server package and a revision number for changes to the image itself.
+
+The tag format is `X.Y.Z-R`, where:
+- `X.Y.Z` is the version of Temporal server (e.g., `1.29.0`).
+- `R` is a revision number for changes to the image (e.g., `1`, `2`, etc.).
+
+Increment the revision number `R` if the Temporal server version `X.Y.Z` remains the same. If the Temporal server version changes, reset `R` to `1`.
+
+We set the image tag and Temporal version as environment variables before building the image:
+
+```bash
+export GO_VERSION=A.B
+export TEMPORAL_VERSION=X.Y.Z
+export TAG=${TEMPORAL_VERSION}-R
+```
+
+## Development
+
+###  Building the container image
+
+Build the container image for your local platform to test before publishing:
+
+```bash
+docker buildx build \
+  --file Containerfile \
+  --no-cache \
+  --build-arg GO_VERSION=$GO_VERSION \
+  --build-arg TEMPORAL_IMAGE=temporalio/auto-setup:$TEMPORAL_VERSION \
+  --build-arg SOURCE_COMMIT=$(git rev-parse HEAD) \
+  --build-arg BUILD_DATE=$(date -u +'%Y-%m-%dT%H:%M:%SZ') \
+  -t git.coopcloud.tech/wiki-cafe/temporal:latest \
+  -t git.coopcloud.tech/wiki-cafe/temporal:$TAG \
+  --load .
+```
+
+<!-- Not applicable for now.
+ For multi-architecture builds (amd64 and arm64):
+
+```bash
+docker buildx build \
+  --file Containerfile \
+  --platform linux/amd64,linux/arm64 \
+  --no-cache \
+  --build-arg GO_VERSION=$GO_VERSION \
+  --build-arg TEMPORAL_IMAGE=temporalio/auto-setup:$TEMPORAL_VERSION \
+  --build-arg SOURCE_COMMIT=$(git rev-parse HEAD) \
+  --build-arg BUILD_DATE=$(date -u +'%Y-%m-%dT%H:%M:%SZ') \
+  -t git.coopcloud.tech/wiki-cafe/temporal:latest \
+  -t git.coopcloud.tech/wiki-cafe/temporal:$TAG \
+  --load .
+``` -->
+
+<!-- Not applicable now. We will eventually move this to another repo. 
+### Committing, Tagging and Pushing the Release
+
+Commit all changes, tag the release, and push everything to the remote repository.
+
+```bash
+git add -A
+git commit -m "Release $TAG"
+git tag -a "$TAG" -m "Release $TAG"
+git push --atomic origin main "$TAG"
+``` -->
+
+### Publishing the container image
+
+After building and verifying the container image locally, push it to the registry.
+
+Note: Due to registry timeout issues with direct `--push` during build, we push each tag separately rather than using `--push` with buildx.
+
+```bash
+docker push git.coopcloud.tech/wiki-cafe/temporal:$TAG
+docker push git.coopcloud.tech/wiki-cafe/temporal:latest
+```
+
+## Deployment
+
+The custom server binary expects configuration to be mounted at runtime. Set the following environment variables when running the container:
+
+- `TEMPORAL_CONFIG_DIR`: Path to the directory containing Temporal configuration files (must include authorization settings)
+- `TEMPORAL_CONFIG_ENV`: Environment name for config loading (defaults to `development`)
+
+Example authorization configuration should be included in your mounted config to enable claim mapping and role-based access control.