🚀 v0.11.8 - 18th June 2024

[cinder sentinel]

👋 so, v0.11.7 had some issues - lots of churn in our ci, lots of refactoring work with telemetry draining, etc.
The idea is to try and schedule v0.11.8 as (hopefully 🤞) a stable release to build on, as we plan for v0.12.0.

Earlier we merged https://github.com/dagger/dagger/pull/7660 (woo @stark stag) - this should fix the deadlocks we see both in ci, but also may have a fairly reasonable chance of resolving other collections of phantom hangs we've seen

I think this is the big issue? After merging this, it looks like our ci is honestly in the best state i've ever seen it, testdev passing in under 10 minutes ❤️

i think it makes sense to cut as soon as possible next week

here's our milestone: https://github.com/dagger/dagger/milestone/49

here's our diffs from the last release: https://github.com/dagger/dagger/compare/v0.11.7...main

cc @steep palm @sinful blade @stark stag @deep mirage @placid sandal @shut ermine @solid fjord @woeful pawn

[deep mirage]

I’ll let other share their view in case some other PRs need to merged asap. But after following the thread and the work done in the last 24hrs, I agree with should release asap (early next week).

[steep palm]

Super keen to see v0.11.8 released. I would not recommend merging any v0.12 PRs until we have confirmed that v0.11.8 addressed some of the long standing bugs that we have been chasing for many weeks now. I think that will take at least 3 days of CI runs to be confident.

If we need to catch & fix a few bugs, cut v0.11.9 so that we have an even more stable release before we introduce more change & potential disruption, it would be worth doing that IMO.

As for the v0.12 release, what are your thoughts on starting with v0.12.0-rc.1 ?

[cinder sentinel]

sgtm on v0.12, and making sure we don't merge those prs pre-emptively

i'd rather not do an rc? i remember when we discussed this around v0.10 and whether we should do one

i think in terms of dogfooding, we can better about using the dev-engines, etc, and we should definitely have an internal "use this commit from main to test", but i'm not sure about doing an rc - i don't think it's going to be any more/less stable than a standard release

i think rcs like this will be much more valuable once we start having longer-term support branches/etc, but i don't think we're there yet

is the 18th (tuesday) good for v0.11.8? we can do monday, but essentially that requires that we have pretty much everything in the milestone sorted by eod today, which feels a bit rushed

[steep palm]

yes, 18th (tuesday) sounds most reasonable for v0.11.8

An RC communicates that we are preparing a new final release and invite users to test. While we wouldn't do this for patch releases, considering that this is a new minor, and taking into account the experience with 0.10.0 & 0.11.0, it would be worth doing in my opinion.

The target user for RCs is someone that wants to try new stuff before it's fully ready & is prepared to find issues. A final release signals that it's been taken through the paces and is ready for prime time. Even if it's just us that tests the RCs before cutting a final, our last few minor releases suggest to me that it will be worth the upfront effort.

Also, as we approach 1.0, I worry that we will not have exercised our RC muscle enough and the final 1.0 release will not be as good as it could be.

A group decision sounds good to me.

[sinful blade]

The main question in my mind is the branching strategy, e.g. some options are:

1. Keep tagging rc's off main - not ideal in that main is essentially blocked other than rc-related commits for as long as the rc process takes
2. Make a branch for the rc's - probably better but does require some commits to get committed to both main and the branch, which can involve resolving conflicts in different ways, etc.

Don't need to figure that all out here, that's just what I'd want a clear answer on before we start doing this

[stark stag]

(False alarm I think but recording for papertrail): this test timed out, but that's expected right, since it's not testdev and ran with v0.11.7?: https://github.com/dagger/dagger/actions/runs/9519543841/job/26242956525?pr=7616

[sinful blade]

Yeah probably expected, I think The outer v0.11.7 engine would still have the draining problem

@stark stag is there a known issue with the cloud UI showing spinners for traces even though they appear to be done? seeing that in the attached screen shot but job ran and succeeded: https://github.com/dagger/dagger/actions/runs/9519716157/job/26243505982?pr=7659 Just double checking it's not somehow related to force flushing spans

[stark stag]

https://discord.com/channels/707636530424053791/1249714408746389556 - our timed-out-spans GC job has been clogged for a while, we're working towards a fix. when we hit a timeout in GHA it leads to this state, normally a background job cleans it up but yea, it's clogged

[sinful blade]

awesome, just relieved it's not a "ah shit, here we go again" type situation 😄

[woeful pawn]

@cinder sentinel https://github.com/dagger/dagger/pull/7636 this PR passes but I'm pretty sure it's a breaking change since it drops support for commonJS because graphql-request did, how should I handle this in the release note / do we want to merge it now?

[cinder sentinel]

i would downgrade graphql to the last supported version with commonjs for now

we shouldn't introduce breaking changes for this release

[woeful pawn]

Fine by me, on it

[woeful pawn]

@cinder sentinel I can merge this one after your approval: https://github.com/dagger/dagger/pull/7636

[cinder sentinel]

sgtm

[cinder sentinel]

milestone looks pretty good for tomorrow: https://github.com/dagger/dagger/milestone/49

@sinful blade is the flaky test still around?

@steep palm are we able to have a latest runner for that job? or should we downgrade the test to v0.11.6 if we expect it to fail?

and any thing else that should be on that list?

[sinful blade]

I have not repro'd it locally after many many attempts but presumably it's still happening in CI occasionally since I don't think anything significant has changed

[cinder sentinel]

