4 ms·

I'm impressed how far GitLab has come in a short amount of time. It's a pretty well-designed platform, when it comes down to it. I think the Vue-based user inte

I'm impressed how far GitLab has come in a short amount of time. It's a pretty well-designed platform, when it comes down to it. I think the Vue-based user interface and the data model are probably the cornerstones of it, and using Ruby on the backend just helps them iterate quickly. Ruby also seems to be getting more robust [1]. Their CI/CD platform is really a great approach, emphasizing the GitLab Worker as a portable CI runner that communicates through the API. For resource-intensive apps it helps to not have the number and size of CI workers be limited by a SaaS plan like they tend to be with other CI/CD platforms. [1] https://githubengineering.com/removing-oobgc/ https://githubengineering.com/removing-oobgc/

sytse 8y ago
Thanks for your kind words, we appreciate it! It has been a crazy day https://twitter.com/gitlab/status/1003779174631235585 https://twitter.com/gitlab/status/1003779174631235585
- enroxorz 8y ago
  One of my favorite features from GitLab is, without having to install any other tool, I can get a link from the response to create my MR. Such a simple feature, yet so convenient.
  - singularity2001 8y ago
    can you elaborate on this feature?
    - jobvandervoort 8y ago
      If you push a new branch to a GitLab project, we return a URL to immediately create a merge requests, which appears in the Git output in your terminal. So rather than going to GitLab, then clicking on a button, you just click the link in your shell.
singularity2001 8y ago
The term CI/CD suddenly appears everywhere. Can «continuous integration and continuous delivery» be shortened to CI&D or CIaD? Or how do you pronounce CI/CD? AC/DC backwards?
- dandr01d 8y ago
  Is 4 letters really too long? I pronounce it Sea Eye Sea Dee.
specialist 8y ago
Builds should just be done with shell scripts. I recently crossed swords with .gitlab-ci.yml. An obfuscation layer that fights back. Ditto jenkinsfile and whatever you wanna call GoCD's config.xml. This silliness reminds me most of all those ETL workflow obfuscation frameworks, like BizTalk and TalenD. PS- If anyone has the bad judgement to use YAML, it'd be nice if the linter reported something more specific than "syntax error line 1 char 1" for deeply buried typos. I thought XML sucked until I met JSON. I thought JSON sucked until I met YAML. What's next? The resurrection of ASN.1? PS2- It's not programming if you can't set a break point. The edit, eval, fail, profanity loop for troubleshooting .gitlab-ci.yml is pretty intense.
- drdaeman 8y ago
  > Builds should just be done with shell scripts You still need something to describe the order and dependencies of those shell scripts as well as when to run them (branches, tags) and how to handle the artifacts (expiry time, etc). Which should be, much preferably, something not Turing-complete, so you can make an UI for this. Draw the graph, etc etc. Take those parts out, and almost all what's left in .gitlab-ci.yml is just the `script` key. You can debug most things locally (without having to do that ugly commit-try-fail-repeat dance) with https://docs.gitlab.com/runner/commands/#gitlab-runner-exec https://docs.gitlab.com/runner/commands/#gitlab-runner-exec
  - specialist 8y ago
    Turing complete? What? If your visual programming fuzzy whatzzit drops down to metal (shell commands in this case), just use the metal. I did get the git-runner to run locally. That was fun. Why do I have to commit my changes to my local branch so the git-runner can see them? MY CODE IS RIGHT THERE! I reiterate: Just use shell scripts.
    - drdaeman 8y ago
      > Turing complete? What? You'll need to run the CI pipeline to figure out the execution graph. In a restricted language, you don't have to - it can just describe that graph. > If your visual programming fuzzy whatzzit drops down to metal I don't get you. Everything programming eventually drops down to metal one way or another. It is not about visual programming, it's about the appropriate languages. Shell scripts are not exactly appropriate to describe a graph. Especially a graph meant to be ran on a distributed system - so, really, *sh may be not the best fit here. Maybe you have some better idea, but I'm just afraid you'll end up with some shell-based DSL that would be no better than YAML, but suffer from all possible issues (for example, there's no concept of pure functions in shell scripting, so every CI run plan can take completely different shape) Oh. If you're a person who likes all their configuration files being programs - then I won't argue as it'll be a matter of taste. > Why do I have to commit my changes to my local branch so the git-runner can see them? Yeah, I'm also disappointed in this. It was dismissed as "wontfix" a while ago https://gitlab.com/gitlab-org/gitlab-runner/issues/1545 https://gitlab.com/gitlab-org/gitlab-runner/issues/1545 and seems that it stays this way even now (they've deprecated `exec` at some point but then reconsidered). Had to write myself an alias for `git commit --amend && gitlab-runner exec`

