Mastering Observability: Softwaresysteme verstehen, steuern und verbessern
Wie sich mit Observability Anwendungsverfügbarkeit sichern, Leistung steigern, Probleme erkennen und lösen lassen, zeigt die Online-Konferenz am 5. Juni 2025.

Mastering Observability: Softwaresysteme verstehen, steuern und verbessern
Wie sich mit Observability Anwendungsverfügbarkeit sichern, Leistung steigern, Probleme erkennen und lösen lassen, zeigt die Online-Konferenz am 5. Juni 2025.
c't-Workshop: CI/CD mit GitLab
Der Workshop vermittelt Entwicklern den Umgang mit GitLabs CI-Funktionen: Sie lernen, Softwareprojekte effizient zu bauen, zu testen und zu veröffentlichen.
Actually, I was looking for something similar to use in a couple of @eleventy projects, @vanillaweb.
I discovered that @Codeberg hosts @WoodpeckerCI, and provides CI/CD services
There is a very instructive repository collecting examples, including one specifically for Eleventy! (I did not test it yet, though)
As every free #ContinuousIntegration vendor is feeling the pinch of cryptocurrency freeloaders, they've all limited the amount of free CI jobs/minutes, and I've just run out of mine at #GitLab (for actual software project tests, not disgusting cryptocurrency mining)
So I setup a GitLab CI Runner on the #Kubernetes cluster that I #SelfHost in my #HomeLab and it does actually work: I can push commits to gitlab.com and it'll manage the orchestration of CI jobs running on my own machines!
I did run into a few issues, the main one being that a critical part of this setup is architecture-specific and does not auto-detect, so I had to hardcode the ARM64 image to get jobs running on my cluster (which is a bunch of Raspberry Pi 4 nodes): https://gitlab.com/gitlab-org/gitlab/-/issues/510740
Also, I run some of my test jobs using the "archlinux/archlinux" and "homebrew" images, and they unfortunately (but understably) do not support linux/arm64 , so I'm either going to have to emulate x86_64 to run those containers very slowly, setup a completely separate runner and hardware for x86_64 jobs, or remove these tests from my setup for the time being
What are folk's approaches to integration testing against cloud stuff?
For example we have an Enterprise Application as an IdP in Azure
Do you usually mock it out? Have a long-lived nonprod instance? Terraform spin up and tear down?
Ooh, looks like Woodpecker CI is getting support for running rootless images. Which means I should be able to set up CI for Kitten* on @Codeberg soon :)
Published: a 19th practice that makes Continuous Integration
Have Reliable Tests
Unreliable tests require an additional layer of manual regression testing that negatively impacts time to market with little extra quality.
Published: a 15th practice that makes Continuous Integration.
Make the Build Self-Testing
There are a couple of more practices coming ...
Am I the only one around here...?
It just occurred to me that this feature could be used a much more accessible method of presenting #ContinuousIntegration results than those images that don't even have alt text.
You can just prepend the last CI run's summary to the readme as plain text, like god intended.
cc: #accessibility
The slash in the middle of “CI/CD” is one of nature’s rare decoupling opportunities. There are few examples of such joyfully loose coupling.
So why are people making their lives harder by trying to treat them the same?
I've shared my thoughts in this post on The New Stack in this post.
#Concourse is a pile of hot garbage
@marianom @skye With CI that allows you to build arbitrary jobs based on client-sent triggers for activation (like git hooks or fossil's own equivalent) or even cronjobs, it would be quite feasible to get good results with something like #Laminar (https://laminar.ohwg.net/) or #ConcourseCI.
Hey gang. We use GitHub Actions, and are all-in on Slack.
What's the best way in 2023 to have a "Siren of Shame" for a fully remote team?
#software #softwaredevelopment #ContinuousIntegration @shanselman
I bet the massive (and growing) resource consumption of cloud computing is largely because seemingly every CI job downloads (a) an entire operating system, (b) a full set of pinned dependencies, (c) the full version control history of your project, then (d) builds all of them from scratch, then (e) it’s all thrown away and run again because you just force-pushed a typo fix.
GitHub-Updates: Private Schwachstellenmeldungen und Regeln für Branches
Gleich drei neue Funktionen hat GitHub veröffentlicht. Sie verbessern die Sicherheit und machen die Arbeit mit Branches komfortabler.
So one way to define #continuousintegration is to write recursive function that defines its inputs in terms of the outputs, which the function gives using initial inputs and so on.
So domain corresponds to rand and vice versa and this describes continuity of the function?
Can we define the continuity in #math like this
Why types should I use if i write it in #haskell
Aha others are thinking about it too
Albeit, i don't think I can treat arrows like applicatives in my approach
Quote
fetching gives you a source promise and you want an image promise
writing pipelines using arrow notation is difficult because we have to program in a point-free style (without variables).
ci- is cool
https://codeberg.org/Codeberg-CI/request-access
https://roscidus.com/blog/blog/2019/11/14/cicd-pipelines/
via @talex5
I'm starting to suspect that when people say "CI/CD", they don't actually do #ContinuousIntegration.
Woodpecker CI is a free open source community fork of the Drone Continuous Integration platform. You can follow Woodpecker's Fediverse account at:
There's more info about Woodpecker on their website at https://woodpecker-ci.github.io and their git at https://github.com/woodpecker-ci/woodpecker
@lj_writes git patch by email? ;)
http://alblue.bandlem.com/2011/12/git-tip-of-week-patches-by-email.html
Maybe look into GitHub Actions or some other #ContinuousIntegration solution so you can let the CI do all the compiling into Word docs as soon as you push your changes, and even have it e-mail a link to the newly compiled documents? :)
Then they can leave comments on your pull requests or commits, perhaps even with handy line references. ;)