This is an example on how to set up building a multi-architecture docker image using the new Swift Static Linux SDK introduced along with Swift 6.0.
  • Shell 56%
  • Swift 33.6%
  • Dockerfile 10.4%
Find a file Use this template
Benedek Kozma 8474d97fe3
All checks were successful
ci/woodpecker/push/pr-checks Pipeline was successful
Use builder image from codeberg.org
2026-05-14 09:58:40 +02:00
.vscode Add yaml extension to recommendations 2026-01-26 23:55:22 +01:00
.woodpecker Make image name lowercase 2026-04-29 10:53:36 +02:00
scripts Switch to regular Swift image for scripts, switch to Musl allocator for docker build 2026-04-25 23:43:10 +02:00
Sources/ExampleApp Don't depend on Foundation 2026-01-26 21:00:10 +01:00
.dockerignore Don't push custom VSCode launch configs, cleanup Dockerignore 2024-10-01 19:35:10 +00:00
.editorconfig Use GHA reporter for SwiftFormat workflow 2024-12-04 16:26:29 +01:00
.gitignore Simplify vscode gitignore 2026-04-22 14:36:30 +02:00
.swiftformat Split swiftformat rules into multiple lines 2026-05-12 18:53:34 +02:00
Dockerfile Use builder image from codeberg.org 2026-05-14 09:58:40 +02:00
Package.resolved Update swiftformat to 0.60.1 2026-04-06 11:46:37 +02:00
Package.swift Use treatAllWarnings Swift setting 2026-04-12 12:19:40 +02:00
README.md Remove resolved TODO 2026-01-27 00:03:38 +01:00
UNLICENSE.txt Initial commit 2024-09-19 18:32:01 +02:00

Description

This is an example on how to set up building a multi-architecture docker image using the new Swift Static Linux SDK introduced along with Swift 6.0.

TimeZone support

Supporting different time zones requires the tzdata package. By default this template is using an empty container as the base, the recommended base for only installing a couple smaller packages is alpine. This supports both passing the TZ environment variable and mounting /etc/localtime to set the desired default for classes like DateFormatter.

- FROM scratch AS release
+ FROM alpine AS release
+ RUN apk add --no-cache tzdata

Locale support

As of Swift 6.0.1, Locale.current is hardcoded to be en_001 on Linux. Manually passing a Locale instance to everything that uses it seems to be the only solution for using a custom Locale currently.