19 Commits

Author SHA1 Message Date
octoturge ecf927aef9 Bump every template's VERSION to publish the git.octoturge.com fix
Provision Coder Templates / build-images (push) Successful in 5s
Provision Coder Templates / provision (push) Successful in 2m13s
The host-gateway change in the previous commit only takes effect on a new
template version - bump every template's VERSION file from 1 to 2 so
coder-templates.yml actually pushes it instead of skipping as "already
pushed". Existing workspaces need a stop/start against the new version to
pick up the updated docker_container host mapping.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YRq8ts9zwge8Rttbuku9FQ
2026-08-28 18:04:51 +02:00
octoturge f377942e90 Add host-gateway mapping for git.octoturge.com in every workspace container
Provision Coder Templates / build-images (push) Successful in 10s
Provision Coder Templates / provision (push) Successful in 54s
install-skills.sh curls git.octoturge.com at workspace startup (coder_script)
to pull this repo's Agent Skills, but the workspace's public DNS answer for
that hostname NAT-hairpins back through the LAN and times out (curl: (28)
after ~147s). code.octoturge.com already has this exact host-gateway
workaround in every template's docker_container.workspace resource; add the
matching entry for git.octoturge.com.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YRq8ts9zwge8Rttbuku9FQ
2026-08-28 18:02:34 +02:00
octoturge 8b3653ee96 Fix provision job crashing on templates already at their current VERSION
Provision Coder Templates / build-images (push) Failing after 23s
Provision Coder Templates / provision (push) Successful in 58s
Run 109 failed: profiles-3d-printing (and the same would've hit every
other already-versioned template) already had a "v1" version from the
previous run, and the pre-check meant to detect that and skip
(coder templates versions list -o json piped through jq) apparently
doesn't match the CLI's actual JSON shape - it never found the
existing version, so the push was attempted anyway and coder rejected
the duplicate name, failing the whole job.

Simpler and more robust: just attempt the push and treat its specific
"A template version with name ... already exists" failure as the skip
signal, instead of trying to predict it from a separate list call.
2026-08-27 12:12:27 +02:00
octoturge fb74669414 Purge apt's downloaded .deb cache in every RUN, not just the package lists
Provision Coder Templates / provision (push) Failing after 42s
Provision Coder Templates / build-images (push) Successful in 16m56s
Splitting the big RUN blocks (previous commit) got several layers under
the registry's per-blob size cap, but a few packages are still huge
enough on their own to fail - libopencv-dev came in at 793MB, Chrome at
1.08GB. Neither of those RUN blocks was clearing
/var/cache/apt/archives, only /var/lib/apt/lists, so each apt install's
downloaded .deb files were sitting in the layer alongside the unpacked
files. Worth trying before reaching for a Cloudflare-side fix.
2026-08-27 11:14:36 +02:00
octoturge 2867db22af Split web image's large RUN blocks into per-layer steps; add per-template VERSION files to skip unchanged reprovisioning
Provision Coder Templates / provision (push) Successful in 1m56s
Provision Coder Templates / build-images (push) Successful in 14m45s
The registry sits behind a reverse proxy that 413s large blob pushes,
so templates/web/Dockerfile's oversized RUN blocks (apt installs,
rustup targets, cargo installs) are broken up so no single layer is
too big to push.

Also adds templates/<name>/VERSION (starting at "1" for all six
templates) and has the provision job's push step look up whether that
version is already pushed before running coder templates push, since
the workflow triggers on any change under templates/** and previously
reprovisioned every template on every push, not just the one that
changed.
2026-08-27 09:32:30 +02:00
octoturge c64987a840 ci: re-declare packages: write for forward compat with gitea#39070
Provision Coder Templates / build-images (push) Successful in 14s
Provision Coder Templates / provision (push) Successful in 1m50s
Currently a no-op given GITEA_TOKEN can't reach the registry at all yet,
but harmless to have in place now so nothing needs to change here once
that fix ships and PACKAGE_REGISTRY_TOKEN can eventually be retired.
2026-08-27 09:21:15 +02:00
octoturge 757a94557b ci: revert to a manual PAT for registry push - GITEA_TOKEN is broken
Provision Coder Templates / provision (push) Successful in 2m0s
Provision Coder Templates / build-images (push) Failing after 8s
secrets.GITEA_TOKEN cannot authenticate to Gitea's container registry in
any currently-shipped version, regardless of the permissions: block or
which account triggers the workflow - confirmed via
go-gitea/gitea#23642 (open since 1.19) and its fix, PR #39070, which is
dated 2026-08-24 and not yet merged. Every run since switching to it has
failed at docker login with a plain "unauthorized". Reverting to a
manually-created PACKAGE_REGISTRY_TOKEN secret (the GITEA_PACKAGE_TOKEN
attempt from before this branch used a reserved-prefix name Gitea
silently refuses to create).
2026-08-27 01:56:30 +02:00
octoturge 268fb97a1c docs: note that GITEA_TOKEN impersonates the pushing account, not the owner
Provision Coder Templates / build-images (push) Failing after 6s
Provision Coder Templates / provision (push) Successful in 2m1s
Documents what we just found the hard way: build-images's docker push
runs as whichever Gitea account authenticated the triggering push
(github.actor), which needs its own package-registry write access -
separate from that account having git push rights to the repo at all.
2026-08-27 01:54:07 +02:00
octoturge 32c71ccaf0 ci: trigger fresh credential prompt after clearing stale akadmin cache 2026-08-27 01:45:58 +02:00
octoturge 9798b522bd ci: use Gitea's built-in GITEA_TOKEN for registry push, drop manual PAT
Provision Coder Templates / build-images (push) Failing after 6s
Provision Coder Templates / provision (push) Has been cancelled
GITEA_PACKAGE_TOKEN was never a creatable secret name (GITEA_ prefix is
reserved), and Gitea Actions' built-in token can be granted registry
write access directly via `permissions: packages: write` (per
https://docs.gitea.com/usage/actions/token-permissions/) - the
"unauthorized: reqPackageAccess" issue noted earlier looks to have been
exactly this: the default restricted token mode denying package write
unless a job explicitly requests it, not an unfixable bug in the token
itself. Drops the manual-PAT requirement entirely - no secret to create
or maintain.
2026-08-27 01:40:07 +02:00
octoturge f27eb23804 ci: rename registry secret to PACKAGE_REGISTRY_TOKEN, fail loudly if unset
GITEA_PACKAGE_TOKEN was never actually creatable - Gitea Actions reserves
the GITEA_ prefix for its own built-in secrets, so Settings > Actions >
Secrets rejects a repo secret by that name. The workflow referenced a
secret that could never exist, so docker login always got an empty
password and failed with a confusing "interactive login from a non TTY
device" error. Renamed to PACKAGE_REGISTRY_TOKEN, and added an explicit
empty-secret check so a future misconfiguration fails with a clear
message instead of that confusing docker error.
2026-08-27 01:37:19 +02:00
octoturge ea4ab76724 ci: run build-images' shell steps under sh, not bash
Provision Coder Templates / build-images (push) Failing after 10s
Provision Coder Templates / provision (push) Successful in 2m0s
docker:27-cli (Alpine) has no bash, only the POSIX /bin/sh (busybox
ash). run: steps default to bash, so both steps in build-images failed
immediately with "exec: bash: executable file not found in $PATH" -
confirmed via the run's log right after the previous checkout fix
landed. Both steps are already plain POSIX shell, so declare shell: sh
as the job default instead of switching interpreters.
2026-08-27 01:31:28 +02:00
octoturge c1bc3566ba ci: replace actions/checkout with a raw git clone in build-images
Provision Coder Templates / build-images (push) Failing after 7s
Provision Coder Templates / provision (push) Successful in 2m0s
actions/checkout is a JS action and needs Node to run inside the job
container. The docker-build runner's job image (docker:27-cli, Alpine,
just the Docker CLI) has no Node, so the step failed immediately with
"exec: node: executable file not found in $PATH" - confirmed via the
run's actual log (build-images failed after 16s on every push since the
image-in-CI switch, including the just-merged duplicate-mount and
if:always() fixes). Alpine has apk/git, so clone directly instead.
2026-08-27 01:26:03 +02:00
octoturge 9482a0a2a7 ci: build every template's image independently, skip only failed ones
Provision Coder Templates / provision (push) Successful in 2m5s
Provision Coder Templates / build-images (push) Failing after 16s
Fixes a regression where the whole provision job (all 6 templates) was
skipped whenever build-web-image failed, since Actions skips a job whose
needs: dependency failed by default. Generalizes the single web-image
build step into a loop over every templates/*/Dockerfile, building and
pushing each independently so one failure doesn't block the rest, and
reports failures via a job output. provision now runs unconditionally
(if: always()) and skips pushing only the specific template(s) whose
image build failed this run, leaving their previous working version in
place instead of pushing one with no matching registry tag.
2026-08-27 01:18:25 +02:00
octoturge 278023e4c2 ci: drop redundant docker.sock mount in build-web-image
First real run of the new job failed at container creation:
"Error response from daemon: Duplicate mount point: /var/run/docker.sock".
The docker-build runner's config.yaml has docker_host: "" (not "-"),
which means act_runner already auto-injects the host socket into job
containers on its own - the workflow's explicit
container.volumes mount for the same path was a second, conflicting
request for it. Just dropping the explicit mount; the runner already
provides it.
2026-08-27 01:12:35 +02:00
octoturge 6de3196faa web: build image in CI, pull it in Terraform instead of building locally
Provision Coder Templates / build-web-image (push) Failing after 17s
Provision Coder Templates / provision (push) Has been skipped
templates/web's docker_image resource used a `build` block, so every
first-use of a new Dockerfile hash triggered a from-scratch build
(including the ~15-20min Rust toolchain compile) right at `terraform
apply` time - i.e. while someone was waiting to create a workspace.

