#GitHub actions yaml removal

1 messages · Page 1 of 1 (latest)

urban vector
#

Agreed, been spending a lot of time in this kind of area recently - is there any particular part that stands out?

#

The .github/actions directory should have most of the complex logic now, that used to be spread around a bit more, though obviously there's still a lot of work to do.

#

Eventually I'd like to move to using our GitHub action, but we have some blockers there, essentially that's what our actions/call is a variation of

#

I like @unreal viper's generation idea: I had the idea that we could take each call and generate an action from it, so you can call it directly from your workflow.

#

I'm not 100% sure about using a module that defines the GitHub yaml in structs though - yes, you get to use dagger, but it's still not really runnable locally in the same way

urban vector
urban vector
urban vector
mortal peak
#

@urban vector thanks for the review on other ci pr, I'm replying now

#

and I have time if you want to chat live

urban vector
#

ah, apologies, i'm dying here of hayfever, it will probably have to be another day 😢

mortal peak
#

Oh no!

#

Feel better

#

And I just realized you didn't just review, you fixed some remaining issues as well, so thank you for that too

unreal viper
# urban vector I think I like the idea, but would this actually result in a loss of complexity?...

The very practical benefit I was thinking of is how in the release process you have to update a bunch of version strings all over many files, which is super manual and tedious and could be fixed by generating them one a common source of truth.

I also think our use of some of the common reusable actions used by e.g. the SDKs makes the workflows harder to read (it's like trying to follow a function call, but in yaml). If they were generated then the commonality would just be handled in code with actual functions and the generated output doesn't need any common actions or anything like that.

#

We should still just try to modularize as much as possible, but for what's left it does seem like it would be cleaner to generate the yaml rather than keep handcrafting them

mortal peak
#

Yes agree! Plus we already have pipelines to handle generated code in the dev workflow. Special checks to make sure you didn't forget to generate, etc. So CI YAML would just be another thing to generate, alongside our client libraries etc

urban vector
#

yeahhh, i'm coming round to the idea

#

we could generate the structs to fill automatically from a json schema

#

since github provides one of those for it's github actions yaml format

#

so we could fairly easily do the yaml mapping bit without all the manual bits

mortal peak
#

The part I'm not sure about is: how do we configure the generator? And how much duplication can we avoid?

urban vector
#

then it's just a conversion job, a vim macro (or chatgpt) could do the initial conversion

urban vector
#

we could also try integrating with act for basic testing

#

though i'm not hopefully on that front at all

mortal peak
#

I mean how much duplication can we avoid adding

#

Somewhere, somehow, the yaml generator function will need a list of event/module/function/arguments as input

#

Presumably that list will be in code - as arguments passed from one dagger function to the other

urban vector
mortal peak
#

Isn't that the schema of the output?

urban vector
#

mm, but this would let us at least generate the structs that we assemble

#

doesn't really solve the "put a bunch of internal details here"

#

but tbf, whatever we do, we'll need to write out the names of our functions/modules/etc - at least this way they'd be in go and not in yaml

mortal peak
urban vector
#

maybe one day we could do some cool self introspection to get this

mortal peak
#

Right

urban vector
#

i wouldn't block on that though

mortal peak
#

But probably would be missing information anyway - like which functions of which modules to run on which CI events?

mortal peak
urban vector
#

🙂 custom pragmas/decorators?

#

that would be funky

#

// +github-event="pull_request"

mortal peak
#

What's funny is, once you daggerized the generating of the CI config from event/module/function tuples... You kind of took the first step to running it 😇

#

How different would those two APIs be?

#

In both cases you're describing which event should trigger which function call

#

Mmmmm but when you're running it, you would want to just import the module and call the function via the generated bindings...

#

---> What if we gave you the same experience when building it somehow?