<samueldr>
well, also kinda thought that inkscape would rasterize the font
<samueldr>
or uh, vectorize
<samueldr>
(since I locally have the font, it looks right)
<gchristensen>
aah
<samueldr>
and since all my computers are synchronized, fonts included... I'm not the best one to see the issue
<gchristensen>
:D
<gchristensen>
deploying ...
<samueldr>
if only there was a simple way to build some kind of test environment, maybe virtual, with a limited set of controled packages and features to test things...
<timokau[m]>
That sounds like you intend to eventuall deprecate the comments api, is that true? I like being able to interact with ofBorg without a GUI.
orivej has joined #nixos-borg
<LnL>
it's really noisy and something like the checks also makes the results much clearer
<timokau[m]>
But then how can I trigger a bulid via email and how will I be notified if it succeeds/fails?
<timokau[m]>
Success notification is not *that* important if we have `bulid-then-merge`
<timokau[m]>
My ideal interface would be just like the current one but with only one comment per command.
<gchristensen>
timokau[m]: just ... thoughts ... there. good to know some people really like it :)
orivej has quit [Ping timeout: 268 seconds]
<gchristensen>
it would be cool if I could kick off / ban users until they upgrade
<gchristensen>
thanuk you gleber_ for upgrading! I think rbvermaa's builder will go away soon, ping globin :)
<gchristensen>
hmmmm LnL I I think the BuildResult could use some adjusting to make the states make more sense
<gchristensen>
for example, on a merge failure maybe we shouldn't even have a attempted_attrs / skipped_attrs
<LnL>
you mean like an enum?
<gchristensen>
yeah
<LnL>
I didn't need it, but serde has an option to inline enums IIRC
<LnL>
#[serde(untagged)]
<gchristensen>
hmm that could make it an easier migration
<LnL>
alternatively we could do something like tag each 'version'
<gchristensen>
oh yeah
<LnL>
but I'm not sure if you can define a default tag to migrate the first time
<samueldr>
(I thought about using something similar for the backports tooling)
<gchristensen>
github is not suitable for storing state
<gchristensen>
but I would be happy with using this as a marker to find the comment to update later :)
<infinisil>
Except if you use a repo for it, then you have transactional updates even :)
<samueldr>
definitely not, but a light representation where failing isn't an issue it could do
<gchristensen>
so my thought is have a central store of what the comment should be and erase it / rewrite it each time
<samueldr>
diffing is hard, so always rewriting is probably better
<LnL>
gchristensen: :o
<gchristensen>
I know I know :|
<gchristensen>
elbow surgery apparently changes you
<samueldr>
they removed the bit that's harshly against state
<samueldr>
probably next to the funny bone
<gchristensen>
lol
<gchristensen>
there is another idea
<gchristensen>
which is comment once with a link to an external dashboard
<gchristensen>
which loads all the data it needs from the logs db
<samueldr>
that's probably better, and I think github has support for linking without comments
<gchristensen>
you think so?
<infinisil>
Stupid idea: Have a github repo with an Issue for every nixpkgs PR which contains all kinds of info. Link to the PR, such that it gets shown in the github comment history
<infinisil>
Better link to the issue from the PR. Would be a bit too uneventful though
<infinisil>
(and then it's just the same as a dashboard)
<gchristensen>
well the dashboard also has streaming log input :)
<gchristensen>
output*
<samueldr>
though I feel the comments are also a worthy thing to keep around, it's an end-user notification (in case you were thinking about moving it all away)
<samueldr>
well, unless the new github thing for CI has better things
<{^_^}>
[ofborg] @grahamc pushed 3 commits to tagged-comments: https://git.io/fNQIo
<gchristensen>
fundamentally they're just like statuses r
<gchristensen>
which makes it hard because a build failure is an "X"
<samueldr>
(while a transition into failure should be an X)
<LnL>
that machine specifically seems to spike to 100% from time to time
jtojnar has joined #nixos-borg
<gchristensen>
it is a builder building :)
<gchristensen>
LnL:
<LnL>
oh, and the others are only infra/evaluators?
<gchristensen>
eya
<LnL>
ok, everything's fine then :D
<gchristensen>
:D
<LnL>
also, the untagged serialisation logic looks sane
<gchristensen>
ooh!
<LnL>
not sure if the behaviour of ambiguous enums is well defined, but that shouldn't really matter
<gchristensen>
should we do an untagged union of the old version, vs. new version, and then a tagged union for v2 / v3?
<LnL>
seems to take the first one
<gchristensen>
I'm thinking I might create a spot bidder thing with buildkite which automatically adds more evaluators using spot instances on Packet, every 15 minutes
<gchristensen>
the evals would be faster than the hetzner cloud machine, and it might be a bit cheaper
<LnL>
don't think that's necessary but we could, makes it easier for potential other things (eg. non rust) to handle the message versions
<gchristensen>
however, the obvious #1 burning thing to solve is multiple core-N machines.
<gchristensen>
nixops' inability to handle multiple nixpkgs revisions stresses me out