Hi everyone.
So today we're going to speak about Typhon, our software for
Knicks-based continuous integration.
Let's say, for the sake of the argument,
watch your enthusiast, and you're asked to set up CI at work.
So what do you do?
You convince your boss to use Knicks, because that's great.
And you install a header.
It's the de facto software for CI with Knicks.
So your job is fantastic using Knicks,
but soon you realize that not everything is perfect,
because first you need to install the thing.
And it's not easy.
It's a full.
And so you want get upstate choices.
Then you need to configure the plugins,
and each time you change the configuration,
you need to redeploy the thing.
Also, it's hard, because when you want to change a plugin,
you actually need to write a poll for scripts,
and you need to redeploy it again.
Last thing, when you want to do deployment,
all you get is this rank command thing,
which is a bit hard to use, and a super staple,
which you don't really like.
So you start to dream about something much more simple,
something declarative maybe.
Maybe you want your plugins to be defined,
user defined basically, with Knicks maybe,
and you would like some better deployment,
more in line with Knicks philosophy,
with declarativity and the productivity.
Okay, so in this dream,
how does it look like to configure CI for a project?
Well, at first it looks a lot like it does in Hydra.
You set up an attribute set of derivations
which are going to constitute your jobs.
But then you write a Knicks expression for your project
that looks a lot like this one.
So here the makeGitUpProject function takes all the information
that needed for a GitHub workflow,
with the repository, of course,
some arbitrary deployment rules.
And of course you're going to need secrets like
GitHub tokens and SSH keys to set GitHub statuses
and do remote deployment.
This expression is fed to Typhoon through the Flake URL.
And once Typhoon spawned your jobs,
it's going to use the project expression to build actions.
So actions are scripts, which are user defined and Knicks built.
They are run in a sandbox and triggered by Typhoon
on various occasions to provide features
that will be provided by Hydra's plugins.
For instance, the most important hooks triggered by Typhoon
are before and after every job to set statuses, of course,
or do any kind of deployment.
In a little bit more detail, an action is sandboxed
with only access to the store and to Internet.
It does not have access to the local machine.
So for instance, it does not have access to secrets
for other projects.
It takes JSON as input containing the decrypted secrets
and of course contextual information about your job.
And it outputs JSON to communicate with Typhoon.
Thanks to actions, Typhoon is completely for diagnostic.
Actually all the communication between Typhoon and the forge
is done through actions, meaning Typhoon can fit
a lot of different workflows.
But how do you write actions?
Well, of course, you use the Typhoon's Knicks library
that lives in Typhoon's flake.
It would be quite frugal at the beginning,
but soon it would go to fit a lot of different forges
and various kind of deployments.
And the goal would be, of course, to have an ecosystem of actions
like we do for GitHub actions, but much better
and using Knicks instead of YAML.
A few words about how you would code something like this.
Of course, you would use Rust
to get some like technologies like Actix and Dissol
for the back end and a nice web app using Leptos.
And so you would start coding and soon you would have a prototype.
Soon the prototype would run CI for itself.
So it would be time to present the project to the Knicks community
at FOSDEM and tell people to try it.
You would still want them though.
It's still a prototype.
Everything you talked about today is maybe not yet fully implemented,
but still it's ready for beta and you're waiting for feedback
for issues, a lot of issues, maybe a contribution
even to the actions library.
And all that would be left for you to do is to thank everyone
for listening to you.