3 ms·

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

by HdS84 2y ago

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

deleted 2y ago
[deleted]
raffraffraff 2y ago
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?
- vel0city 2y ago
  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 https://github.com/aws-actions
- Groxx 2y ago
  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-chain-compromise-third-party-github-action-cve-2025-30066 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-files-supply-chain-attack-cve-2025-30066 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.
kroolik 2y ago
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/#artifactsreportsdotenv https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifacts...
- HdS84 2y ago
  Yes, that works for most thinks. E.g. for services:name, but not services:variables:xxx
daveau 2y ago
they have this now: https://docs.gitlab.com/ci/components/ https://docs.gitlab.com/ci/components/

by HdS84 2y ago

deleted 2y ago

[deleted]

raffraffraff 2y ago

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?

vel0city 2y ago
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 https://github.com/aws-actions
Groxx 2y ago
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-chain-compromise-third-party-github-action-cve-2025-30066 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-files-supply-chain-attack-cve-2025-30066 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.

kroolik 2y ago

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/#artifactsreportsdotenv https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifacts...

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

daveau 2y ago

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