Blindly using automation or implementing it with validation will always bite a person in the butt. Been there done that. It is good but it should always be event driven with a point of user validation.
I'll think twice before using GitHub Actions again
201–210 of 284 posts
Re: I'll think twice before using GitHub Actions again
#202> no way of running actions locally My policy is to never let pipeline DSLs contain any actual logic outside orchestration for the task, relying solely on one-liner build or test commands. If the task is more complicated than a one-liner, make a script for it in the repo to make it a one-liner. Doesn't matter if it's GitHub Actions, Jenkins, Azure DevOps (which has super cursed yaml), etc. This in turn means that you…
When I automate my github actions I keep everything task orientated and if anything is pushing code or builds it has user step to verify the work by the automation. You approve and then merge it kicks off promotional pipelines not necessarily for deployment but to promote a build as stable through tagging.
Re: I'll think twice before using GitHub Actions again
#203Earlier quoted context omitted.
I find that Python scripts that deal with calling other programs have even more sharp edges because now you have to deal with stdin, stderr and stdout much more explicitly. Now you need to both know shell scripting AND Python. Python’s subprocess has communicate(), check_output() and other helpers which takes care of a lot but (a) you need to know what method you should actually call and (b) if you need to do somethi…
1) If possible, don't run shell scripts with Python. Evaluate why you are trying to do that and don't. 2) Python has a bunch of infrastructure compared to shell, you can use it. Shell scripts don't. 3) Apply the same you used for the script to what it calls. CI calls control script for job, script calls tools/libraries for heavy lifting. Often the shell script just calls a python/Ruby/rust exec anyways... Shell scrip…
[dead]
Re: I'll think twice before using GitHub Actions again
#204Why is this team sticking multiple directories that are “independent of each other” into a single repository? This sounds like a clear case of doing version control wrong. Monorepos come with their own set of challenges, and I don’t think there are many situations where they’re actually warranted. They certainly don’t help for completely independent projects.
No project within a single organization is completely independent. In general they all serve to meet a unified business objective and developers often need the global context on occasion. I used to be a multirepo proponent, but have fallen in love with Bazel and “everything bagel” repo.
> No project within a single organization is completely independent. In general they all serve to meet a unified business objective and developers often need the global context on occasion.
Of course; I was only quoting the article. I am a firm believer in making things as simple as possible until you need something complicated, and monorepos/Bazel definitely get a “complicated” label from me.
Re: I'll think twice before using GitHub Actions again
#205It's simple. Don't believe that the company purchased by Microsoft wants anything other than for you to use more compute.
Re: I'll think twice before using GitHub Actions again
#206Earlier quoted context omitted.
The problem with Gitlab CI is that now you need to use Gitlab. I’m not even sure when I started feeling like that was a bad thing. Probably when they started glueing a bunch of badly executed security crud onto the main product.
I decided it was a bad thing when they sent password reset emails to addresses given by unauthenticated users. Not that I ever used them. But now it is a hard no, permanently. They have since had other also severe CVEs. That has made me feel pretty confident in my decision.
If password reset emails shouldn’t be sent to unauthenticated users, how would users reset their passwords?
Re: I'll think twice before using GitHub Actions again
#207I once used Team City and Octopus Deploy in a company. And ever since then, dealing with Gitlab Pipelines and Github Actions, I find them so much poorer as a toolkit.
We are very much in the part of the platform cycle where best-in-breed is losing out to all-in-one. Hopefully we see things swing in the other direction in the next few years where composable best-in-breed solutions recapture the hearts and minds of the community.
Re: I'll think twice before using GitHub Actions again
#208Earlier quoted context omitted.
But I can install it on any Linux system from the base repository
If all your targets are .PHONY, you might as well just as bash (or your favourite shell) directly. Make targets look suspiciously like functions (or procedures), but they actually aren't.
One of the benefits of just -- it isn't a build system, it's a command runner.
Good facilities for arguments, builtins like absolute locations -- there are a ton of benefits (see the README).
Re: I'll think twice before using GitHub Actions again
#209assuming that every folder is independent sounds like bad design.
if they're really independent out them in separate repos.
Re: I'll think twice before using GitHub Actions again
#210> no way of running actions locally My policy is to never let pipeline DSLs contain any actual logic outside orchestration for the task, relying solely on one-liner build or test commands. If the task is more complicated than a one-liner, make a script for it in the repo to make it a one-liner. Doesn't matter if it's GitHub Actions, Jenkins, Azure DevOps (which has super cursed yaml), etc. This in turn means that you…
> My policy is to never let pipeline DSLs contain any actual logic outside orchestration for the task, I call this “isomorphic CI” — ie: as long as you set the correct env vars, it should run identically on GitHub actions, Jenkins, your local machine, a VM etc
i like this term