Convert GitHub actions workflows to tangled pipelines and vice versa.
Migrating to the new Tangled knot2 | jola.dev
Tangled is a Github alternative built on atproto. I've previously shown you how to set up the self-hosted repo server, here I go through migrating to knot2.
Spindles
Spindle workflows allow you to write CI/CD pipelines in a simple format. They’re located in the .tangled/workflows directory at the root of your repository, and are defined using YAML.
Embracing ATProto, part 2: Tangled Knots and social coding
You thought Github was a social coding platform? Think again, and get ready to tangle! Built on atproto, tangled allows you to use your Bluesky/atproto identity on a (not quite yet) fully feldged git platform!
Self-hosting and Tangled | jola.dev
Tangled is a Github alternative built on atproto that lets you self-host your own repos and workflows, while still participating in a shared community. Here's how you get set up.
Tangled integration - Railway Central Station
Support deploying from tangled.sh repos, like you can from GitHub (select repo + deploy hooks + pr previews etc). | Get Help with Railway
proposal: ingest repo records #282
`sh.tangled.repo` records are one of the last few records that need atprotation (2-way sync between appview/pds). this one is tricky because we want consistency between knot state, appview state and PDS state. the path forward is described below: - migration to did/rkey syntax universally: in several places, we utilize `did/repo-name` as a globally unique identifier for a repository, we should migrate this to `did/rkey`: * for the tangled appview: this means reworking our ACLs, routers and DB to use `did/rkey` or ATURI as a globally unique identifier for a repo * for knots: this means changing paths on disk to be `did/rkey`, allowing git ops to `host:did/rkey` , updating ACLs, and XRPC endpoints * for spindles: this means updating ACLs and XRPC endpoints - once this is done, we can define ingestion logic for all services in the network to pull sh.tangled.repo records * for the tangled appview, this should create/delete/update a repo pointer record * for knots: this should create-or-ignore/delete-or-ignore/update-or-ignore a repo on disk. migration of repos needs to be thought out here. * for spindles: as above - define edge-case behaviors: * when referring to repos by rkey, it is possible for clever users to create duplicate records with the same repo-name, appview routers must handle this ambiguity with a new interstitial page that offers a redirect, knots must return an error upon push/pull on ambiguous git URLs * the `knot` cli can introduce a command `backfill` or `sync` to bring knot state up to sync with the rest of the world (repos, collaborators, pubkeys, ACLs etc.).