hc1NTsMwFATgHqXyCZ6f_-2V_RyvkLgAmzRYYLVqqiaqQKhSz9CrIA6T2xAWbGE50nwz9-Vr-Xz0Ajy7tPHQjm2anx7aUI9Dpdc67H8D8-g_Ji-sZ5u_m5v6dmrndxaa50YgSJDchZXq_-lzP_cs9J7_fPEV1HZu-2m7O4wv29M4zSzsPA_X63LLWKJb1w1SykKlRJgFoXRFR25AaZ6M48KgJKFJAdlM0kEU2bpkEYwCRBdBpqisQuIl6yyh01QKqNIZqUvXRcgchS0KxWohko3JKecgfQM
From time to time I get some really good and motivating feedback on the product I have built, violinist.io. And I want to start this post, which will also have a huge feature announcement, by mentioning a couple of them:
If this sounds useful to you, or your organization, please don’t hesitate to reach out for a free trial. In fact, in the name of smooth onboarding, here is an absolutely free trial for you already without reaching out (as long as you are reading and using this within 2 months of this blog post): A totally free license key, valid for all repositories for 2 months from today (valid until 2024-11-19T19:20:19+01:00):
Lastly, there are so much more I want to share and address about this. For example the aspect of open source in all of this, the differences between this and violinist.io (the SaaS), the licencing and pricing aspect. But those are all blog posts on their own. For now, I hope you will try it out if it’s useful, and that you want to connect should you have any questions or concerns. Here in the comments, or by reaching out.
overall did the trick of what I was looking for and was very very fast
Let’s close up this blog post with an animated gif of “runners”.
- Does our code have to make its way to violinist.io infrastructure for us to be able to use the service?
- Can violinist.io access our Self Hosted GitLab which is locked down with a required VPN connection
docker run
--pull=always
-e "LICENCE_KEY=my_key"
-e "PROJECT_URL=https://github.com/user/repo"
-e "USER_TOKEN=ghp_jYgGb_1npvkiHTdnM"
ghcr.io/violinist-dev/update-check-runner:8.3-multi-composer-2
It was wonderfully painless (…) I don’t think I’ve ever experienced a faster setup of a CI tool — I think I said “wait that’s all?” out loud!
Well, today I want to share another product update that will make it theoretically even faster to set up and get results. But first allow me to provide a bit of background on why this new feature came to be.
One recurring question we get is regarding two avenues of a similar aspect:
- Run the same update jobs as violinist.io without any code entering any third party infrastructure
- Run jobs your CI infrastructure of choice. GitHub Actions, CircleCI, Bitbucket pipelines, Self Hosted GitLab, your totally locked down VPN protected GitLab instance that has a totally locked down Jenkins server. And so on
- Decide your own intervals for running them, probably inside said CI infrastructure. Daily jobs? Weekly jobs? Hourly jobs? Not a problem.
- Compose CI workflows that can do all your repositories in a matrix, all on the same schedule, if useful?
- Expose a webhook to trigger jobs, and run them when new items appear in the Drupal Security Announcements RSS feed
- And a million other things probably? You decide!
They might differ a bit in wording or actual focus, but they usually boil down to one of these. And from time to time we find a compromise to both of these questions together, and the person contacting us turn into happy customers. But from time to time these questions also become the actual blocker for them to start using violinist.io. But now, at least, we have an alternative that covers both of these use cases: Self hosting violinist.io runners!
In other words, easy to set up, and fast results.
Of course, this in itself is not super useful. Avoiding running commands on your computer is the whole point of using an automatic update service like violinist.io, but now you can do cool stuff like:
And here is why I am mentioning the feedback regarding quick onboarding in the context of this product announcement. You can literally start an update check with one docker command:
