Eager Eagle

I’ve been doing that for years. Rollbacks are very rare, to the point that it doesn’t make much of a difference whether I do them all at once or not, other than spending more time to do it.

If I wasn’t using containers for everything, sure. Otherwise it’s a bit of an excessive concern.

exactly my point, I’d suggest automating that before I bothered with PRs that upgrade versions, as it’s a waste of time.

“manual changes”, which connotes “local changes”

It doesn’t. Manual as in a PR with upgrades that you’re suggesting yourself, as opposed to running dependabot.

Putting up a PR with changes isn’t considered a manual anything.

If I have to open a PR myself, that’s very much a manual change.

that’s a lot of FUD, topgrade just upgrades using all package managers you have, it doesn’t do the upgrades itself bypassing the manager that installed it, or package authors.

dependabot is a tool for repos, not to apply local changes

That may work for a handful of projects. It’d be my full time job if I did it for everything I run. Also, I might simply suggest maintainers to adopt dependabot or an alternative before I spend time with manual changes. These things should be automated.

what’s the alternative? Write a PR yourself?

upgrade all things by default

https://github.com/topgrade-rs/topgrade/

you do have an nginx process with PID 2511847 using the port

get more info with

ps aux | grep 2511847

or kill it, if you need to spawn a new one with the right configuration

find out which process is really binding to 443 if you don’t recognize that port as being used

sudo ss -unapt | grep 443

This is such an underutilized and neglected behavior.

The very least a config parser should do is to log a warning.

because of garbage like that I always use the long option names in scripts, even when the short one would be obvious