sytse 8y ago

Thanks for your kind words, we appreciate it! It has been a crazy day https://twitter.com/gitlab/status/1003779174631235585 https://twitter.com/gitlab/status/1003779174631235585

enroxorz 8y ago
One of my favorite features from GitLab is, without having to install any other tool, I can get a link from the response to create my MR. Such a simple feature, yet so convenient.
- singularity2001 8y ago
  can you elaborate on this feature?
  - jobvandervoort 8y ago
    If you push a new branch to a GitLab project, we return a URL to immediately create a merge requests, which appears in the Git output in your terminal. So rather than going to GitLab, then clicking on a button, you just click the link in your shell.

singularity2001 8y ago

The term CI/CD suddenly appears everywhere. Can «continuous integration and continuous delivery» be shortened to CI&D or CIaD? Or how do you pronounce CI/CD? AC/DC backwards?

dandr01d 8y ago
Is 4 letters really too long? I pronounce it Sea Eye Sea Dee.

specialist 8y ago

Builds should just be done with shell scripts. I recently crossed swords with .gitlab-ci.yml. An obfuscation layer that fights back. Ditto jenkinsfile and whatever you wanna call GoCD's config.xml. This silliness reminds me most of all those ETL workflow obfuscation frameworks, like BizTalk and TalenD. PS- If anyone has the bad judgement to use YAML, it'd be nice if the linter reported something more specific than "syntax error line 1 char 1" for deeply buried typos. I thought XML sucked until I met JSON. I thought JSON sucked until I met YAML. What's next? The resurrection of ASN.1? PS2- It's not programming if you can't set a break point. The edit, eval, fail, profanity loop for troubleshooting .gitlab-ci.yml is pretty intense.

drdaeman 8y ago
> Builds should just be done with shell scripts You still need something to describe the order and dependencies of those shell scripts as well as when to run them (branches, tags) and how to handle the artifacts (expiry time, etc). Which should be, much preferably, something not Turing-complete, so you can make an UI for this. Draw the graph, etc etc. Take those parts out, and almost all what's left in .gitlab-ci.yml is just the `script` key. You can debug most things locally (without having to do that ugly commit-try-fail-repeat dance) with https://docs.gitlab.com/runner/commands/#gitlab-runner-exec https://docs.gitlab.com/runner/commands/#gitlab-runner-exec
- specialist 8y ago
  Turing complete? What? If your visual programming fuzzy whatzzit drops down to metal (shell commands in this case), just use the metal. I did get the git-runner to run locally. That was fun. Why do I have to commit my changes to my local branch so the git-runner can see them? MY CODE IS RIGHT THERE! I reiterate: Just use shell scripts.
  - drdaeman 8y ago
    > Turing complete? What? You'll need to run the CI pipeline to figure out the execution graph. In a restricted language, you don't have to - it can just describe that graph. > If your visual programming fuzzy whatzzit drops down to metal I don't get you. Everything programming eventually drops down to metal one way or another. It is not about visual programming, it's about the appropriate languages. Shell scripts are not exactly appropriate to describe a graph. Especially a graph meant to be ran on a distributed system - so, really, *sh may be not the best fit here. Maybe you have some better idea, but I'm just afraid you'll end up with some shell-based DSL that would be no better than YAML, but suffer from all possible issues (for example, there's no concept of pure functions in shell scripting, so every CI run plan can take completely different shape) Oh. If you're a person who likes all their configuration files being programs - then I won't argue as it'll be a matter of taste. > Why do I have to commit my changes to my local branch so the git-runner can see them? Yeah, I'm also disappointed in this. It was dismissed as "wontfix" a while ago https://gitlab.com/gitlab-org/gitlab-runner/issues/1545 https://gitlab.com/gitlab-org/gitlab-runner/issues/1545 and seems that it stays this way even now (they've deprecated `exec` at some point but then reconsidered). Had to write myself an alias for `git commit --amend && gitlab-runner exec`