Open lmangani opened 3 hours ago
Thanks, that's valid a concern we have not addressed, and have not a clear plan yet.
I guess a testing mode with a single platform could be the default, and more expanded test to be done only on request (say via invoking the action explicitly or by opt-in)?
Another bummer with the current approach is it forces rebuilding all platforms when a single one fails (_WIN32 😆) and that's when I think cross-execution build caching might do miracles even with a short retention. Maybe ccache can be used with DuckDB builds?
The current extension template features a FANTASTIC Github Action set to validate our builds on all platforms and save us years in testing but there's a hidden surprise tax in Action costs. A little bit of extension hacking can easily consume 100% of PRO allowances within the first week of each month. The heavy hitters are windows and OSX builds which burn really fast 💸
As our extensions park grows this is becoming a pain and I would imagine this might eventually affect others too - finding out the hard way is very annoying and can literally halt one's development process for weeks (including other projects one might be using actions for). I'm opening this thread to try and find some ideas to lower the cost of development for community extensions.
Of course, rudely opening a garbage Draft PR to the community-extension repo and offloading to DuckDB Actions might be an option (I'm not sure who's credits it uses actually) but that's both feeling wrong and mostly unviable during early development phases and prototyping.
Other approaches could be defaulting a subset of the template actions to run on pushes and only running the full stack on releases, or perhaps implementing build caching between runs to slash the execution time. Is anyone experiencing the same?
Have a fantastic weekend!