Adds a build-web-image job to coder-templates.yml that builds and pushes
git.octoturge.com/octo-tech/profiles-web:<dockerfile-sha1> to this
instance's container registry, tagged identically to what
docker_image.web now computes and pulls (no build block). provision now
depends on build-web-image so a template never gets pushed pointing at
an image that isn't there yet. Skips the build entirely if that tag's
already in the registry, so an unrelated templates/* change doesn't
pay any cost.

Runs on a new dedicated "docker-build" runner (profiles-web-build),
scoped to just this repo via a repo-level registration token, with
host Docker socket access - deliberately not added to the existing
shared runner-1, which has no such access and stays untouched. Repo is
public, so the pulled image needs no registry auth; the push does, via
a new GITEA_PACKAGE_TOKEN repo secret (write:package scope).

Since CI and this Coder deployment share the same Docker daemon, the
"pull" is normally a same-host cache hit, not a real network pull.

Verified: `terraform validate` passes against the updated
templates/web/main.tf (run directly inside the coder-server container,
which has terraform embedded).
2026-08-27 01:10:58 +02:00
octoturge 730af0a335 cli-setup-wizard: stop parsing tea's config.yml, use tea itself
Provision Coder Templates / provision (push) Successful in 2m4s
DID_GITEA detection and the SSH/GPG key uploads to Gitea were reading
tea's config.yml directly with awk, assuming 2-space indentation and a
plaintext `token:` field. Neither holds: the real format uses 6-space
indentation for fields under each login, and a login done via OAuth
(tea's default flow) has no token field in the file at all - it's held
elsewhere. Confirmed live: a workspace with a genuinely active `tea`
OAuth login was still reporting "not logged in" and skipping the whole
key-setup step because of this.

Replaced with tea's own subcommands, which handle auth internally
regardless of method:
  - detection: `tea whoami`
  - SSH key upload: `tea ssh-keys add`
  - GPG key upload: `tea api -X POST /user/gpg_keys -F armored_public_key=@-`

Verified all three directly against the live account (disposable test
SSH + GPG keys, added then removed) - SSH upload succeeded; the GPG
upload correctly failed for an unrelated, expected reason (Gitea
requires the key's email to match a verified account email, and the
test key used a throwaway address), confirming the request itself is
well-formed.
2026-08-27 00:49:20 +02:00
octoturge d60e44508a cli-setup-wizard: explain why SSH/GPG key setup got skipped
Provision Coder Templates / provision (push) Successful in 2m7s
The SSH/GPG key-generation question only fires when gh/tea are actually
logged in (DID_GITHUB/DID_GITEA), which is correct - but if login was
declined, failed, or never completed, the section was skipped with zero
explanation. From the user's side that looked like a missing feature
rather than an unfinished login.

Confirmed on a live workspace: gh was never installed, and tea was
installed but `tea login add` never actually completed (no
~/.config/tea/config.yml), so the gate correctly stayed closed - the
user just had no way to know why. Now prints a one-line hint (only when
gh or tea is installed at all) pointing at the login command and the
--force re-run.
2026-08-27 00:14:11 +02:00
octoturge 93721b9096 web: install Google Chrome for the Browse Lite extension
Provision Coder Templates / provision (push) Successful in 2m22s
Browse Lite (antfu.browse-lite, kept in the earlier Open VSX audit)
launches an embedded browser preview via a real Chrome/Chromium binary,
which templates/web's image never provided - it failed with "No Chrome
installation found, or no Chrome executable set in the settings".

Ubuntu's own chromium-browser apt package is a snap wrapper and doesn't
work in a container, so this installs Google Chrome's official .deb
instead (amd64 only, matching this repo's single x86_64 Docker host).
Also points browse-lite.chromeExecutable at it explicitly rather than
relying on auto-detection.

Verified the new apt-key/repo/install layer builds cleanly in isolation
on octo-winsrv (google-chrome-stable 152.0.7977.64).
2026-08-26 23:57:51 +02:00
21 changed files with 398 additions and 132 deletions
+156 -9
View File
@@ -2,17 +2,52 @@ name: Provision Coder Templates
# Keeps Coder templates in sync with templates/*/ in this repo:
# - every push to main pushes a new version of each templates/<env>/ dir
# (coder templates push creates it if it doesn't exist yet, so adding a
# new templates/<env>/ directory is enough to provision a new one)
# whose VERSION file names a version not already pushed (coder templates
# push creates the template if it doesn't exist yet, so adding a new
# templates/<env>/ directory - with a VERSION file - is enough to
# provision a new one). This workflow triggers on any change under
# templates/**, not just a specific template's own directory, so VERSION
# is what keeps an edit to one template from generating a no-op new
# version for every other, unchanged template.
# - if a templates/<env>/ directory is removed on main, its template is
# deleted from Coder. `coder templates delete` refuses to delete a
# template that still has active workspaces, so this can't silently
# orphan running workspaces - it just fails loudly and needs a human.
#
# Requires two repo/org secrets (Settings > Actions > Secrets):
# CODER_URL e.g. https://code.octoturge.com
# CODER_SESSION_TOKEN a token from `coder tokens create`, ideally under a
# Requires three repo/org secrets (Settings > Actions > Secrets):
# CODER_URL e.g. https://code.octoturge.com
# CODER_SESSION_TOKEN a token from `coder tokens create`, ideally under a
# dedicated service account rather than a personal one
# PACKAGE_REGISTRY_TOKEN a Gitea access token (user Settings > Applications)
# with write:package scope, for pushing each
# Dockerfile-having template's image to this
# instance's container registry.
#
# Not secrets.GITEA_TOKEN (Gitea Actions' built-in token): as of this
# writing it cannot authenticate to the container registry in any shipped
# Gitea version - `permissions: packages: write` is a no-op because the
# Actions token's package scope isn't wired up server-side yet (open since
# Gitea 1.19: https://github.com/go-gitea/gitea/issues/23642; fix in
# https://github.com/go-gitea/gitea/pull/39070, not yet merged). Every
# attempt fails at docker login with a plain "unauthorized", regardless of
# the permissions: block or which account triggered the workflow. A
# manually-created PAT is the only thing that currently works. Named
# without a GITEA_ prefix because Gitea Actions reserves that prefix for
# its own built-in secrets and rejects creating one with that name.
#
# Any templates/<env>/ that has its own Dockerfile gets its image built and
# pushed here (build-images, on the dedicated "docker-build" runner - see
# templates/web/main.tf for why: that runner is scoped to this repo only and
# has host Docker socket access that the shared runner-1 deliberately
# doesn't). provision then just pulls the tag build-images produced, instead
# of building it itself at `terraform apply` time - keeps a slow toolchain
# compile off of "someone is waiting to create a workspace".
#
# Each template's image is built independently - one Dockerfile failing to
# build doesn't stop the others from building, and provision skips pushing
# only the specific template(s) whose image build failed this run (leaving
# their previous, already-working Coder template version in place) rather
# than skipping every template or pushing one with no matching image.
on:
push:
@@ -23,11 +58,83 @@ on:
workflow_dispatch: {}
jobs:
build-images:
# The docker-build runner's docker_host: "" setting already auto-injects
# /var/run/docker.sock into job containers - an explicit
# container.volumes mount for the same path here fails at container
# creation with "Duplicate mount point: /var/run/docker.sock".
runs-on: docker-build
# Currently a no-op (see the PACKAGE_REGISTRY_TOKEN note above) but
# harmless to declare now - once go-gitea/gitea#39070 ships, GITEA_TOKEN
# will need this to get package write access, so this is one less thing
# to remember when PACKAGE_REGISTRY_TOKEN can eventually be retired.
permissions:
packages: write
outputs:
failed_templates: ${{ steps.build.outputs.failed_templates }}
# docker:27-cli (Alpine) has no bash - only the POSIX /bin/sh (busybox
# ash) - but run: steps default to bash, which fails with "exec: bash:
# executable file not found in $PATH". Both run: steps below are plain
# POSIX shell already, so just run them under sh.
defaults:
run:
shell: sh
steps:
# actions/checkout is a JS action and needs Node in the job container -
# this job runs in docker:27-cli (Alpine, just the Docker CLI) so it has
# no Node, and actions/checkout fails immediately with "exec: node:
# executable file not found in $PATH". Alpine does have apk/git though,
# so clone directly instead.
- name: Checkout
run: |
set -e
apk add --no-cache git
git clone --depth 1 --branch "${{ github.ref_name }}" "${{ github.server_url }}/${{ github.repository }}.git" .
- name: Build and push every template's image (skips a tag that's already in the registry)
id: build
run: |
set -e
echo "${{ secrets.PACKAGE_REGISTRY_TOKEN }}" | docker login git.octoturge.com -u octoturge --password-stdin
FAILED=""
for dockerfile in templates/*/Dockerfile; do
[ -e "$dockerfile" ] || continue
dir="$(dirname "$dockerfile")"
name="$(basename "$dir")"
TAG="$(sha1sum "$dockerfile" | cut -d' ' -f1)"
IMAGE="git.octoturge.com/octo-tech/profiles-${name}:${TAG}"
echo "::group::${name}"
if docker manifest inspect "$IMAGE" >/dev/null 2>&1; then
echo "$IMAGE already in the registry (Dockerfile unchanged), skipping build."
elif docker build -t "$IMAGE" "$dir" && docker push "$IMAGE"; then
echo "Built and pushed $IMAGE"
else
echo "::warning::Failed to build/push $IMAGE - templates/$name will be skipped this run."
FAILED="$FAILED $name"
fi
echo "::endgroup::"
done
echo "failed_templates=${FAILED# }" >> "$GITHUB_OUTPUT"
provision:
# needs: build-images orders this after the image builds (so a fresh
# template push never points at a tag that isn't in the registry yet)
# without making every template's reprovisioning depend on ALL builds
# succeeding - if:always() overrides the default "skip if a dependency
# failed" behavior, since build-images only fails outright on an
# infra-level problem (e.g. registry login); a single template's build
# failure is reported via failed_templates instead and only skips that
# one template below.
needs: build-images
if: always()
runs-on: ubuntu-latest
env:
CODER_URL: ${{ secrets.CODER_URL }}
CODER_SESSION_TOKEN: ${{ secrets.CODER_SESSION_TOKEN }}
FAILED_TEMPLATES: ${{ needs.build-images.outputs.failed_templates }}
steps:
- name: Checkout (full history, needed to detect removed templates)
uses: actions/checkout@v4
@@ -44,10 +151,50 @@ jobs:
run: |
set -e
for dir in templates/*/; do
name="profiles-$(basename "$dir")"
echo "::group::Pushing $name from $dir"
coder templates push "$name" -d "$dir" --yes \
-m "auto-provisioned from ${GITHUB_SHA:0:12}"
name="$(basename "$dir")"
full="profiles-$name"
case " $FAILED_TEMPLATES " in
*" $name "*)
echo "::warning::Skipping $full - its Docker image failed to build this run (see build-images), leaving the previous template version in place."
continue
;;
esac
# templates/<name>/VERSION lets a template opt out of being
# reprovisioned on every push: bump it and coder templates push
# names the new version "v<N>". This is a manual contract, not a
# content hash - editing a template without bumping its VERSION
# means the change won't go out until someone does. paths: on
# this workflow's trigger is templates/** as a whole, so without
# this every template gets a new (identical) version on any push
# under templates/, even ones whose own directory didn't change.
#
# Rather than pre-checking `coder templates versions list` for
# whether v<N> already exists (fragile - depends on its exact
# JSON shape matching what we expect), just attempt the push and
# treat its specific "version already exists" failure as the
# skip signal instead.
version=""
if [ -f "$dir/VERSION" ]; then
version="$(tr -d '[:space:]' < "$dir/VERSION")"
fi
args=(-d "$dir" --yes -m "auto-provisioned from ${GITHUB_SHA:0:12}")
[ -n "$version" ] && args+=(--name "v$version")
echo "::group::Pushing $full from $dir"
if push_output="$(coder templates push "$full" "${args[@]}" 2>&1)"; then
echo "$push_output"
else
push_status=$?
echo "$push_output"
if [ -n "$version" ] && printf '%s' "$push_output" | grep -qF "A template version with name \"v$version\" already exists"; then
echo "Version v$version (templates/$name/VERSION) is already pushed - nothing to do. Bump the VERSION file to push a new one."
else
echo "::endgroup::"
exit "$push_status"
fi
fi
echo "::endgroup::"
done
+1
View File
@@ -0,0 +1 @@
2
+15 -16
View File
@@ -143,12 +143,11 @@ else
fi
fi
fi
TEA_CONFIG="${XDG_CONFIG_HOME:-$HOME/.config}/tea/config.yml"
if command -v tea >/dev/null 2>&1 && [ -f "$TEA_CONFIG" ]; then
TEA_URL="$(awk '/^logins:/{f=1} f && /^ url:/{print $2; exit}' "$TEA_CONFIG")"
TEA_TOKEN="$(awk '/^logins:/{f=1} f && /^ token:/{print $2; exit}' "$TEA_CONFIG")"
[ -n "$TEA_URL" ] && [ -n "$TEA_TOKEN" ] && DID_GITEA=1
fi
# `tea whoami` succeeds regardless of how the login was done (personal
# access token or OAuth) - more reliable than parsing tea's own
# config.yml, whose indentation and fields (no plaintext `token:` at all
# for an OAuth login) vary by auth method.
command -v tea >/dev/null 2>&1 && tea whoami >/dev/null 2>&1 && DID_GITEA=1
# --- SSH + GPG keys for the external git host(s) selected above ---
# Only asks if the user actually set up GitHub and/or Gitea just now -
@@ -186,13 +185,10 @@ if [ "$DID_GITHUB" -eq 1 ] || [ "$DID_GITEA" -eq 1 ]; then
fi
if [ "$DID_GITEA" -eq 1 ]; then
SSH_PUB_JSON="$(sed 's/\\/\\\\/g; s/"/\\"/g' "${SSH_KEY}.pub")"
if curl -fsS -X POST "${TEA_URL%/}/api/v1/user/keys" \
-H "Authorization: token ${TEA_TOKEN}" -H "Content-Type: application/json" \
-d "{\"title\":\"coder-$(hostname)\",\"key\":\"${SSH_PUB_JSON}\"}" >/dev/null 2>&1; then
if tea ssh-keys add "${SSH_KEY}.pub" --title "coder-$(hostname)" >/dev/null 2>&1; then
echo "SSH key added to Gitea."
else
echo "Couldn't add the SSH key to Gitea automatically (may already be added). Add manually at: ${TEA_URL%/}/user/settings/keys"
echo "Couldn't add the SSH key to Gitea automatically (may already be added). Add manually with: tea ssh-keys add ${SSH_KEY}.pub"
fi
fi
@@ -226,17 +222,20 @@ if [ "$DID_GITHUB" -eq 1 ] || [ "$DID_GITEA" -eq 1 ]; then
fi
if [ "$DID_GITEA" -eq 1 ]; then
GPG_ARMORED_JSON="$(gpg --armor --export "$GPG_KEY_ID" | awk '{printf "%s\\n", $0}')"
if curl -fsS -X POST "${TEA_URL%/}/api/v1/user/gpg_keys" \
-H "Authorization: token ${TEA_TOKEN}" -H "Content-Type: application/json" \
-d "{\"armored_public_key\":\"${GPG_ARMORED_JSON}\"}" >/dev/null 2>&1; then
if gpg --armor --export "$GPG_KEY_ID" | tea api -X POST /user/gpg_keys -F armored_public_key=@- >/dev/null 2>&1; then
echo "GPG key added to Gitea."
else
echo "Couldn't add the GPG key to Gitea automatically (may already be added). Add manually at: ${TEA_URL%/}/user/settings/keys"
echo "Couldn't add the GPG key to Gitea automatically (may already be added). Add manually: gpg --armor --export $GPG_KEY_ID | tea api -X POST /user/gpg_keys -F armored_public_key=@-"
fi
fi
fi
fi
elif command -v gh >/dev/null 2>&1 || command -v tea >/dev/null 2>&1; then
# gh and/or tea are installed but neither is actually logged in yet (login
# was declined, failed, or never completed) - say why the key-generation
# question above got skipped instead of just silently not asking.
echo "Skipping SSH/GPG key setup: not logged in to GitHub or Gitea yet."
echo "Log in (gh auth login / tea login add) then re-run: bash /opt/coder/cli-setup-wizard.sh --force"
fi
echo ""
+7
View File
@@ -204,6 +204,13 @@ resource "docker_container" "workspace" {
host = "code.octoturge.com"
ip = "host-gateway"
}
# install-skills.sh curls this at startup to pull the repo's Agent Skills;
# without this the workspace's public DNS answer for git.octoturge.com
# NAT-hairpins back to the LAN and times out (curl: (28)).
host {
host = "git.octoturge.com"
ip = "host-gateway"
}
volumes {
container_path = "/home/coder"
volume_name = docker_volume.home_volume.name
+1
View File
@@ -0,0 +1 @@
2
+15 -16
View File
@@ -143,12 +143,11 @@ else
fi
fi
fi
TEA_CONFIG="${XDG_CONFIG_HOME:-$HOME/.config}/tea/config.yml"
if command -v tea >/dev/null 2>&1 && [ -f "$TEA_CONFIG" ]; then
TEA_URL="$(awk '/^logins:/{f=1} f && /^ url:/{print $2; exit}' "$TEA_CONFIG")"
TEA_TOKEN="$(awk '/^logins:/{f=1} f && /^ token:/{print $2; exit}' "$TEA_CONFIG")"
[ -n "$TEA_URL" ] && [ -n "$TEA_TOKEN" ] && DID_GITEA=1
fi
# `tea whoami` succeeds regardless of how the login was done (personal
# access token or OAuth) - more reliable than parsing tea's own
# config.yml, whose indentation and fields (no plaintext `token:` at all
# for an OAuth login) vary by auth method.
command -v tea >/dev/null 2>&1 && tea whoami >/dev/null 2>&1 && DID_GITEA=1
# --- SSH + GPG keys for the external git host(s) selected above ---
# Only asks if the user actually set up GitHub and/or Gitea just now -
@@ -186,13 +185,10 @@ if [ "$DID_GITHUB" -eq 1 ] || [ "$DID_GITEA" -eq 1 ]; then
fi
if [ "$DID_GITEA" -eq 1 ]; then
SSH_PUB_JSON="$(sed 's/\\/\\\\/g; s/"/\\"/g' "${SSH_KEY}.pub")"
if curl -fsS -X POST "${TEA_URL%/}/api/v1/user/keys" \
-H "Authorization: token ${TEA_TOKEN}" -H "Content-Type: application/json" \
-d "{\"title\":\"coder-$(hostname)\",\"key\":\"${SSH_PUB_JSON}\"}" >/dev/null 2>&1; then
if tea ssh-keys add "${SSH_KEY}.pub" --title "coder-$(hostname)" >/dev/null 2>&1; then
echo "SSH key added to Gitea."
else
echo "Couldn't add the SSH key to Gitea automatically (may already be added). Add manually at: ${TEA_URL%/}/user/settings/keys"
echo "Couldn't add the SSH key to Gitea automatically (may already be added). Add manually with: tea ssh-keys add ${SSH_KEY}.pub"
fi
fi
@@ -226,17 +222,20 @@ if [ "$DID_GITHUB" -eq 1 ] || [ "$DID_GITEA" -eq 1 ]; then
fi
if [ "$DID_GITEA" -eq 1 ]; then
GPG_ARMORED_JSON="$(gpg --armor --export "$GPG_KEY_ID" | awk '{printf "%s\\n", $0}')"
if curl -fsS -X POST "${TEA_URL%/}/api/v1/user/gpg_keys" \
-H "Authorization: token ${TEA_TOKEN}" -H "Content-Type: application/json" \
-d "{\"armored_public_key\":\"${GPG_ARMORED_JSON}\"}" >/dev/null 2>&1; then
if gpg --armor --export "$GPG_KEY_ID" | tea api -X POST /user/gpg_keys -F armored_public_key=@- >/dev/null 2>&1; then
echo "GPG key added to Gitea."
else
echo "Couldn't add the GPG key to Gitea automatically (may already be added). Add manually at: ${TEA_URL%/}/user/settings/keys"
echo "Couldn't add the GPG key to Gitea automatically (may already be added). Add manually: gpg --armor --export $GPG_KEY_ID | tea api -X POST /user/gpg_keys -F armored_public_key=@-"
fi
fi
fi
fi
elif command -v gh >/dev/null 2>&1 || command -v tea >/dev/null 2>&1; then
# gh and/or tea are installed but neither is actually logged in yet (login
# was declined, failed, or never completed) - say why the key-generation
# question above got skipped instead of just silently not asking.
echo "Skipping SSH/GPG key setup: not logged in to GitHub or Gitea yet."
echo "Log in (gh auth login / tea login add) then re-run: bash /opt/coder/cli-setup-wizard.sh --force"
fi
echo ""
+7
View File
@@ -204,6 +204,13 @@ resource "docker_container" "workspace" {
host = "code.octoturge.com"
ip = "host-gateway"
}
# install-skills.sh curls this at startup to pull the repo's Agent Skills;
# without this the workspace's public DNS answer for git.octoturge.com
# NAT-hairpins back to the LAN and times out (curl: (28)).
host {
host = "git.octoturge.com"
ip = "host-gateway"
}
volumes {
container_path = "/home/coder"
volume_name = docker_volume.home_volume.name
+1
View File
@@ -0,0 +1 @@
2
+15 -16
View File
@@ -143,12 +143,11 @@ else
fi
fi
fi
TEA_CONFIG="${XDG_CONFIG_HOME:-$HOME/.config}/tea/config.yml"
if command -v tea >/dev/null 2>&1 && [ -f "$TEA_CONFIG" ]; then
TEA_URL="$(awk '/^logins:/{f=1} f && /^ url:/{print $2; exit}' "$TEA_CONFIG")"
TEA_TOKEN="$(awk '/^logins:/{f=1} f && /^ token:/{print $2; exit}' "$TEA_CONFIG")"
[ -n "$TEA_URL" ] && [ -n "$TEA_TOKEN" ] && DID_GITEA=1
fi
# `tea whoami` succeeds regardless of how the login was done (personal
# access token or OAuth) - more reliable than parsing tea's own
# config.yml, whose indentation and fields (no plaintext `token:` at all
# for an OAuth login) vary by auth method.
command -v tea >/dev/null 2>&1 && tea whoami >/dev/null 2>&1 && DID_GITEA=1
# --- SSH + GPG keys for the external git host(s) selected above ---
# Only asks if the user actually set up GitHub and/or Gitea just now -
@@ -186,13 +185,10 @@ if [ "$DID_GITHUB" -eq 1 ] || [ "$DID_GITEA" -eq 1 ]; then
fi
if [ "$DID_GITEA" -eq 1 ]; then
SSH_PUB_JSON="$(sed 's/\\/\\\\/g; s/"/\\"/g' "${SSH_KEY}.pub")"
if curl -fsS -X POST "${TEA_URL%/}/api/v1/user/keys" \
-H "Authorization: token ${TEA_TOKEN}" -H "Content-Type: application/json" \
-d "{\"title\":\"coder-$(hostname)\",\"key\":\"${SSH_PUB_JSON}\"}" >/dev/null 2>&1; then
if tea ssh-keys add "${SSH_KEY}.pub" --title "coder-$(hostname)" >/dev/null 2>&1; then
echo "SSH key added to Gitea."
else
echo "Couldn't add the SSH key to Gitea automatically (may already be added). Add manually at: ${TEA_URL%/}/user/settings/keys"
echo "Couldn't add the SSH key to Gitea automatically (may already be added). Add manually with: tea ssh-keys add ${SSH_KEY}.pub"
fi
fi
@@ -226,17 +222,20 @@ if [ "$DID_GITHUB" -eq 1 ] || [ "$DID_GITEA" -eq 1 ]; then
fi
if [ "$DID_GITEA" -eq 1 ]; then
GPG_ARMORED_JSON="$(gpg --armor --export "$GPG_KEY_ID" | awk '{printf "%s\\n", $0}')"
if curl -fsS -X POST "${TEA_URL%/}/api/v1/user/gpg_keys" \
-H "Authorization: token ${TEA_TOKEN}" -H "Content-Type: application/json" \
-d "{\"armored_public_key\":\"${GPG_ARMORED_JSON}\"}" >/dev/null 2>&1; then
if gpg --armor --export "$GPG_KEY_ID" | tea api -X POST /user/gpg_keys -F armored_public_key=@- >/dev/null 2>&1; then
echo "GPG key added to Gitea."
else
echo "Couldn't add the GPG key to Gitea automatically (may already be added). Add manually at: ${TEA_URL%/}/user/settings/keys"
echo "Couldn't add the GPG key to Gitea automatically (may already be added). Add manually: gpg --armor --export $GPG_KEY_ID | tea api -X POST /user/gpg_keys -F armored_public_key=@-"
fi
fi
fi
fi
elif command -v gh >/dev/null 2>&1 || command -v tea >/dev/null 2>&1; then
# gh and/or tea are installed but neither is actually logged in yet (login
# was declined, failed, or never completed) - say why the key-generation
# question above got skipped instead of just silently not asking.
echo "Skipping SSH/GPG key setup: not logged in to GitHub or Gitea yet."
echo "Log in (gh auth login / tea login add) then re-run: bash /opt/coder/cli-setup-wizard.sh --force"
fi
echo ""
+7
View File
@@ -204,6 +204,13 @@ resource "docker_container" "workspace" {
host = "code.octoturge.com"
ip = "host-gateway"
}
# install-skills.sh curls this at startup to pull the repo's Agent Skills;
# without this the workspace's public DNS answer for git.octoturge.com
# NAT-hairpins back to the LAN and times out (curl: (28)).
host {
host = "git.octoturge.com"
ip = "host-gateway"
}
volumes {
container_path = "/home/coder"
volume_name = docker_volume.home_volume.name
+1
View File
@@ -0,0 +1 @@
2
+15 -16
View File
@@ -143,12 +143,11 @@ else
fi
fi
fi
TEA_CONFIG="${XDG_CONFIG_HOME:-$HOME/.config}/tea/config.yml"
if command -v tea >/dev/null 2>&1 && [ -f "$TEA_CONFIG" ]; then
TEA_URL="$(awk '/^logins:/{f=1} f && /^ url:/{print $2; exit}' "$TEA_CONFIG")"
TEA_TOKEN="$(awk '/^logins:/{f=1} f && /^ token:/{print $2; exit}' "$TEA_CONFIG")"
[ -n "$TEA_URL" ] && [ -n "$TEA_TOKEN" ] && DID_GITEA=1
fi
# `tea whoami` succeeds regardless of how the login was done (personal
# access token or OAuth) - more reliable than parsing tea's own
# config.yml, whose indentation and fields (no plaintext `token:` at all
# for an OAuth login) vary by auth method.
command -v tea >/dev/null 2>&1 && tea whoami >/dev/null 2>&1 && DID_GITEA=1
# --- SSH + GPG keys for the external git host(s) selected above ---
# Only asks if the user actually set up GitHub and/or Gitea just now -
@@ -186,13 +185,10 @@ if [ "$DID_GITHUB" -eq 1 ] || [ "$DID_GITEA" -eq 1 ]; then
fi
if [ "$DID_GITEA" -eq 1 ]; then
SSH_PUB_JSON="$(sed 's/\\/\\\\/g; s/"/\\"/g' "${SSH_KEY}.pub")"
if curl -fsS -X POST "${TEA_URL%/}/api/v1/user/keys" \
-H "Authorization: token ${TEA_TOKEN}" -H "Content-Type: application/json" \
-d "{\"title\":\"coder-$(hostname)\",\"key\":\"${SSH_PUB_JSON}\"}" >/dev/null 2>&1; then
if tea ssh-keys add "${SSH_KEY}.pub" --title "coder-$(hostname)" >/dev/null 2>&1; then
echo "SSH key added to Gitea."
else
echo "Couldn't add the SSH key to Gitea automatically (may already be added). Add manually at: ${TEA_URL%/}/user/settings/keys"
echo "Couldn't add the SSH key to Gitea automatically (may already be added). Add manually with: tea ssh-keys add ${SSH_KEY}.pub"
fi
fi
@@ -226,17 +222,20 @@ if [ "$DID_GITHUB" -eq 1 ] || [ "$DID_GITEA" -eq 1 ]; then
fi
if [ "$DID_GITEA" -eq 1 ]; then
GPG_ARMORED_JSON="$(gpg --armor --export "$GPG_KEY_ID" | awk '{printf "%s\\n", $0}')"
if curl -fsS -X POST "${TEA_URL%/}/api/v1/user/gpg_keys" \
-H "Authorization: token ${TEA_TOKEN}" -H "Content-Type: application/json" \
-d "{\"armored_public_key\":\"${GPG_ARMORED_JSON}\"}" >/dev/null 2>&1; then
if gpg --armor --export "$GPG_KEY_ID" | tea api -X POST /user/gpg_keys -F armored_public_key=@- >/dev/null 2>&1; then
echo "GPG key added to Gitea."
else
echo "Couldn't add the GPG key to Gitea automatically (may already be added). Add manually at: ${TEA_URL%/}/user/settings/keys"
echo "Couldn't add the GPG key to Gitea automatically (may already be added). Add manually: gpg --armor --export $GPG_KEY_ID | tea api -X POST /user/gpg_keys -F armored_public_key=@-"
fi
fi
fi
fi
elif command -v gh >/dev/null 2>&1 || command -v tea >/dev/null 2>&1; then
# gh and/or tea are installed but neither is actually logged in yet (login
# was declined, failed, or never completed) - say why the key-generation
# question above got skipped instead of just silently not asking.
echo "Skipping SSH/GPG key setup: not logged in to GitHub or Gitea yet."
echo "Log in (gh auth login / tea login add) then re-run: bash /opt/coder/cli-setup-wizard.sh --force"
fi
echo ""
+7
View File
@@ -204,6 +204,13 @@ resource "docker_container" "workspace" {
host = "code.octoturge.com"
ip = "host-gateway"
}
# install-skills.sh curls this at startup to pull the repo's Agent Skills;
# without this the workspace's public DNS answer for git.octoturge.com
# NAT-hairpins back to the LAN and times out (curl: (28)).
host {
host = "git.octoturge.com"
ip = "host-gateway"
}
volumes {
container_path = "/home/coder"
volume_name = docker_volume.home_volume.name
+1
View File
@@ -0,0 +1 @@
2
+15 -16
View File
@@ -143,12 +143,11 @@ else
fi
fi
fi
TEA_CONFIG="${XDG_CONFIG_HOME:-$HOME/.config}/tea/config.yml"
if command -v tea >/dev/null 2>&1 && [ -f "$TEA_CONFIG" ]; then
TEA_URL="$(awk '/^logins:/{f=1} f && /^ url:/{print $2; exit}' "$TEA_CONFIG")"
TEA_TOKEN="$(awk '/^logins:/{f=1} f && /^ token:/{print $2; exit}' "$TEA_CONFIG")"
[ -n "$TEA_URL" ] && [ -n "$TEA_TOKEN" ] && DID_GITEA=1
fi
# `tea whoami` succeeds regardless of how the login was done (personal
# access token or OAuth) - more reliable than parsing tea's own
# config.yml, whose indentation and fields (no plaintext `token:` at all
# for an OAuth login) vary by auth method.
command -v tea >/dev/null 2>&1 && tea whoami >/dev/null 2>&1 && DID_GITEA=1
# --- SSH + GPG keys for the external git host(s) selected above ---
# Only asks if the user actually set up GitHub and/or Gitea just now -
@@ -186,13 +185,10 @@ if [ "$DID_GITHUB" -eq 1 ] || [ "$DID_GITEA" -eq 1 ]; then
fi
if [ "$DID_GITEA" -eq 1 ]; then
SSH_PUB_JSON="$(sed 's/\\/\\\\/g; s/"/\\"/g' "${SSH_KEY}.pub")"
if curl -fsS -X POST "${TEA_URL%/}/api/v1/user/keys" \
-H "Authorization: token ${TEA_TOKEN}" -H "Content-Type: application/json" \
-d "{\"title\":\"coder-$(hostname)\",\"key\":\"${SSH_PUB_JSON}\"}" >/dev/null 2>&1; then
if tea ssh-keys add "${SSH_KEY}.pub" --title "coder-$(hostname)" >/dev/null 2>&1; then
echo "SSH key added to Gitea."
else
echo "Couldn't add the SSH key to Gitea automatically (may already be added). Add manually at: ${TEA_URL%/}/user/settings/keys"
echo "Couldn't add the SSH key to Gitea automatically (may already be added). Add manually with: tea ssh-keys add ${SSH_KEY}.pub"
fi
fi
@@ -226,17 +222,20 @@ if [ "$DID_GITHUB" -eq 1 ] || [ "$DID_GITEA" -eq 1 ]; then
fi
if [ "$DID_GITEA" -eq 1 ]; then
GPG_ARMORED_JSON="$(gpg --armor --export "$GPG_KEY_ID" | awk '{printf "%s\\n", $0}')"
if curl -fsS -X POST "${TEA_URL%/}/api/v1/user/gpg_keys" \
-H "Authorization: token ${TEA_TOKEN}" -H "Content-Type: application/json" \
-d "{\"armored_public_key\":\"${GPG_ARMORED_JSON}\"}" >/dev/null 2>&1; then
if gpg --armor --export "$GPG_KEY_ID" | tea api -X POST /user/gpg_keys -F armored_public_key=@- >/dev/null 2>&1; then
echo "GPG key added to Gitea."
else
echo "Couldn't add the GPG key to Gitea automatically (may already be added). Add manually at: ${TEA_URL%/}/user/settings/keys"
echo "Couldn't add the GPG key to Gitea automatically (may already be added). Add manually: gpg --armor --export $GPG_KEY_ID | tea api -X POST /user/gpg_keys -F armored_public_key=@-"
fi
fi
fi
fi
elif command -v gh >/dev/null 2>&1 || command -v tea >/dev/null 2>&1; then
# gh and/or tea are installed but neither is actually logged in yet (login
# was declined, failed, or never completed) - say why the key-generation
# question above got skipped instead of just silently not asking.
echo "Skipping SSH/GPG key setup: not logged in to GitHub or Gitea yet."
echo "Log in (gh auth login / tea login add) then re-run: bash /opt/coder/cli-setup-wizard.sh --force"
fi
echo ""
+7
View File
@@ -204,6 +204,13 @@ resource "docker_container" "workspace" {
host = "code.octoturge.com"
ip = "host-gateway"
}
# install-skills.sh curls this at startup to pull the repo's Agent Skills;
# without this the workspace's public DNS answer for git.octoturge.com
# NAT-hairpins back to the LAN and times out (curl: (28)).
host {
host = "git.octoturge.com"
ip = "host-gateway"
}
volumes {
container_path = "/home/coder"
volume_name = docker_volume.home_volume.name
+92 -17
View File
@@ -11,34 +11,87 @@ ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y --no-install-recommends \
locales sudo ca-certificates gnupg curl wget \
&& locale-gen en_US.UTF-8 \
&& rm -rf /var/lib/apt/lists/*
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/*
ENV LANG=en_US.UTF-8 \
LANGUAGE=en_US:en \
LC_ALL=en_US.UTF-8
# Google Chrome (stable), for the Browse Lite VS Code extension's embedded
# browser preview. Ubuntu's own `chromium-browser` apt package is just a
# snap wrapper and doesn't work in a container (no snapd) - Google's own
# .deb is the reliable way to get a real Chrome binary here. amd64 only
# (Google doesn't publish a Chrome .deb for arm64), which matches this
# repo's single x86_64 Docker host.
RUN curl -fsSL https://dl.google.com/linux/linux_signing_key.pub \
| gpg --dearmor -o /usr/share/keyrings/google-chrome.gpg \
&& echo "deb [arch=amd64 signed-by=/usr/share/keyrings/google-chrome.gpg] http://dl.google.com/linux/chrome/deb/ stable main" \
> /etc/apt/sources.list.d/google-chrome.list \
&& apt-get update && apt-get install -y google-chrome-stable \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/*
# Core build toolchain, crypto/DB headers, Tauri 2 / WebKit GUI prerequisites,
# X11 dev libs, DB CLI clients, Python + OpenCV, protobuf compiler.
#
# Split into several RUN steps (rather than one big apt-get install) so no
# single resulting layer is too large to push to the registry - it sits
# behind a reverse proxy with a request body size cap, and a couple of these
# packages (llvm, libopencv-dev, libwebkit2gtk-4.1-dev) are individually
# large enough to blow past it if lumped together with everything else.
RUN apt-get update && apt-get install -y --no-install-recommends \
build-essential pkg-config cmake \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/*
RUN apt-get update && apt-get install -y --no-install-recommends \
clang llvm \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/*
RUN apt-get update && apt-get install -y --no-install-recommends \
build-essential pkg-config cmake clang llvm \
git git-lfs jq unzip tar file htop tree tmux zsh openssh-client \
&& git lfs install --system \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/*
RUN apt-get update && apt-get install -y --no-install-recommends \
libssl-dev libpq-dev libsqlite3-dev \
postgresql-client redis-tools sqlite3 \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/*
RUN apt-get update && apt-get install -y --no-install-recommends \
libwebkit2gtk-4.1-dev libayatana-appindicator3-dev librsvg2-dev libxdo-dev \
libgtk-3-dev libsoup-3.0-dev \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/*
RUN apt-get update && apt-get install -y --no-install-recommends \
libx11-dev libxext-dev libxrender-dev libxtst-dev libxi-dev \
postgresql-client redis-tools sqlite3 \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/*
RUN apt-get update && apt-get install -y --no-install-recommends \
python3 python3-pip python3-venv python3-dev \
libopencv-dev \
protobuf-compiler \
&& git lfs install --system \
&& rm -rf /var/lib/apt/lists/*
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/*
RUN apt-get update && apt-get install -y --no-install-recommends \
libopencv-dev \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/*
# Node.js LTS (22.x) plus npm/pnpm/yarn as root so global bins land on the
# system PATH for every user.
RUN curl -fsSL https://deb.nodesource.com/setup_22.x | bash - \
&& apt-get install -y --no-install-recommends nodejs \
&& npm install -g pnpm yarn \
&& rm -rf /var/lib/apt/lists/*
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* /var/cache/apt/archives/*
RUN npm install -g pnpm yarn
# Global Python prototyping packages: CV, ONNX runtime, CPU-only torch wheel.
# Ubuntu 24.04's system Python is PEP 668 externally-managed; this is a
@@ -48,9 +101,14 @@ RUN curl -fsSL https://deb.nodesource.com/setup_22.x | bash - \
# file (dpkg-installed, not pip-installed), so `pip install --upgrade pip`
# fails trying to uninstall it in place - and it's unneeded anyway, the
# packages below install fine under the stock version.
#
# Each package gets its own RUN/layer for the same reverse-proxy body-size
# reason as the apt-get split above - torch's CPU wheel and opencv-python's
# wheel are each large enough on their own to be worth isolating.
RUN python3 -m pip install --break-system-packages --no-cache-dir numpy
RUN python3 -m pip install --break-system-packages --no-cache-dir opencv-python-headless
RUN python3 -m pip install --break-system-packages --no-cache-dir onnxruntime
RUN python3 -m pip install --break-system-packages --no-cache-dir \
numpy opencv-python-headless onnxruntime \
&& python3 -m pip install --break-system-packages --no-cache-dir \
torch --index-url https://download.pytorch.org/whl/cpu
# Standard non-root dev user with passwordless sudo. Ubuntu 24.04's base
@@ -75,15 +133,32 @@ WORKDIR /home/coder
# Rust via rustup: stable toolchain, rust-analyzer/clippy/rustfmt/rust-src,
# native + musl targets for x86_64/aarch64, and cargo helper utilities.
#
# Split into one RUN per target/tool (rather than one big chained command) so
# no single layer is too large to push to the registry, for the same
# reverse-proxy body-size reason as the apt-get split above - the base
# toolchain and each additional target's std library are each sizeable, and
# `cargo install` leaves a build/registry cache behind that needs clearing
# inside its own RUN, or it would just bloat that same layer instead.
RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y \
--default-toolchain stable --profile default \
&& rustup component add rustfmt clippy rust-analyzer rust-src \
&& rustup target add \
x86_64-unknown-linux-gnu \
x86_64-unknown-linux-musl \
aarch64-unknown-linux-gnu \
aarch64-unknown-linux-musl \
&& cargo install --locked cargo-watch cargo-edit cross bacon
&& rm -rf "$RUSTUP_HOME"/tmp "$RUSTUP_HOME"/downloads
RUN rustup component add rustfmt clippy rust-analyzer rust-src
RUN rustup target add x86_64-unknown-linux-gnu
RUN rustup target add x86_64-unknown-linux-musl
RUN rustup target add aarch64-unknown-linux-gnu
RUN rustup target add aarch64-unknown-linux-musl
RUN cargo install --locked cargo-watch \
&& rm -rf "$CARGO_HOME"/registry "$CARGO_HOME"/git
RUN cargo install --locked cargo-edit \
&& rm -rf "$CARGO_HOME"/registry "$CARGO_HOME"/git
RUN cargo install --locked cross \
&& rm -rf "$CARGO_HOME"/registry "$CARGO_HOME"/git
RUN cargo install --locked bacon \
&& rm -rf "$CARGO_HOME"/registry "$CARGO_HOME"/git
# Bun: global runtime for the ElysiaJS backend and fast scripting.
RUN curl -fsSL https://bun.sh/install | bash
+1
View File
@@ -0,0 +1 @@
2
+15 -16
View File
@@ -143,12 +143,11 @@ else
fi
fi
fi
TEA_CONFIG="${XDG_CONFIG_HOME:-$HOME/.config}/tea/config.yml"
if command -v tea >/dev/null 2>&1 && [ -f "$TEA_CONFIG" ]; then
TEA_URL="$(awk '/^logins:/{f=1} f && /^ url:/{print $2; exit}' "$TEA_CONFIG")"
TEA_TOKEN="$(awk '/^logins:/{f=1} f && /^ token:/{print $2; exit}' "$TEA_CONFIG")"
[ -n "$TEA_URL" ] && [ -n "$TEA_TOKEN" ] && DID_GITEA=1
fi
# `tea whoami` succeeds regardless of how the login was done (personal
# access token or OAuth) - more reliable than parsing tea's own
# config.yml, whose indentation and fields (no plaintext `token:` at all
# for an OAuth login) vary by auth method.
command -v tea >/dev/null 2>&1 && tea whoami >/dev/null 2>&1 && DID_GITEA=1
# --- SSH + GPG keys for the external git host(s) selected above ---
# Only asks if the user actually set up GitHub and/or Gitea just now -
@@ -186,13 +185,10 @@ if [ "$DID_GITHUB" -eq 1 ] || [ "$DID_GITEA" -eq 1 ]; then
fi
if [ "$DID_GITEA" -eq 1 ]; then
SSH_PUB_JSON="$(sed 's/\\/\\\\/g; s/"/\\"/g' "${SSH_KEY}.pub")"
if curl -fsS -X POST "${TEA_URL%/}/api/v1/user/keys" \
-H "Authorization: token ${TEA_TOKEN}" -H "Content-Type: application/json" \
-d "{\"title\":\"coder-$(hostname)\",\"key\":\"${SSH_PUB_JSON}\"}" >/dev/null 2>&1; then
if tea ssh-keys add "${SSH_KEY}.pub" --title "coder-$(hostname)" >/dev/null 2>&1; then
echo "SSH key added to Gitea."
else
echo "Couldn't add the SSH key to Gitea automatically (may already be added). Add manually at: ${TEA_URL%/}/user/settings/keys"
echo "Couldn't add the SSH key to Gitea automatically (may already be added). Add manually with: tea ssh-keys add ${SSH_KEY}.pub"
fi
fi
@@ -226,17 +222,20 @@ if [ "$DID_GITHUB" -eq 1 ] || [ "$DID_GITEA" -eq 1 ]; then
fi
if [ "$DID_GITEA" -eq 1 ]; then
GPG_ARMORED_JSON="$(gpg --armor --export "$GPG_KEY_ID" | awk '{printf "%s\\n", $0}')"
if curl -fsS -X POST "${TEA_URL%/}/api/v1/user/gpg_keys" \
-H "Authorization: token ${TEA_TOKEN}" -H "Content-Type: application/json" \
-d "{\"armored_public_key\":\"${GPG_ARMORED_JSON}\"}" >/dev/null 2>&1; then
if gpg --armor --export "$GPG_KEY_ID" | tea api -X POST /user/gpg_keys -F armored_public_key=@- >/dev/null 2>&1; then
echo "GPG key added to Gitea."
else
echo "Couldn't add the GPG key to Gitea automatically (may already be added). Add manually at: ${TEA_URL%/}/user/settings/keys"
echo "Couldn't add the GPG key to Gitea automatically (may already be added). Add manually: gpg --armor --export $GPG_KEY_ID | tea api -X POST /user/gpg_keys -F armored_public_key=@-"
fi
fi
fi
fi
elif command -v gh >/dev/null 2>&1 || command -v tea >/dev/null 2>&1; then
# gh and/or tea are installed but neither is actually logged in yet (login
# was declined, failed, or never completed) - say why the key-generation
# question above got skipped instead of just silently not asking.
echo "Skipping SSH/GPG key setup: not logged in to GitHub or Gitea yet."
echo "Log in (gh auth login / tea login add) then re-run: bash /opt/coder/cli-setup-wizard.sh --force"
fi
echo ""
+18 -9
View File
@@ -193,16 +193,18 @@ resource "docker_volume" "home_volume" {
}
}
# Builds the full Web Applications toolchain (Rust/Tauri 2, Bun/Node/pnpm,
# Python CV/ONNX, DB clients - see ./Dockerfile) from this template's own
# directory, so no external registry push is required. The tag embeds the
# Dockerfile's hash so a Dockerfile edit forces a rebuild on next apply/push,
# while an unchanged Dockerfile reuses the cached image.
# Pulls the full Web Applications toolchain (Rust/Tauri 2, Bun/Node/pnpm,
# Python CV/ONNX, DB clients - see ./Dockerfile) instead of building it here.
# The image is built and pushed by .gitea/workflows/coder-templates.yml's
# build-web-image job, tagged with the same Dockerfile hash this resource
# computes - so a Dockerfile edit always resolves to the matching image, and
# an unchanged Dockerfile resolves to one already built (CI skips rebuilding
# it, and this pull is normally a same-host cache hit rather than a real
# network pull, since CI and this Coder deployment share one Docker daemon).
# Moves the ~15-20min Rust toolchain compile off of "someone is waiting to
# create a workspace" and onto CI, where it runs once per Dockerfile change.
resource "docker_image" "web" {
name = "coder-profiles-web:${filesha1("${path.module}/Dockerfile")}"
build {
context = path.module
}
name = "git.octoturge.com/octo-tech/profiles-web:${filesha1("${path.module}/Dockerfile")}"
keep_locally = true
}
@@ -224,6 +226,13 @@ resource "docker_container" "workspace" {
host = "code.octoturge.com"
ip = "host-gateway"
}
# install-skills.sh curls this at startup to pull the repo's Agent Skills;
# without this the workspace's public DNS answer for git.octoturge.com
# NAT-hairpins back to the LAN and times out (curl: (28)).
host {
host = "git.octoturge.com"
ip = "host-gateway"
}
volumes {
container_path = "/home/coder"
volume_name = docker_volume.home_volume.name
File diff suppressed because one or more lines are too long