1.0 dogfood 🧵

[eager linden]

<@&785926252749651978>

@last valve @reef mason how hard would it be to setup a special dagger org to run on engines from a specific commit? Specifically: a commit on the workspace branch, soon to be tagged as 1.0.0-beta1

I would like to dogfood it on native CI - especially for module repos, because the new workspace config can get us green CI (right now those repos all are red in native ci, because the module being developed is the module being loaded -> wrong)

[last valve]

very easy. Go ahead and create the org and we can set everything up tomorrow morning 🙏

[eager linden]

nice thanks. And what about repo access? The repos we need are in the dagger github org.. so currently they show up in the dagger org in dagger cloud

[last valve]

I see..yeah.. that's not really supported in the model now. I thought you were going to trigger the checks from a fork

[eager linden]

Oh, well if it needs to be from a fork, then we can do that

[last valve]

yep, that'd be way easier

[eager linden]

OK. Then I guess we could just switch my own personal org

And I'll do the forks there

[last valve]

you can map multiple GH orgs to differente dagger cloud orgs, but not repos

[eager linden]

Is it even possible for a separate dagger cloud org to access some of my github forks?

[last valve]

yes, we added this recently

[eager linden]

Oh but to be clear: I would remove those repos from dagger.cloud/dagger

(I don't need the same repo to show up in 2 dagger cloud orgs)

[last valve]

I'm confused now.

What I'm proposing to do is to have a dagger fork in any GH org you like and then map that org+repo to whatever dagger cloud org you need

the only restriction is that one GH repo can only be mapped to one DC org

[eager linden]

Yeah I'm trying to choose between 2 options:

• Option 1: I fork the repos, then those forks are mapped to the new DC org
• Option 2: I don't fork the repos, and I just map the original repos to the new DC org

If option 2 is possible, I prefer it 🙂 I don't need those repos to stay in the main DC org (they're red anyway)

[last valve]

oh yeah, you can do 2 but you won't be able to map the dagger repo if you need it

since that's already mapped to the dagger DC org

[eager linden]

right. That's fine

[last valve]

👍

ok, go for 2 then

[eager linden]

dagger/dagger can wait until we're ready to upgrade the dagger org to 1.0.0-beta

[last valve]

you set everything up in the git sources tab https://dagger.cloud/dagger/settings?tab=Git Sources

[eager linden]

Thank you!

I'll send you a dagger cloud org name + list of repos

Oh. I guess I can just setup everything

and just the dagger cloud org

[last valve]

yep, just send us the dagger-cloud org so we make sure native-ci is good there

create it as individual and send the name so I can bump it to team internal so you don't get charged

[last valve]

it's basically going to chargebee and change the plan there

the changes propagate automatically

[last valve]

just moved this to the internal team plan @eager linden

[eager linden]

@reef mason @last valve just a gentle ping about upgrading that org to the latest commit on workspace branch 🙏

[reef mason]

On it

Have you published an image somewhere?

[eager linden]

@real stone can you go over every repo currently linked as a git source to the dagger-dogfood org, make sure it's a repo fora dagger module (eg dagger/go), create a local branch "migrate-1.0", run dagger migrate -y and commit the output? Then report back on the result in a compact list format

[real stone]

I’m on it. I’ll first identify the git sources attached to dagger-dogfood, then clone/check each module repo, run dagger migrate -y on codex/migrate-1.0, commit any migration output, and report the compact status list here.

❌ Turn failed before completion.

💻 🌎

[eager linden]

no, I don't know what is implied. Marcos just said "it's easy" 😅

[real stone]

Workspace migrate PRs
Opened dagger/dagger#13213 for workspace migrate polish. Updated and force-pushed module migration branches to match fixed migrate output, then opened PRs for PsScriptAnalyzer#1, biomejs#1, eslint#8, go#12, go-sdk#1, helm#1, jest#22, node#1, prettier#8, pytest#12, sdk-sdk#1, setup#4, shellcheck#1, and vitest#12. python-sdk/typescript-sdk had no migration diff.

[reef mason]

No worries, I'll set it up!

[eager linden]

<@&1506565370385793125>: I forgot an important detail. You need tod do this using a build of the workspace branch of dagger

[real stone]

Update: cloned the 19 selected repos from dagger-dogfood. 16 have a root dagger.json; bun, dang-sdk, and mochajs do not look like Dagger module repos on their default branch, so I’ll skip/report those unless something else turns up. Workspace build is still running and is building from 992e1a48.

💻

[eager linden]

thanks! I think we're ready to tag that commit as 1.0.0-beta1 if you want to use that for building & tagging the image

that way it will feel less like a special case

ideally we will cut a real pre-release from that tay today

[reef mason]

The way we are dogfooding/testing releases is using using the tag from main before publishing any tags or making any changes. I was thinking of publishing an image at a separate registry first and if that testing goes well we can cut the pre-release?

[eager linden]

yeah sounds goood

[real stone]

Got it. I’ll use a local Dagger build from the workspace branch for dagger migrate -y, and if 1.0.0-beta1 gets tagged while I’m working I’ll treat that as the target version instead of making this depend on an anonymous commit. I’m picking the migration work back up now.

