"Desert Island guide to daggerizing legacy projects" - Demo for community call

[charred swallow]

@shut compass has graciously accepted to do a community demo this week, but is hitting a few content roadblocks.

He has a large theme that he wants to cover, so I am hoping we can help him find the exact part of the story that he should dive into.

@shut compass do you want to add a summary of where you'd like support or guidance? I can ping some people that I think will be best to help once you do.

[shut compass]

So I'm in a number of open source communities which have overly complicated CI tooling.
and I have been looking at ways to structure a migration to dagger.

Or rather looking at ways to use dagger to reduce the number of unfamiliar tools a new contributor or maintainer needs to manage.

[charred swallow]

Do you have an outline of what you were thinking about for your current demo? Maybe even just showing how you have or would migrate a single project? @thorny trout @warped basalt and I have thought about live streaming the "daggerization" of a project before, so maybe we could try it out this week!

[shut compass]

For perspective, these are some of the projects:
https://github.com/cucumber/common
https://github.com/nedbat/coveragepy/blob/master/Makefile
https://github.com/upstream-operators/okd-operator-pipeline?tab=readme-ov-file#description

[charred swallow]

Kyle was already going to do help demo something this week, so maybe we could just try it out tomorrow together during our recordings session and both of you can pair on it? It would be fun and interactive.

[shut compass]

So kid, you say you wanna change the world with Dagger? OK, first you make a list of the Makefile targets, then you go after the Docker file, then the shell scripts ....

Something along the lines of Feathers' classic "Working effectively with legacy code"

And combine that with "making work visible", listing the key indicators (speed? simplicity? dependencies?)

[thorny trout]

The message makes sense! Do you have a starting point in mind? i.e. a demo repo you're going to daggerize?

[shut compass]

So I have a rough outline of the talk here:
https://paste.ofcode.org/SPrGZDhLE3vnCR5hVVECdh

and I have a few repos under consideration:
https://github.com/blaisep/pytest-bdd-ng
https://github.com/nedbat/coveragepy

I had considered
https://github.com/upstream-operators/okd-operator-pipeline
but maybe it's a beast and I don't know it all that well.

@thorny trout , I'm also open to any suggestions, of course.

I suppose @golden jungle may have daggerized enough legacy repos by now to have a sense of whether this approach:
https://paste.ofcode.org/SPrGZDhLE3vnCR5hVVECdh
is on track and how it should be changed.

[charred swallow]

@nocturne haven might have thoughts since he has wrote many of our guides, and @ivory warren has done a few presentations on Dagger in the last weeks, so he might have some feedback too.

[shut compass]

Hmmm, I think https://github.com/blaisep/pytest-bdd-ng
because it is a hodgepoge of external dependencies and toolchains

[shut compass]

@thorny trout , I guess I have a plan for how to break up the structure of a legacy repo,
maybe I should also add some guidance on the sequence of iterations?
For example:

• Start by replacing the Dockerfiles (benefit: caching performance)
• Next, replace the shell scripts (benefit: Simplicity, DevEx)
• Then, look over the config data (maybe consider an abstraction layer to help with mock data?)
• Finally, refactor the tests if necessary

[thorny trout]

Yup totally makes sense! A good source of inspiration might be Jeremy and Mark's talk from Rejekts back in November https://www.youtube.com/watch?v=tWWBzsZLrIw&t=16364s
They go through a pretty similar sequence

[shut compass]

THANK YOU!
I was afraid that I might have overlooked something, I'll go through this in a few minutes.