this post was submitted on 20 Jul 2023
392 points (95.6% liked)
Programming
17319 readers
114 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You can do almost everything with the Gitlab API so I'm curious what issue you had.
I'm also not sure why "Gitlab CI is the worst on the market"? I really like in particular that I can have my own gitlab-runner on any machine.
I want a build job to be triggered when a merge request is raised/changed to verify merge requests. Primarily I want it to comment/annotate changes so peer review focusses on logic and warnings are clear.
I can do this with Concourse, Circle, Jenkins and Github Actions on Azure Devops, Bitbucket Cloud, Bitbucket Server & Github. All Gitlab can tell you is pass/fail, which was good in 2003 but seriously lacking in 2023.
Similarly I want the ability to trigger a release and supply a desired version for the release (or someway to achieve that since our projects follow semantic versioning).
The release DSL is incomplete and could not work on server/cloud last time I used it. The page claims it can do alot but there is a hole in it and even the writer clearly knew.
I want the ability to specify multiple reusable pipelines, in a central place. This is not possible in cloud.
Lastly I would like to have multiple potential pipelines in a repository (e.g. smoke test and release). You can hack this in via variables. This will/won't work depending specifically on the runner for your job. if self hosted or cloud you'll notice different parsing behaviour depending on what host it runs on. This is shocking.
I have an email somewhere where I went through every GitLab CI DSL and documented which didn't consistently work, which only worked consistently on cloud and which only worked on server. Also things like release that are broken on both.
The only way to make it work is to use multi stage docker builds and if your doing that build bot and a bash script would be better.
All of what you said seems completely doable to me.
You can. See https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
CI_PIPELINE_SOURCE
You have full access to the API and can do whatever you want in the MR too.
You can, with CI templates. Templates can be in a completely different repository
I do have different pipelines for staging and production in my projects with no issue.
Try to do it and get back to me.
For extra fun try to do it in cloud and server, you'll realise some stuffis server only, some cloud only and the docs don't tell you which one is true
I'm only using the hosted version, it works. I do have a separate gitlab-runner in GCP at the moment though that is working fine.
If something doesn't work for you I suggest creating a ticket?