sillsdev / sillsdev/langtechdepot

Merge the two sites: serve the instructions from depot.langtech.cloud

Open
#14 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Python
Stars
0
Forks
2
Avg merge
4d 21h
Merged PRs (30d)
2

Description

The end state we designed for: one hostname, so the user never notices they crossed between two systems mid-install.

The recipe is already written out at the bottom of server/Caddyfile.example. In short:

  1. Publish the built tree (the _site that .github/workflows/pages.yml assembles — docs/ plus a downloads/ folder) to /srv/langtechdepot-site on the server.
  2. Swap the Caddy catch-all for a file_server, keeping /signup, /register, /request and /healthz proxied to register.py.
  3. Set SITE_URL=https://depot.langtech.cloud in register.env.
  4. Set DEPOT = '' and SIGNUP = '/signup' in docs/assets/site.js, so the site's links to the form become same-origin and stop colliding with the site's own front page.

Nothing else in the site changes: links are relative and the Linux curl command rewrites itself from window.location, so it starts pointing at depot.langtech.cloud on its own.

Two things to decide when we do it:

  • How the built tree gets to the box. Right now GitHub Actions is the only thing that builds the zip. Either it grows a deploy step (rsync over SSH, which means a deploy key on the server), or someone runs the four build commands by hand on the box. The second is fine at our rate of change and adds no secrets.
  • Whether GitHub Pages keeps running as a mirror. Cheap to leave up, and it is the fallback if the California box is unreachable — which for some of our users is not hypothetical. If it stays up the two copies must not drift, so either the Pages build stays the source of truth, or Pages becomes a redirect.

Do #12 first. #13 overlaps: if we take the custom-domain route there, this becomes optional rather than necessary.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with server/Caddyfile.example, .github/workflows/pages.yml, register.env, and docs/assets/site.js; review #12 and #13 before choosing an approach. The work is done when depot.langtech.cloud serves the built docs and downloads, the listed paths proxy to register.py, SITE_URL and same-origin links are set, and the deployment or Pages-mirror decision is settled.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, python
Domain
cloud, devops, infrastructure
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.