#On a branch that adds a [Debug](https://

1 messages · Page 1 of 1 (latest)

ashen tusk
#

👀

#

linter takes the dagger.json version of the python/sdk/runtime module and regenerates it when calling this method

Did not understand that

young elm
#

sorry updated, very badly written:

When I run dagger call go lint, it rebuilds the runtime modules from scratch. During that step, it regenerates internal/dagger/dagger.gen.go using the engine version pinned in each module’s dagger.json. For sdk/python/runtime (and TS) that’s still v0.19.4, so the generated client doesn’t contain my new SDKConfig.Debug() method.

I guess that’s why lint fails, even though my local copy—generated against the branch’s schema—still builds.

ashen tusk
#

Isn't it because you need to generate the Go SDK first?

young elm
#

I did dagger call generate -o .

#

i would've thought everything would have been regenerated no ?

ashen tusk
young elm
#

yes

ashen tusk
#

then yes

#

doesn't look like a linter issue - even if you try to build, it should also fail right?

young elm
ashen tusk
#

<@&946480760016207902>

#

This broke my brain

#

TLDR:

  • Our CI module generates all dagger go runtimes, to lint etc. Like dagger develop but programmatic
  • This generates dagger.gen.go etc.
  • PROBLEM: it generates this from the stable engine that runs the CI. So, if that module requires a new API only available in dev engine, this will generate broken code.
  • As far as I can tell, this has always been the case??? Unclear how we ever managed to pass CI when pushing a change to any dagger module in our repo that requires a not-yet-released core feature
sand ridge
# ashen tusk TLDR: - Our CI module generates all dagger go runtimes, to lint etc. Like `dagg...

As far as I can tell, this has always been the case??? Unclear how we ever managed to pass CI when pushing a change to any dagger module in our repo that requires a not-yet-released core feature
Yeah we have not done that before and can't because of this issue. You gotta release the core feature before it can be used in our CI. It is occasionally annoying like this.

But I don't think there's any way around it within the model of using stable dagger to build dev dagger

prime edge
ashen tusk
#

I knew it @young elm 😁

#

we could wrap it in DinD

young elm
#

if others are ok with DinD, then I can totally do it

ashen tusk
#

would only be for linting modules

young elm
#

Ok, after talking with Solomon, I'll do as you guys --> just ship the core first and then the rest right after

jolly ember
#

@sand ridge didn't we use to build a dev engine on each of our CI workflows up to very recently when we decided to switch back to the latest stable since it apparently didn't make a lot of sense?

#

I recall we had a conversation around that not so long ago

sand ridge
#

Yeah, for this type of situation that only helps if the new feature isn't in the codepath of "build dev engine", because even in the way we used to do things we still had to build the dev engine from stable engine

jolly ember
#

Yeah, correct. Just what I thought

sand ridge
#

I would say the switch was less because it didn't make sense and more that it was too slow to be worth the minor benefits

jolly ember
#

Ok, great. Just wanted to make sure I wasn't hallucinating it 😄

ashen tusk
#

@jolly ember @sand ridge now we do have a special ci-in-ci check to replace the old dev engine stuff

jolly ember
young elm
#

For now, to unlock this PR i'll split it in 2 --> modifying the core, then following your release tomorrow Erik I'll rebase on top and change the SDK runtimes 🙏

#

(to focus on git)