#✨ v0.12.1 - 18th July 2024

1 messages · Page 1 of 1 (latest)

magic lake
#

If this is urgent, we should do the release asap - however, the milestone is kinda large, and so we should decide, and determine what stuff we can move into the next one

#

cc @quiet echo @tribal trail @potent tide @rough ridge @storm vessel @forest vector

quiet echo
magic lake
#

✨ v0.12.1

#

as far as i can tell, it's only alacritty based stuff (and maybe ghostty, though i think that's more edge casey, since it's so in-development, and not widely used)

#

i'm convinced it's urgent enough to release again this week on thursday, but i think it's okay to leave till then

quiet echo
magic lake
#

✨ v0.12.1 - 18th July 2024

potent tide
storm vessel
#

The golang module wasn't able to run after release because of an outdated go version. @magic lake, @potent tide, does it make sense for the Go runtime to check the version in go.mod and pull a corresponding base image? That would have fixed the issue.

potent tide
storm vessel
#

Yeah, started in 1.21. Golang module was in 1.20.

potent tide
storm vessel
magic lake
magic lake
#

The parser is all a go library

#

The parser can only parse the versions on or below the version it was compiled with

#

I think there's an issue in the next milestone about this on the top of my head

#

The best we can really do is keep go up to date on the recent release (at least until we do something more extensive)

magic lake
#

would appreciate any spare hands on it, if anyone's managed to reproduce this locally, that would be chefskiss

#

speaking of releases? are we still aiming for tomorrow? the big fix currently in is the cleanup of dagger login to always be able to click the link

potent tide
tribal trail
#

Gonna merge https://github.com/dagger/dagger/pull/7804 in a few, doing some last minute testing to see if a performance optimization actually makes any difference.

It's a significant enough change that I'd cautiously classify it as mildly risky, but nothing too fundamental and adds enough test coverage that I feel good about still going forward with a release tomorrow rather than letting it bake.

magic lake
#

Unless something large changes, how do folks feel about holding until #1263140175144288328 are understood? Or should we go ahead? I guess TUI fixes and 7804 are good reasons to go tomorrow

tribal trail
magic lake
#

Heads up I'm also off on Friday (and maybe Monday, yet to decide, happy to have someone else run this one as well)

magic lake
#

We definitely should shift some things in the milestones, like context dirs, which feel unlikely to make it for 0.12.1

#

Will make a call tomorrow morning, if I do go for it, itll be sometime around midday UK time 🎉

tribal trail
potent tide
#

Or just skipping draining, or having a 10s timeout, or [...] - just a band-aid until the rework, which I'd like to prioritize instead of trying to debug the current thing

magic lake
#

What is this not the most fun and enjoyable bug ever 😛

#

Telemetry draining bug number 348 🙂

potent tide
copper drum
potent tide
tribal trail
#

Makes sense to me! Like you said, not worth intensely fighting something we can refactor away soon enough

magic lake
tribal trail
tribal trail
tribal trail
magic lake
quiet echo
#

I can help with the former but not the latter 🙂

magic lake
#

hm, additionally, something is very wrong with our testdev jobs 🤔 the docker daemon is not running

#

might be just a fluke, let's see

magic lake
magic lake
ionic mortar
magic lake
#

thanks 🙏 absolutely huge kudos for all the help in the last couple days 😄

ionic mortar
#

There appears to be some issues with mounting the secret with credentials, checking now

#

We are definitely reaching some issue when trying to pull the image, I see that the credentials are actually present and seem to be valid. I think its related to a restart loop that is happening with the main runners, they are failing in the init script and it is causing to constantly repull the same images. We are probably going over the rate limit even for authenticated users. Its 200 pulls per 6 hour period, and this has been looping for quite a while. I'll fix the main runners now

image.png
magic lake
ionic mortar
magic lake
#

thank you thank you 🎉

magic lake
#

i have to head off a little earlier than normal today, so don't want to be trying to rush it

magic lake
#

regardless, i'm headed off in about 10 mins, so not really able to do it - can pick up on tuesday when i'm back

#

but that then breaks the clickable link in alacritty 😛

tribal trail
potent tide
#

I'd say keep the change; imo it's better to skip Cloud for version, login etc. - if we want analytics or something, we can add that separately, but they seem like more noise than signal in Cloud, and we had multiple requests to not send them to Cloud

#

(Also we can always go back on that if we want)

tribal trail
tribal trail
tribal trail
#

Fixed that problem that was causing failures on main ^. Still getting flakes on main of course but double checking everything is a known flake before proceeding

#

All good ✅

#

Hmmm CLI publish failed because the v0.12.1 changelog wasn't present... Following RELEASING.md that's actually what the instructions result in. But I think we had an implicit assumption of including the PR that adds the next version changelog PR in tag.

Will fix RELEASING.md after all this, but in meantime I will delete+re-tag. I'm not sure yet if the engine image publishes will be happy when the publish jobs re-run, will see what happens. Worst case I may need to manually delete some tags in the registry.

