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.

My team is doing continuous integration for years. Trunk-based. PRs is a tool invented for OSS development in a zero trust environment.

When working in a team and doing pair or mob programming, practicing TDD, no need for code reviews and no need for PRs or branches.

Just once in a while, we create a branch for some exploratory work.
But this is an exception.

#swdev #DEVCommunity
#PairProgramming #ContinousIntegration

https://martinfowler.com/articles/ship-show-ask.html

In case anyone is looking for a selfhosted #CI for #nixos: I just build a adapter for #woodpecker

It consumes #nixos #flakes and dynamically generates a #pipeline from a predefined output. That way, you can define all your build steps as #nix code or derive them from the flake's contents.
https://github.com/pinpox/woodpecker-flake-pipeliner

#continous #integration #continousintegration @WoodpeckerCI #pipeline

quote from pentest report (asked if this is ok):

​ (great work, sadly NDA'ed)

"We bypassed the internal SSH Zero Trust Gateway because its service account was setup to fully trust the [...] Continuous Integration. Due to the chosen Zero Trust gateway this compromise was undetectable, because there are no logon events on the target Linux systems being recorded [... This had been disabled by the admins because there was no log investigation procedure for this.]"

#zerotrust seems to have basic requirements. No basics, and Zero Trust becomes Blind Trust.

I am interested in what others do with automation / #continousintegration and Zero Trust. Obviously the login secrets have to be stored in CI. And no one will ever check these CI logon logs, because these are too many.

Architecturally this is a challenge.

Is there a way to run automated tests if an #iOS and #Android app can be properly installed or updated and properly launched?