💻

[reef mason]

Changes is being deployed!

Done!

[eager linden]

how's the migration going? CI is ready for you

[real stone]

Migration is done locally for the module repos. I built Dagger from workspace commit 992e1a48fdab, ran dagger migrate -y with the local workspace engine, and committed results on codex/migrate-1.0.

I’m going to push the migrated branches now so CI can pick them up, then I’ll post the compact repo list.

💻

[eager linden]

what does the the migration result look like?

[real stone]

Shape of the migration result:

• Most repos only add two files: .dagger/config.toml and .dagger/migration-report.md (~16 lines total).
• The new config is basically an empty workspace config:

# Dagger workspace configuration

[modules]

• The report says the root dagger.json is still valid, but implicit root-module loading no longer works. Scripts need dagger -m . ... instead of plain dagger ....
• Some repos with local test fixture modules also migrate those fixtures. Example jest deletes tests/log_output_toolchain_local/dagger.json and replaces it with tests/log_output_toolchain_local/.dagger/config.toml that points back to the repo module with legacy-default-path = true. Same pattern in pytest, setup, and vitest.
• python-sdk and typescript-sdk produced no diff because they already had workspace config.

So this is mostly additive workspace metadata plus reports, with fixture dagger.json files converted where present.

💻

[eager linden]

publish an html report with links to each branch

@real stone

[eager linden]

@real stone hello? do it

[real stone]

Published the HTML report here:

https://dx-51f50c5ff62b1b0f5312.exe.xyz/a/H3xMi1fJE_pHzpBonRlxkjJ1D96rbiC3/html/

It has branch + commit links for every pushed codex/migrate-1.0 branch, plus the no-change/skipped/failed repos and the dagger.io --force note.

💻 📝

[eager linden]

Can you add the full diff, rendered nicely, as an extra column?

[real stone]

Done. I republished the same report URL with a new Full Diff column. Each pushed branch row has a collapsible rendered diff with colored add/delete/hunk lines.

https://dx-51f50c5ff62b1b0f5312.exe.xyz/a/H3xMi1fJE_pHzpBonRlxkjJ1D96rbiC3/html/

💻

[eager linden]

no cute "expand" thing. I want the whole thing expanded

[real stone]

Done. The report now shows the full rendered diffs expanded inline, with no expand/collapse controls. Same URL:

https://dx-51f50c5ff62b1b0f5312.exe.xyz/a/H3xMi1fJE_pHzpBonRlxkjJ1D96rbiC3/html/

💻

[eager linden]

Two things surprise me:

1. The superfluous "# Dagger module configuration\n# bla blabla\n# hey let's keep writing stuff\n# the user loves to read stuff, let's get really verbose" -> I never suggested that. Got ai-slopped in

2. dagger migrate on a SDK-only module was supposed to install the corresponding SDK in the parent workspace. eg. a module with "sdk":{"source":"go"} should have triggered the staged installation of github.com/dagger/go-sdk in the workspace. But that didn't happen.

Can you investigate the root cause of both in the workspace branch? NO EDITS YET

[real stone]

Investigation complete. No edits made.

1. Verbose config comments: root cause is initialWorkspaceConfig in core/schema/workspace_config.go. Migration parent plans seed new parent configs with that exact starter template in core/schema/workspace_migrate_parent.go:109, so migration is reusing the workspace init template instead of emitting a minimal migration config.

2. SDK install behavior: the SDK install path works for mapped plain SDK modules. biomejs had sdk.source = "typescript" and did get [modules.typescript-sdk] source = "github.com/dagger/typescript-sdk". The dogfood repos that did not get SDK installs mostly use sdk.source = "dang"; dang is explicitly unmapped today. core/sdk/workspace_module.go maps go/python/typescript/java/php/elixir, and core/sdk/loader_test.go has a testcase named dang has no workspace module.

Related edge: if a repo already has .dagger/config.toml, migrate returns empty immediately at core/schema/workspace_migrate.go:50-57, so it does not scan legacy dagger.json files under that workspace yet.

Focused tests passed:

• go test ./core/sdk -run 'TestWorkspaceModuleForRuntime|TestParseSDKName'
• go test ./core/schema -run TestWorkspaceMigrationParentPlans

[eager linden]

dump

[real stone]

Dump for turn 1507499555497971874:
https://dx-51f50c5ff62b1b0f5312.exe.xyz/a/H3xMi1fJE_pHzpBonRlxkjJ1D96rbiC3/html/dumps/turn-1507499555497971874.html

[eager linden]

Based on my debug info you have actually completed your turn, but this never got communicated to me on discord. See screenshot.

Can you update your message to tell me your progress?

[real stone]

Updated the previous message with the completed investigation summary. Short version: no edits made; the verbose comments come from reusing initialWorkspaceConfig, and the missing SDK installs are because most dogfood repos use sdk.source = "dang", which is explicitly unmapped as a workspace SDK module today.

💻

[eager linden]

Verbose config comments: root cause is initialWorkspaceConfig in core/schema/workspace_config.go. Migration parent plans seed new parent configs with that exact starter template in core/schema/workspace_migrate_parent.go:109, so migration is reusing the workspace init template instead of emitting a minimal migration config.

