I don’t think speckle automate should be “hardcoded” to github. In my case, I’d like a particular repo to use. I was surprised to find out that I couldn’t even change the source repo by editing the automation.
Even when github is used, as far as I can tell, Speckle is just adding the github automation specs files. So, speckle automate should just attempt to merge with the given repo.
When the repo is not on github, speckle automate can just detect commits and execute either build the Dockerfile^^^^r Containerfile or treat the repo as a standard project in a particular programming language and set it up that way.
Thank you for the feedback, it is great to hear that you are exploring Speckle Automate.
Would you be able to explain a little more about what you were trying to achieve? Could you also tell us which alternative source code hosting service you would like to use?
there are some arguments for the setup, that we went for:
initially we were going for an all functions should be open source, so having it hosted on github made the most sense
building the source code into a function binary ( oci container ) is not something we wanted to implement in the automate app, because all source code hosting platforms have very good CI/CD solutions for that
With the public beta, we’re now allowing private functions on automate, but we’re still relying on github actions to build and publish the function to the automate container repository.
What you are suggesting is a definitely possible technically, but we’d rather not rebuild what github / microsoft / atlassian / gitlab has already done quite well.
As Jonathon said, we are looking into integrating with these providers, but we’d like to see good signal to justify committing to developing the integration.
What repo hosting + CI/CD solution would you prefer to use for your automate function?
Again, I don’t see why speckle needs to be involved in the (actual) building of the function. That’s the developer’s responsibility.
Each (self-respecting) programming language has a way to distribute executables. Speckle can just be told where to get the executable from. Furthermore, this is much lighter than dealing with containers.
Thanks, @majidaldo, for your continued input. Clearly, you’re passionate about this, and we truly value it.
We may have to agree to disagree to some extent here. Automate is designed to be the least technical infrastructure for event-based computation, prioritising ease of use and accessibility. The current architectural choices, including leveraging CI/CD systems like GitHub Actions, reflect that goal.
That said, this doesn’t rule anything out. We’re actively testing support for private functions during the public beta and remain open to evolving as we gather more insights from user feedback. While Automate will continue following its current architectural direction, we appreciate your suggestions and consider them part of the broader conversation on future development.
All that said, Speckle has long-supported webhooks for most server activities, which allow you to deploy function code on any infrastructure that can receive them, providing flexibility for those with more custom workflows. Webhooks | Speckle Docs
Thanks again for helping shape the conversation around Speckle Automate—this kind of engagement drives improvement.
we aim to lower the barrier to entry for automate function development. Many times our developers are semi technically skilled AEC hackers, who are not skilled (yet) enough, or just not interested at all in how building a distributable executable works.
While you are right, that building a binary of your code is many times self explanatory, if you do not need to care about dependencies and especially host os + architecture specific ones!
Lets not even get into how complicated it can get, to build a fully statically linked executable, that is runnable no matter what kind of linux distro it runs on. You prob can see how that starts to narrow the number of qualifying AEC developers to a very small population. In our view containerization is a very easy solution to these issues. Btw, if you want to consider the OCI container ( a truly portable execution environment of your app ), the thing that you build, you can do that building yourself and push the image layers to automate. That is what our github action does in the background.
Also consider our point of view, where were running random internet ppl’s untrusted code in our cloud environment. To keep everyone’s Speckle data safe, we need a well isolated execution environment. For us, that is something running on top of kubernetes .
I hope these points shed more light on why relying on an OCI container as an application distribution mechanism makes the most sense for automate.
We do try to provide very good function templates to our devs, that have 95% of the setup boilerplate already in place in a fairly decently documented way.