do we think it's a release blocker? or good to go on without it?

this other one did crop up which seemed suspicious to me - i think we might have regressed something in the python sdk when making otel changes: https://github.com/dagger/dagger/issues/7673

[sinful blade]

I'd say go forward, it isn't happening so often that it's devastating. I don't think we can block releases on "whodunnit" type mysteries like this unless they are really breaking everything

[cinder sentinel]

removing from the milestone then

[steep palm]

yes. we should have it, but I didn't have time to test yet: https://github.com/dagger/dagger.io/pull/3798

I also think that we should call it dev since latest assumes latest stable, not latest dev. On my list!

[cinder sentinel]

sounds good!

[placid sandal]

I'm waiting for 11.8 to be tagged before merging https://github.com/dagger/dagger/pull/7586 -- can you give me a heads up @cinder sentinel @steep palm when we're in the clear? 🙂

[cinder sentinel]

just one pr approval needed before i can start releasing process: https://github.com/dagger/dagger/pull/7616

[cinder sentinel]

hm, maybe some more if anyone has a moment:

• https://github.com/dagger/dagger/pull/7634
• https://github.com/dagger/dagger/pull/7633
  these are ci-related and would help boost my confidence for ongoing releases, etc

[woeful pawn]

I think https://github.com/dagger/dagger/pull/7601 will also be part of the release, if that's okay? Or should I hold it for the next?

[cinder sentinel]

up to you - if there are no breaking changes, makes sense to take it

why does tsx update so much 😢

[steep palm]

I reviewed all outstanding PRs - anything else needed to keep this train going? 🚂

[cinder sentinel]

Nope should be good! I'm just gonna grab lunch, then kick this off

[woeful pawn]

That's a good question I don't have the answer too

[cinder sentinel]

release is currently blocked - looks like sdk tests aren't being picked up by workers

see #infrastructure

cc @steep palm @swift python

[cinder sentinel]

i'm coming up towards the end of my day 👀 if i have to head off, i'll pick up the rest of the sdk release tomorrow / if anyone us-side wants to pick it up

[cinder sentinel]

have to head off soon - i'll pick up the sdk releases tomorrow

if anyone else decides to pick it up before then: this is the step we're currently blocked at: https://github.com/dagger/dagger/blob/main/RELEASING.md#-go-sdk--30mins

[placid sandal]

Safe to merge on main now that the release is tagged? /cc @sinful blade

[cinder sentinel]

Should be good? Your PR doesn't change any SDK code right?

Just in case we need to apply some fixes there

[placid sandal]

Actually it does, it updates the signature of Terminal

I'll hold off until tomorrow

[cinder sentinel]

Sorry, thanks for bearing with ❤️

[placid sandal]

hey no worries! thanks for taking care of the release

Just wanted to double check before making a mess 🫠

[placid sandal]

@cinder sentinel FYI, there's a vulnerability in one of the Go SDK dependencies (#daggernauts message) -- I just created a PR to bump it: https://github.com/dagger/dagger/pull/7695 /cc @stark stag @steep palm

[steep palm]

Since we haven't tagged & released the Go SDK yet, it might make sense to add this the above PR to the release. WDYT @cinder sentinel ?

[cinder sentinel]

Sgtm

[cinder sentinel]

🎉 back now, going to pick up the release again

[cinder sentinel]

@steep palm i'll bump the docs - but first we should update the install scripts on cloudfront

@summer dagger @swift python @sick locust we should be good to bump daggerverse + cloud + playground

bump dagger-for-github PR here: https://github.com/dagger/dagger-for-github/pull/133

Improving PR here: https://github.com/dagger/dagger/pull/7702

[cinder sentinel]

I think this is the only outstanding thing

[steep palm]

Doing it now.

Done.

[cinder sentinel]

redeployed docs 🎉

windows instructions are up to date now 😄 https://docs.dagger.io/quickstart/cli/

🚀 v0.11.8 - 18th June 2024

[shut ermine]

Thank you!

[cinder sentinel]

fyi @placid sandal sorry, i was just looking through the backlog - i think attachable terminal sessions should be good to merge, this release is now tagged, and looks stable enough 🙂

hehe that was quick, guess you had your finger on the button for the last few days 😄

[swift python]

Dagger Cloud CI upgrade: https://github.com/dagger/dagger.io/pull/3802 cc @summer dagger

Daggerverse upgrade: https://github.com/dagger/dagger.io/pull/3803

Playground upgrade: https://github.com/dagger/dagger.io/pull/3804

[swift python]

Getting a bunch of timeouts here, looking into it

[steep palm]

I'm reviewing this PR now. I think there is a Dagger version mismatch between the SDK & the Engine. The other 2 PRs are LGTM.

[swift python]

Which particular job? I'm looking into publish for the API and I don't think thats the case. API's dagger module is v0.11.8 and the engine it is connecting to is 0.11.8 as well. Looking into the logs I see that the dagger CLI used is also v0.11.8

[steep palm]

This should fix it: https://github.com/dagger/dagger.io/pull/3802/commits/93baa54d7f52767315fb8a8da530348faa297c1d

[swift python]

oooo we got mage still running around loose in the building

We should definitely modularize it (cc @summer dagger)

[swift python]

There was an issue with one of the v0.11.8 playground pods. The CLI was throwing an error when connecting to the engine saying "session not implemented". Is this an issue with trying to connect to the engine too quickly? Recyling the pod did the trick

[sinful blade]

That would potentially happen if an old CLI connected to a new engine