🍩 Doughnut Reader 🍩

chmaynard

26 comments

12 days ago

Tangentially:

> [The RSL is] implemented in gittuf using a custom git namespace. The RSL is stored under refs/gittuf/reference-state-log and the policy metadata is stored under refs/gittuf/policy.

I'm glad to see more systems making use of git ref namespaces, which I think is an underused aspect of git for extending it. Other examples include git-notes [1], and Gerrit's various uses, such as user-facing push points, where the virtual ref "refs/for/branchname" receives commits for review that are destined for branchname, "refs/changes" for storing review data, and NoteDB [2] for storing project and user configuration.

[1] https://git-scm.com/docs/git-notes

[2] https://gerrit-review.googlesource.com/Documentation/note-db...

AceJohnny2

11 days ago

For fun, https://aur.archlinux.org is a single git repository with each package represented as their own namespace.

An mirror for the `aur.git` repository can be found on Github.

https://github.com/archlinux/aur

Foxboron

11 days ago

Aur's a bit different and more traditional, because each package is its own branch, so in the usual `refs/heads/` namespace.

AceJohnny2

11 days ago

> how do we actually know that that pull request has gone through all the checks

gerrit flags all reviews and checks into git notes, which can be downloaded and displayed with a little bit of configuration: https://tylercipriani.com/blog/2022/11/19/git-notes-gits-coo...

This doesn't prevent an admin from cheating and editing the notes manually, but it's a good audit trail if you trust the "forge".

3r7j6qzi9jvnve

11 days ago

> This doesn't prevent an admin from cheating and editing the notes manually, but it's a good audit trail if you trust the "forge".

If one of the values of Git as a DVCS is that you don't need to trust the forge, this seems like it removes one of the core features of git to me.

maccard

11 days ago

People trust the forge all the time; if someone wants to mess with github (say, feed a different repo for everyone except developers using whatever it is they usually interact with the git with (ssh or their IP or whatever), it'd take a while to notice -- if they do that for existing releases archives distros might notice but for a new tag? I'll bet no-one sees it)

From a pure git perspective, notes are normal objects so if everyone fetches the notes regularly they'll notice if they're tempered with just like regular commits iirc. I think you can add notes after the fact but not modify what's there?

evgpbfhnr

11 days ago

Kinda off-topic, but:

> During the Q&A an attendee asked about Kubernetes CI. The audience member said that CI for the project cost "between $100,000 and $200,000 a month"

wtf?! That's a crazy amount of money. At 10,000 PRs a month, that's $10 to $20 per PR(!!)

arp242

11 days ago

Said audience member here. "The Kubernetes project" includes a bit more than just https://github.com/kubernetes/kubernetes, but yes that's accurate.

Here's our GCP spend for the past month: https://imgur.com/a/VVJTSKx. Note that does not include a separate AWS cluster that we are migrating jobs too.

A large chunk of this comes from the nature of distributed tests. We need to reproduce the environment, spin up compute, etc. We do have a large problem with flaky tests on the project as well. Whether that's timeouts, memory/cpu consumption creep over time, loads of other things. We talk about how one day we'd like to get to the granulairty of being able to go to a SIG and say, "this flaky test of yours is costing the project $x in retries. Please dedicate some resources to fix it".

How we distribute the artifacts is a whole different conversation. The container world is unique in that voluntary mirrors are not as possible as with linux packages and other binaries.

If this space interests you please join us at either [SIG K8s Infra](https://github.com/kubernetes/community/tree/master/sig-k8s-...) or [SIG Testing](https://github.com/kubernetes/community/blob/master/sig-test...)!

eddiezane

11 days ago

Looking at one random PR there are about 15 jobs running. One of these ran for 40 minutes. Assuming every job starts a new virtual machine that would be 10 hours of CI time. If they use very beefy machines, we can probably somehow justify this cost.

zufallsheld

11 days ago

how much should it cost per PR, in your head, and why?

fragmede

11 days ago

Assuming a PR is using 1 hour of compute time for CI related tasks, i expect it to take around 1 hour of compute cost. Is there any service that would realistically cost $10-20 per hour of used compute for CI related tasks?

xboxnolifes

10 days ago

I think gitops is the culprit. Around 2017-2018, everything was git centric and that was the best practice. With some sane process, you can definitely bring down that price ridiculously.

I have seen in lot of organisations, every push triggers a build. That is wasted compute.

debarshri

11 days ago

Every push should trigger a build. This should not cost a significant amount of real money, especially not compared to the salary of the developer waiting for the build.

pjc50

11 days ago

Why should every push trigger a build?

mindwok

11 days ago

Because why not? There is no reason to filter/abstain from builds given the second statement. Especially if it has the potential to save time for the developer, whose time is going to cost significant more then the build ever will

ffsm8

11 days ago

Because they're spending up to $200,000 every month on it. That's why not.

I don't think I've ever seen the "developer time is worth more!" true-ism being uncritically repeated than here. They can easily hire over 12 full-time devs for this money.

arp242

11 days ago

given the second statement.

You're still ignoring it. They've got an issue in their CI, it's not that they're triggering it to often. It's because each build costs way too much. Though we technically don't know that either, as the attendee didn't specify how many builds they did, technically. (At least I didn't see it in TFA)

It was also explicitly stated that the goal was to have the Dev run the build locally and sign the commit with the build status so they could skip CI on the server and save cost there. Considering that context, I believe that the Dev time = money argument is justified.

ffsm8

11 days ago

[deleted]

10 days ago

[dead]

KLAUSGREY

10 days ago

Not a fan of shoving more functionality into a tool, that doesn't officially support it, to solve a problem that the tool isn't meant to solve.

throwaway984393

11 days ago

[deleted]

11 days ago

[flagged]

DZAIN13

11 days ago

[flagged]

hiwelep

11 days ago

Someone should create an hn summary extension so that those are inserted under the link instead of having them in the comments.

gostsamo

11 days ago

that isn't a summary. the ad for wizlynx isn't in the link

fragmede

11 days ago

[flagged]

ayushghosh22

11 days ago