Hacker News Reader

Comment by the_duke | Hacker News Reader

Friendly reminder of the day:

Always have an established and regularly tested workflow for manual deployments that doesn't rely on CI jobs. You'll need it sooner or later.

View on HN

That's why my CI pipelines never rely on proprietary stuff.

I use multistage Dockerfiles + Buildkit to implement secrets caching, etc... My CI scripts just do "docker build" and "docker publish".

It makes doing things locally much easier.

I've always resisted the change to GHA, preferring instead tried and tested Jenkins and docker workflows. Sure, multi-agent GHA is nice, but when it's down, what do you do? We don't even work in offices to have swordfights in anymore.

I agree here, looking now it seems that I would need three pairs of hands to count how many times Actions have gone down every year. It feels like Actions itself is not ready for production use.

Also nice XKCD reference (https://xkcd.com/303/)!

I wasn't aware that there's a "docker publish" command. Is that an add-on or how does that work?

Could he mean "docker push"? I never heard of any publish command.

I meant docker push :(

Your CI should be the automation of an existing, manual process for this reason.

Should the automation fail, your manual process still works.

Anyone recommend any tools that can do CD pipelines on the CLI, maybe something a bit nicer than Makefiles?

Jenkinsfile Runner is exactly that!

https://github.com/jenkinsci/jenkinsfile-runner/

There's also taskfile. https://taskfile.dev/

I’m liking Earthly a lot: https://earthly.dev/

https://dagger.io

Or a shell script. Always have a backup shell script.

Problem is who will maintain and test it. Without DR (disaster recovery) test days its worth nothing cause something will have been changed and not propagated

Use the script in your regular CI/CD pipeline. Just add arguments for things that vary between GitHub runners and local machines, like secrets and paths.

It's certainly a risk to be relying on any proprietary SaaS or Cloud but I don't really get the reason to be doing CI/CD as if it can never be down. There are a lot of risks in having credentials on hot spare alternative systems you rarely need and the number of times I've really had to rollback a deployment quickly is something I can count on one hand. Isn't it better to focus on quality to not need to deploy on a moment's notice?

You can keep the credentials in a password manager. Presumably the sysadmin already uses the same corporate PM for his regular credentials, so this doesn't increase risk much.

We're a small org but I'd be pretty annoyed if we planned a deployment on a day and ended up having to wait for GitHub to go back up. Deployments can be disruptive and we have to coordinate with other teams.

I feel like most of my build or deployment pipelines always end up as just a bash script executed by the CI/CD tool anyway.

Yeah. I the end is the only thing Jenkins do for me.

SCP, SSH, and cp to the rescue

Reply on news.ycombinator.com