bramblerose

vor 5 Monatendiscuss

While that is true, "Drivers consistently ignoring rules" is also a systems issue, which can be mitigated through e.g. better road design (narrower roads reduce speeding, for example).

bramblerose

vor 6 Monatendiscuss

Unless the design of the object is copyrightable (which it often is!) in which case the photo is a derivative work.

bramblerose

vor 7 Monatendiscuss

- Using the commit SHA of a released action version is the safest for stability and security.

This is not true for stability in practice: the action often depends on a specific Node version (which may not be supported by the runner at some point) and/or a versioned API that becomes unsupported. I've had better luck with @main.

bramblerose

vor 10 Monatendiscuss

The solution to the "interface/tooling to translate" problem, at least for open source applications, is https://translatewiki.net/ , with the additional benefit that it comes with a team of experts that can help you understand how to deal with stuff you might be unfamiliar with, such as RTL languages and plural forms.

bramblerose

vor 10 Monatendiscuss

   uses: actions/checkout@v4

That uses the Node that is provided by GitHub, and that will break in the future.

bramblerose

vor 10 Monatendiscuss

I find the repeated deprecations on GitHub Actions frustrating to work with. One of the key goals of a build system is to be able to come back to a project after several years and just having the build work out of the box.

Yet with GHA I need to update actions/checkout@v2 to actions/checkout@vwhatever (or, what I'm doing now, actions/checkout@main because the actual API haven't actually changed) because... some Node version is "out of maintenance"?!

GHA is literally code execution as a service. Why would I care whether the Node runner has a security vulnerability?

bramblerose

letztes Jahrdiscuss

In the end, this is the age old "I built by thing on top of a 3rd party platform, it doesn't quite match my use case (anymore) and now I'm stuck".

Would GitLab have been better? Maybe. But chances are that there is another edge case that is not handled well there. You're in a PaaS world, don't expect the platform to adjust to your workflow; adjust your workflow to the platform.

You could of course choose to "step down" (PaaS to IaaS) by just having a "ci" script in your repo that is called by GA/other CI tooling. That gives you immense flexibility but also you lose specific features (e.g. pipeline display).

bramblerose

vor 2 Jahrendiscuss

I would argue that the second rule is even optional here. There is enough literature (McConnell's Software Estimation, Boehm's Software Engineering Economics) that suggests that, given a well-scoped problem and other projects to base the estimation on, a good (+/-50% or so) estimate is possible. But if you don't know what you're building it's all wasted effort because you're estimating the wrong thing!

comments