Tilt is great but it doesn’t solve the problem you’re asking about. This project more directly addresses that. Fundamentally the problem is that you want to maintain the lifecycle of several services during an ephemeral ci run and tear them down when you are done. As you mentioned it gets unwieldy and annoying to try to run all of these on a single machine and doubly so when you have a lot of services/containers. Kubedock is more like what you are looking for, it translates compose calls to Kube equivalents and each service in the compose file is it’s one kube pod with its own lifecycle. It should be possible under that to do what you are saying, spawn multiple docker composes from a single run.
It is worth noting that Kubedock has some really annoying limitations, part of it is that it’s one person the other part is that some concepts don’t translate to kube very well. So make sure that whatever you will be doing fits into those constraints before you try it
With a single Tilt file combined with a docker compose file, almost all of the infrastructure you need is configured on a local machine. It also supports running kubernetes (most of the docs are around this), but you do not necessarily need to it it.My goto when I have more then 2 docker containers/services I want to keep changing code for. Some teams I work with usually have 20 such containers for local dev.
And yes, you can even nest Tilt files and even write normal python if you want to mix things up.
Shortened commit SHAs are actually not supported by Actions; if you try, you get
"Unable to resolve action `actions/checkout@11bd719`, the provided ref `11bd719` is the shortened version of a commit SHA, which is not supported. Please use the full commit SHA `11bd71901bbe5b1630ceea73d27597364c9af683` instead."
What if the repository has a tag called 11bd719? Does Git/GitHub forbid creation of this tag if a commit exists with that prefix?
What if a Git commit is created that matches an existing tag? Does Git have a procedure to make a new one? e.g. imagine I pregenerate a few million 8 character tags and wait for a collision
btw: Even if you specify the full commit SHA, this can still be attacked; there have been pre-image attacks against Git commit hashes in the past. At least for older versions of Git, the algorithm was Sha1. Maybe that’s changed but an attacker could always construct a malicious repository with intentionally weak hashes with the intent of later swapping one of them. (But at that point they may as well just push the malicious code in the first place.)
What is the attack exactly? Only full commit SHAs are valid to reference a commit by SHA. GitHub disallows tags and branch names that could collide with a full commit SHA. There is never any collision between commit SHAs and tags.
I think the hypothetical attack is to create a tag with the shortened commit SHA pointing at malicious code, and if someone accidentally puts that instead of the full commit SHA, maybe Github will serve them that malicious tag instead of throwing the error. It sounds like that could work if Github doesn't block a tag/branch colliding with a shortened commit SHA. I'd guess they probably do though?
So you would need to specifically write an action referencing an invalid short SHA, which would not work and the action would fail, and then wait for an attacker to push an action with that tag name, and then run your action which has thus far been failing because of the invalid reference?
You'd push the tag at the same time you push the commit. If anyone tries to reference your action and accidentally copies the shortened commit SHA instead of the full commit SHA, they'll reference the malicious tag instead. They'd never see it fail, they'd just silently pick up the malicious tag. But again I'm guessing Github will block that shortened commit SHA as a tag and this wouldn't actually work.
How could they? They can't block every 8 character tag. And you can push the tag before you push the commit. (You know which short sha to impersonate because you can see it locally.)
Whilst Git will be default abbreviate commits to 7 characters, that's merely a default; `core.abbrev` can be set to any number to change the default display. Git will also accept any length abbreviated hashes as long as they're unique in the repo.
It's still SHA-1 by the way, but they included counter-cryptanalysis to reject objects that appear to be one side of a collision using known techniques.
In Ideas That Created the Future [1], a curated and edited set of influential computer science papers, the Leibniz contribution is "The True Method" [2], which I read more or less as "if we could formalize everything, we could use mathematical methods to find answers to all questions".
In the collection of papers, it's picked because of its ideas later formalized in Boolean logic, and logic programming in general.
Just as a note, the GitHub CLI doesn't use bubbletea itself right now, though it does use other charm libraries such as lipgloss and glamour. That said, it's quite likely that at some point we will use huh for our prompting library, which does use bubbletea.
reply