Can you start a branch against workpace, where we will incrementally push fixes for all this (in tight coordination with me!)

1. First: let's eliminate dagger workspace init entirely. The command should go away. Make sure any tests that assert its existence are deleted also. And, if dagger migrate relies on it as you hinted - make sure it doesn't.

[real stone]

Pushed the first scoped fix branch:

codex/remove-workspace-init at 9fe67fab6
https://github.com/dagger/dagger/pull/new/codex/remove-workspace-init

What it does:

• removes dagger workspace init from the CLI
• makes dagger workspace init fail as an unknown command instead of falling through to workspace help
• removes currentWorkspace.init from schema + generated Go/TS/Rust clients
• replaces the verbose init template with minimal [modules] for migration/auto-created configs
• deletes or rewires tests/docs that referenced init

Checks run:

• go test ./cmd/dagger -run 'TestRemovedWorkspaceCommands|TestWorkspaceInitCommandRemoved|TestRootHelpShowsWorkspaceCommandGroup|TestWorkspaceFlagPolicy' passed
• go test ./core/schema -run TestWorkspaceMigrationParentPlans passed
• go test ./core/integration -run '^$' passed
• go test ./... in sdk/go passed
• go run ./cmd/dagger workspace init now errors unknown

Noted but not blocking this patch: full go test ./cmd/dagger ./core/schema hit unrelated local/env failures in TestCloudEngineUnauth and shell autocomplete schema validation. TS/Rust SDK compile checks could not run because pnpm and cargo are not installed in this VM.

💻

💻 📝

[eager linden]

When you're done (and commit as you go, with OSS-grade commit messages that are concise and make each word count):

: the SDK install path works for mapped plain SDK modules.

Which are mapped?

dang is explicitly unmapped today.

It should be mapped to github.com/dagger/dang-sdk

What other unmapped cases did you hit? When this happens, it should add an entry in the migration report, and a comment in the migrated config, something like # Skipped SDK install when migrating module <local path>: no known SDK for runtime "<runtime name>"

[real stone]

Done and pushed on codex/remove-workspace-init: b6848c4c9 Map dang workspace SDK and c76cf4197 Report skipped SDK installs. Mapped runtimes are now go/python/typescript/java/php/elixir/dang; dogfood only hit dang as unmapped. Unknown future SDK runtimes now get a config comment and migration report entry. Checks: go test ./core/sdk ./core/schema passed.

[eager linden]

dump

[real stone]

Dump for turn 1507511091809485000:
https://dx-51f50c5ff62b1b0f5312.exe.xyz/a/H3xMi1fJE_pHzpBonRlxkjJ1D96rbiC3/html/dumps/turn-1507511091809485000.html

[eager linden]

<@&1506565370385793125> Maybe rename the branch to something better-scoped. Perhaps workspace-migrate-polish?

[real stone]

Renamed and pushed. The branch is now:

codex/workspace-migrate-polish
https://github.com/dagger/dagger/pull/new/codex/workspace-migrate-polish

It points at c76cf4197. I also deleted the old remote branch codex/remove-workspace-init; git ls-remote now only shows the new branch.

💻

💻

[eager linden]

Can you please:

1. Open a PR against workspace for this migrate polish fix

2. Manually change your migration branches against the various module repos, so that it looks exactly like you ran migrate with your fixed version (no superfluous comments in .dagger/config.toml, mapped dang SDK module etc

3. Open PRs for each of your migration branches, with a concise to-the-point PR description without an over-complex template format.

[real stone]

Done.

Core PR:

• dagger/dagger: https://github.com/dagger/dagger/pull/13213

I amended and force-pushed the module migration branches so they match the fixed migrate output: no verbose starter comments, and dang repos now install github.com/dagger/dang-sdk. Then I opened these PRs:

• PsScriptAnalyzer: https://github.com/dagger/PsScriptAnalyzer/pull/1
• biomejs: https://github.com/dagger/biomejs/pull/1
• eslint: https://github.com/dagger/eslint/pull/8
• go: https://github.com/dagger/go/pull/12
• go-sdk: https://github.com/dagger/go-sdk/pull/1
• helm: https://github.com/dagger/helm/pull/1
• jest: https://github.com/dagger/jest/pull/22
• node: https://github.com/dagger/node/pull/1
• prettier: https://github.com/dagger/prettier/pull/8
• pytest: https://github.com/dagger/pytest/pull/12
• sdk-sdk: https://github.com/dagger/sdk-sdk/pull/1
• setup: https://github.com/dagger/setup/pull/4
• shellcheck: https://github.com/dagger/shellcheck/pull/1
• vitest: https://github.com/dagger/vitest/pull/12

No PRs for python-sdk or typescript-sdk: their codex/migrate-1.0 branches have no diff against main.

💻

💻 🛠️ 📝

[eager linden]

@dawn aurora @compact siren FYI these PRs 👆 will hopefully trigger our first checks using 1.0.0-alpha-1 in this org https://dagger.cloud/dagger-dogfood/checks