When debugging failures in CI in steps that execute a shell snippet, it's harder to do when stdout and stderr aren't interleaved. This leads me to think about this: what would the ideal CI run log output be like, for me? I have some thoughts that I'll write down when I have time, but you, dear reader, what is your answer? Assume anything is possible, don't worry about how much work it'd be.

GitHub Actions for the R language: Makes automatic testing of your R package much easier and making sure your package works on different OS and R versions is a matter of just a few lines of yaml: https://github.com/r-lib/actions #rstats #ci #testing #github

GitHub Actions now supports free-threaded Python!

I wrote up how to add it your workflows so you can start testing free-threaded Python 3.13 and 3.14 with either actions/setup-python or actions/setup-uv.

https://hugovk.dev/blog/2025/free-threaded-python-on-github-actions/

Climate change nightmare, tech edition: #CI workflow using #Nix on #Gentoo to fine-tune a #JVM implementation of a #blockchain-enabled #LLM.

Thanks for inspiration, @faassen!

Keep your commits consistent!
forgejo-commit-path-rules v0.2.3 ensures your commit messages align with your file changes.

Enforce commit message and file path rules in your repo!

Written in Rust
Repo: https://codeberg.org/kemitix/forgejo-commit-path-rules
A ForgeJo Action/CLI Tool

What's New:

- Coloured highlights in logging (supports --no-colour)
- all matching strategy for paths (default is any)
- Built in templates: docs, feature, tests and fixes

Usage:

- Define rules in .forgejo/commit-path-rules.toml
- Run via CLI or ForgeJo Action

Install:
cargo install forgejo-commit-path-rules

CLI Usage:
forgejo-commit-path-rules --workspace . --no-colour

Forgejo Action:

 jobs:
  validate:
   steps:
    - uses: actions/checkout@v3
      with:
        fetch-depth: 0
    - name: Run forgejo-commit-path-rules
      uses: kemitix/commit-path-rules@v0.2.3
      with:
        args: --verbose

Some valuable advice on #CI - see below for the source:
---
After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is:

* Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code.

* Invest time that your pipelines can run locally on a developer machine as well (as much as possible at least), otherwise testing/debugging pipelines becomes a nightmare.

* Avoid YAML as much as possible, period.

* Don't bind yourself to some fancy new VC-financed thing that will solve CI once and for all but needs to get monetized eventually (see: earthly, dagger, etc.)

* Always use your own runners, on-premise if possible

Source https://news.ycombinator.com/item?id=43420361

ACCU 2025 SESSION ANNOUNCEMENT: Continuous Integration (CI) for large scale package-based C, C++ projects with Conan2 by Diego Rodriguez-Losada

https://accuconference.org/2025/session/continuous-integration-ci-for-large-scale-package-based-c-cpp-projects-with-conan2

Register now at https://accuconference.org/booking/

Can't wait for all the #bugs, #security holes, and #vulnerabilities that will inevitably come out because people are just letting some prediction engine write their code for them and aren't reviewing the code or the logic being inserted into it. #AI #LLM #Vibe #SoftwareDevelopment #CI

https://developers.slashdot.org/story/25/03/18/1428226/vibe-coding-is-letting-10-engineers-do-the-work-of-a-team-of-50-to-100-says-yc-ceo

the other #rustlang thingy that's been cooking (and just passed a #ci run) is called #taggart.

it uses #tengri to pop up an interactive table to edit things, namely: the #id3 tags of music releases

its purpose? why, to make it easier to prepare a certain pile of content (that we've accumulated with a friend over the past, what, 6-7 years), for publication in a sovereign #faircamp instance! but none of it's well-tagged and existing interactive mediatag editors are ugh

https://codeberg.org/unspeaker/taggart

I am increasingly of the opinion that when writing CI scripts for platforms such as GitHub actions you shouldn't use that platform's features but just wrap a single largish bash script.

It is trivially runnable on your laptop, which is great for testing and debugging changes locally.

And you don't need to learn syntax and conventions that are only used by a single system.

I'd be interested to know why this approach is so unusual. Is it because actions from the marketplace don't mix well with this?

I just tried to update my Godot project to Godot 4.4 but it seems like my build pipeline does not support 4.4 builds just yet ...

Somehow the docker container was not updated because a service broke down, now I need to wait.

https://github.com/felix-schindler/build-godot-action

I already used a fork of the action because the other one was achieved.

Are there other more reliable build solutions out there?

#Godot #Godot4 Godot4_4 #GameDev #CI #Development #GodotQuestion

forgejo-todo-checker v1.3.2: Checks your source files for TODO and FIXME comments, where they don't have an open issue number

Written in Rust
Repo: https://codeberg.org/kemitix/forgejo-todo-checker
A ForgeJo Action.

What's new

- bug fix - hadn't updated the version of rust used in the docker image

Install

cargo install forgejo-todo-checker

CLI Usage

forgejo-todo-checker --workspace $PWD \
    --site https://git.kemitix.net \
    --repo kemitix/forgejo-todo-checker

This should allow you to check locally that your TODO and FIXME comments are valid before you push the change to your CI.

CI

forgejo-todo-checker is primarily a Forgejo Action:

jobs:
  tests:
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Check TODOs
        uses: kemitix/todo-checker@v1.3.2

If you have any TODO or FIXME comments in your code that doesn't have an associated and open issue, then this will fail the build.

"I’ll tell you… You need to share the illusion that you provide more than what you really do, and hope that the years of investing in vendor-locking will prevent companies from leaving you. Ehem, Mobile DevOps. But this model is falling apart. It’s a matter of time. And we’ll see more companies iterating on the idea that they are a CI company. Give it some time…"

#Swift #CI #iOSDev
https://pepicrft.me/blog/2025/02/24/ci-is-commoditizing

Do you know how to define release pipelines? Have experience in building environments from developer sandboxes to production? Then you're the right person to talk at DevConf.CZ 2025!

Any tools and best practices in #DevOps and #Automation, agile development practices, continous application development or testing strategies are welcome!

Submit your proposal now at https://pretalx.devconf.info/devconf-cz-2025/cfp

#Ansible, #AIOps, #CI/CD, #Tekton, #ArgoCD, #SiteReliabilityEngineering

Update on #Nautilism, my Godot sailing game! I have refactored the wave code and made some more under-the-hood tweaks. I also set up a #GitLab #CI pipeline to automatically build the game and host the builds on #gitlabpages. The repository is https://gitlab.com/TKK13909/nautilism and the website is https://nautilism-c15fcc.gitlab.io/

Please try it out and tell me what you think! I'm still trying to figure out the direction I want to take the game but I am happy to hear suggestions.

@liw presented

> Ambient CI engine: an introduction

https://fluconf.online/sessions/ambient-ci-engine-an-introduction/

Finally finished migrating to Apple's OpenAPI Codegen, which fixes a lot of issues I had with CreateAPI.

I'm thinking of moving the OpenAPI Spec to a own repository and generate the API Clients (Golang, Typescript and Swift) with a Github Action on Trigger.

Is that a good practice? Maybe I should write about it, but I guess I'm to lazy for that.
#iosdev #backenddev #github #ci

First up today at #FOSDEM: Upgrading Linux development and integration workflows with #KernelCI, presented by Paweł Wieczorek. 11:30 CEST, room UD6.215, see you there! https://fosdem.org/2025/schedule/event/fosdem-2025-6487-kernelci-upgrading-linux-development-and-integration-workflows/ #CI #Linux