Programming

26579 readers

197 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

UlrikHD@programming.dev

bugsmith@programming.dev

Spyro@programming.dev

Dynamic & resilient git remotes with doink (absolutely-vivid.srht.site)

submitted 1 day ago by absolutely_vivid@programming.dev to c/programming@programming.dev

6 comments fedilink hide all child comments

Hey, I made a thing! It's called doink. Doink gives you dynamic git remotes by using DNS TXT records as pointers.

I wrote a bit about how it works and what it's useful for.

Anyway, do you ever thing about how DNS is a basically a decentralized key-value database? I think about it a lot :)

top 6 comments

sorted by: hot top controversial new old

[–] alex_riv@lemmy.org 1 points 17 hours ago

clever approach. using DNS TXT records as lightweight pointers is a neat way to get indirection without any centralized service.

the DNS-as-key-value-store angle is underrated. you can do some interesting things with SRV and TXT records for service discovery that don't get much attention because everything assumes you have consul or a k8s cluster.

does it handle TTL caching gracefully? that's the usual gotcha with DNS-based dynamic config — if you update the TXT record you might be stale for a while depending on resolver config.

[–] aivoton@sopuli.xyz 1 points 18 hours ago

If you use ssh for the remote you can just add a line to ssh config mapping the remote to whatever. Of course you still have to change the config if things change, but you're not relying on DNS. Used to be the way to handle multiple auths to github when dealing with client repos before they had better organization/enterprise & team support.

[–] thenextguy@lemmy.world 4 points 1 day ago (1 children)

If you have control of the dns server, why do you need the bash script? Just create a CNAME record pointing to the current remote.

[–] absolutely_vivid@programming.dev 3 points 1 day ago

Great question! I considered that, it's what lead me to the idea to use DNS in the first place. The problem I had with that is that the ultimate URL path might change, not just the hostname. What happens if a repo has to move from github.com/org/repo to mycoolforge.net/repo?

But there's also another reason that I realized as I was working out the details of git-remote-helpers: What happens if your remote needs to change protocols? With doink you can swap from http(s) to ftp with an ip address instead of a hostname, or perhaps even some (future) git-over-whatever-p2p-network.

So yeah if you're swapping from a github-style forge to another github-style forge and you don't need the flexibility, you definitely could just CNAME it! And that would probably be more robust, but it would also give you less future flexibility :P

[–] thenextguy@lemmy.world 2 points 1 day ago (1 children)

"Scientific Progress Goes Doink!"

[–] absolutely_vivid@programming.dev 1 points 1 day ago

Yoink! New project logo haha ;P