quiet echo
tribal trail
# quiet echo Would it be useful to have integration tests for the CLI publish? I started taki...

We have something of a dry-run publish; I wouldn't mind it being fleshed out more. But this specific case is highly specific to a "real" publish since it's looking for a file .changes/v0.12.1.md, which is only going to exist during the actual publish.

I'm not seeing much of a way to really catch this specific scenario until it happens. I think what's most important is that when it happens we can safely re-tag and re-publish without creating any inconsistent state and/or requiring any manual effort.

#

Okay the engine image + CLI publish succeed on the new run. So that's actually a good sign so far; when the unexpected happens it's easily recoverable with minimal manual effort. I'll do extra double checks this time around to confirm 100%, but so far so good.

We did hit the problem with permissions on the automated bump engine version PR again: #infrastructure message

I'm guessing we just worked around with manual effort during v0.12.0? We need to fix that after this release is done; adding to list.

#

Oh yeah I just saw the message below the one I linked, was just manually worked around during v0.12: #infrastructure message Will do the same for the moment

tribal trail
#

@potent tide hitting a bunch of cases of the jobs succeeding but marked as failed in dagger cloud only due to "we never saw this span complete" - I know we've seen that before, just checking it's tracked and/or expected to be fixed by the draining changes in v0.12.1

quiet echo
#

@tribal trail would any of the issues encountered in 0.12.0 and 0.12.1 release, possibly be remediated by running the goreleaser publish process locally with dagger call, instead of in a GHA job?

#

It feels kind of weird to me to automate that stuff in CI - maybe if there was nothing else to do by hand, but since there are so many local steps anyway... feels unnecessarily brittle to me. maybe I'm wrong

#

(ie. it's not like you can just git tag, push and go home anyway. So is it worth the extra complication to do one part in CI, and another part locally)

tribal trail
quiet echo
#

To be clear I'm talking about running the existing "daggerized goreleaser" pipeline, only locally instead of from CI

#

(and yeah also what you said, with lots of low hanging fruits we can pick along the way without even removing goreleaser - just daggerizing it more efficiently)

#

Also I discovered that goreleaser pro (which we already pay for) has a goreleaser release --prepare command that lets you prepare the release and validate everything without publishing , then actualy publish separately. I don't think we take advantage of that currently, but might be easier to do locally

--> https://goreleaser.com/cmd/goreleaser_publish/

I guess if it only does the glorified go build, it doesn't de-risk that much

tribal trail
# quiet echo To be clear I'm talking about running the existing "daggerized goreleaser" pipel...

Oh I see, yeah we have taken baby steps in that direction. E.g. when I had to manually create the bump engine PR I just ran two dagger calls. But there's a million little things left in terms of automating and consolidating.

I think a good goal would be to encapsulate the entire release into as few dagger calls as possible. Then it could run locally or in CI equivalently and it wouldn't even matter where it's happening.

The only somewhat annoying part of "local" that would remain is getting all the various keys+secrets. But with a 1password module that could also be fully daggerized

#

(pretty sure that module already exists actually? have a memory of it)

quiet echo
tribal trail
potent tide
tribal trail
potent tide
#

the happy one is the only one I can find in GHA, and the reruns didn't even rerun it

#

sorry, clarification: the happy one is the one linked from the successful GHA job

#

and the sad one is the one linked from the checks

tribal trail
#

I did open up a draft PR at first actually and then had to push more commits

potent tide
#

@old sigil would be nice to have git metadata on the trace page for cases like this - it's hard to tell why/where a trace came from

tribal trail
#

Oh, I wonder if the GHA checks UI was showing me the trace from the draft PR still even after I updated it?

#

Either way, separate issue, that PR is good. Just can't self-ship-it 🙂

potent tide
#

maybe? it's possible that its run got interrupted by the push. but I don't know why it would then be showing up on this commit. unless it's the same commit?

#

was it commit deadbeef => change from draft to ready => deadbeef? or was there a push?

#

maybe changing from draft to ready also interrupts for some reason? like from having another trigger on the workflows

tribal trail
tribal trail
potent tide
#

if that's the case, it's possible that Cloud timing out the original trace clobbered the happy one, since it's the same commit, and that happens on a 5 min delay

potent tide
tribal trail
#

Merged it, moving onto Go SDK once main CI is done

old sigil
potent tide
old sigil
#

it will take you to the group for sure, like the branch + commit combo

#

as for the workflow run, I guess it's metadata blocked by the GHA control plane work, as that will add some new labels to pick up from GitHub, which means recreating the view

tribal trail
#

Okay SDKs+Helm chart are all good to go

#

@burnt yoke @ionic mortar @forest vector @twin kernel pinging as instructed to update

  • Playground
  • Daggerverse
  • Dagger Cloud

No breaking changes this time, so no time pressure.

#

So good to go pending updates to cloud infra 🎉 . Gonna go work on the fixes in the improve releasing PR

rustic karma
tribal trail
ionic mortar
tribal trail