6 ms·

Invest time in GH actions, they are actually really good once you get over the initial hump.

by dkarlovi 6y ago

Twixes 6y ago
I love GH Actions so much, though would love dive into GitLab's CI/CD too if anyone has good resources on that.
- john_cogs 6y ago
  Here are some options depending on your learning preference: Video: https://www.youtube.com/watch?v=l5705U8s_nQ https://www.youtube.com/watch?v=l5705U8s_nQ Docs: https://docs.gitlab.com/ee/ci/quick_start/ https://docs.gitlab.com/ee/ci/quick_start/ Slides and a demo exercise: https://gitlab.com/gitlab-de/swiss-meetup-2021-jan https://gitlab.com/gitlab-de/swiss-meetup-2021-jan
- sjburt 6y ago
  Gitlab's CI/CD a minefield of bad design decisions piled upon each other. Not worth it unless you're stuck with it.
  - leesalminen 6y ago
    Honestly curious what bad decisions you’ve encountered? I’ve used Gitlab CI/CD on ~20 or so projects of varying complexity (small to enterprise) and have found it enjoyable to use each time.
  - solidnerd 6y ago
    Would be interested what are your current Problems ?
  - suicas 6y ago
    I'd be interesting in hearing more about some of these. We're currently using GitLab's CI/CD for ~50 or so private repositories, covering ~7 different languages without any issues. That includes testing, Docker builds and documentation generation for most projects. We only use private runners though, I don't know if any issues are related to their own runners.
    - sjburt 6y ago
      So runners are a good example: The runner config is stored in a config.toml on the runner. If you want autoscaling runners, it gets very complex so you might want to version control it or back it up, but you have to store your AWS secrets in this config.toml. It also contains hashes that have to be matched with settings in the UI, and of course, tags, which need to be tied into your .gitlab-ci. UI configuration changes take places instantly and there's no undo. So you have configuration in 3 places, only one of which is version controlled. And lets say you have some new runners with new tags -- you aren't going to be able to run an old pipeline on the new runner.
  - forty 6y ago
    Agreed with other commenters, we use gitlab CI extensively, and we find it great. That's the main reason we use gitlab, the code/repository part is not that great and we don't use the other stuff
  - huijzer 6y ago
    Talking about bad design decisions, I prefer GitLab's way to handle Pages over GitHub. It's just strange to store generated artifacts in a (`gh-pages`) branch. Instead, in GitLab it's stored as separate files and removed automatically after a certain period.

Invest time in GH actions, they are actually really good once you get over the initial hump.

Twixes 6y ago

I love GH Actions so much, though would love dive into GitLab's CI/CD too if anyone has good resources on that.

john_cogs 6y ago
Here are some options depending on your learning preference: Video: https://www.youtube.com/watch?v=l5705U8s_nQ https://www.youtube.com/watch?v=l5705U8s_nQ Docs: https://docs.gitlab.com/ee/ci/quick_start/ https://docs.gitlab.com/ee/ci/quick_start/ Slides and a demo exercise: https://gitlab.com/gitlab-de/swiss-meetup-2021-jan https://gitlab.com/gitlab-de/swiss-meetup-2021-jan
sjburt 6y ago
Gitlab's CI/CD a minefield of bad design decisions piled upon each other. Not worth it unless you're stuck with it.
- leesalminen 6y ago
  Honestly curious what bad decisions you’ve encountered? I’ve used Gitlab CI/CD on ~20 or so projects of varying complexity (small to enterprise) and have found it enjoyable to use each time.
- solidnerd 6y ago
  Would be interested what are your current Problems ?
- suicas 6y ago
  I'd be interesting in hearing more about some of these. We're currently using GitLab's CI/CD for ~50 or so private repositories, covering ~7 different languages without any issues. That includes testing, Docker builds and documentation generation for most projects. We only use private runners though, I don't know if any issues are related to their own runners.
  - sjburt 6y ago
    So runners are a good example: The runner config is stored in a config.toml on the runner. If you want autoscaling runners, it gets very complex so you might want to version control it or back it up, but you have to store your AWS secrets in this config.toml. It also contains hashes that have to be matched with settings in the UI, and of course, tags, which need to be tied into your .gitlab-ci. UI configuration changes take places instantly and there's no undo. So you have configuration in 3 places, only one of which is version controlled. And lets say you have some new runners with new tags -- you aren't going to be able to run an old pipeline on the new runner.
- forty 6y ago
  Agreed with other commenters, we use gitlab CI extensively, and we find it great. That's the main reason we use gitlab, the code/repository part is not that great and we don't use the other stuff
- huijzer 6y ago
  Talking about bad design decisions, I prefer GitLab's way to handle Pages over GitHub. It's just strange to store generated artifacts in a (`gh-pages`) branch. Instead, in GitLab it's stored as separate files and removed automatically after a certain period.