Hacker News Reader

Comment by HdS84 | Hacker News Reader

There are lots of problems. Actions try to abstract the script away and give you a consistent experience and, must crucially, allow sharing. Because gitlab has no real way to share actions or workflows (I can do yaml include, but come on that sucks even harder than actions) you are constantly reinventing the wheel. That's ok if all you do is " build folder" but if you need caching, reporting of issues, code coverage etc. Pp it gets real ugly really fast. Example: yesterday I tried services, i.e. starting up some DB and backend containers to run integration tests against. Unfortunately, you cannot expand dynamic variables (set by previous containers) but are limited to already set bars. So back to docker compose...and the gitlab pipelines are chock full of such weird limitations

View on HN

You can apply dynamic env to other jobs by exporting an env file as a dotenv artifact. So first job creates a dotenv file and export it as artifact. Second depends on the first so it can consume the artifact. https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifacts...

Yes, that works for most thinks. E.g. for services:name, but not services:variables:xxx

I haven't looked too much into how sharing workflows works, but isn't the use of shared GitHub workflows (from outside your org) a little dangerous? I get it, we use other people's code all the time. Some we trust more (ISO of a Linux OS with SHA) and others we trust a little less even if it comes from a verified source with GPG, because we know that supply chain attacks can happen.

Every time someone introduced a new way to use someone else's shared magic I feel nervous about using it. Like GitHub Actions. Perhaps it's time for me to dig into them a bit more and try to understand if/how they're safe to use. But I seem to remember just a few days ago someone mentioning a GitHub action getting hijacked?

Definitely a mixed bag. Lots of community derived actions which yes, potentially have some bad supply chain questions. I tend to try and avoid these as much as possible. Lots of established vendors also have their own actions shared though, so you don't have to reinvent the wheel when interacting with their platforms/services/products.

For instance, AWS has a lot of actions they maintain to assist with common CI/CD needs with AWS services.

https://github.com/aws-actions

Yes, it is definitely dangerous, like any other code running next to your stuff. The thing you remember is probably this: https://www.cisa.gov/news-events/alerts/2025/03/18/supply-ch... and a larger description: https://www.wiz.io/blog/github-action-tj-actions-changed-fil...

I will be stunned if this doesn't become a more popular attack vector over the next few years. Lots of valuable stuff sits in github, and they're a nearly-wide-open hole to access it.

they have this now: https://docs.gitlab.com/ci/components/

Reply on news.ycombinator.com