71–80 of 80 posts
Apple started using GitLab internally after switching off of GHE years ago. Not surprised at all by this
This tweet is, unsurprisingly, too light on details. I wonder what the plus for Xcode is here? I'm sure it already had Git integration. Is Xcode getting project, issue, merge-request etc. management support? And they chose to start that with (or exclusively base it on) GitLab?
As others have said, support for two platforms was added. And GitHub was already supported. Guess that doesn’t make a great headline though.
Our team loves Gitlab. We have had a bunch of slow responses today. Also lots of CI/CD glitches yesterday and today... but we recognize this is just due to the exodus so we know it will go back to normal - we're just laughing about it a bit.
Earlier quoted context omitted.
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.
> 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…
"Everything programming eventually drops down to metal one way or another."
Keeping with the trog theme...
I need things to be as explicit as possible.
I just couldn't figure out why my script commands were not doing variable substitution. I expected my line ' - echo id: $CI_BUILD_ID' to cut and paste 'echo id: $CI_BUILD_ID' to the command line and run that bad boy as-is. And I'd see the expected output in the log. Just like if I run 'echo id: $CI_BUILD_ID' locally.
What could be more simple?
Nope.
gitlab-ci does some ninja code escape mangling thing (turn on debugging output to see it in action). So in your log you continue to see 'echo id: $CI_BUILD_ID' instead of 'id: 123456'.
I have no idea why anyone would do that.
I want to run commands. Why not just run them as-is? Why the obfuscation layers?
--
Inevitably, abstraction layers introduce an impedance mismatch, where some behavior will surprise you, where you have to do a workaround. Then you're fighting the tool instead of solving your problem directly. Then you say "fuck it" and just have the layer call your loose code (eg shell script) directly. Then what's the point of having the layer at all?
Earlier quoted context omitted.
> 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…
I'm a simple cave man. I don't understand why there needs to be an execution graph. Conditional logic? "Everything programming eventually drops down to metal one way or another." Keeping with the trog theme... I need things to be as explicit as possible. I just couldn't figure out why my script commands were not doing variable substitution. I expected my line ' - echo id: $CI_BUILD_ID' to cut and paste 'echo id: $CI_…
Of course. You may have different requirements, but here's an example flow of the one project I had worked on:
Lint --------------------
\
Build -+-- Tests (fast) --+-- Release --- Deploy
\ /
- Tests (slow) -
Lint runs in parallel with build + test (multiple runners, on different machines, each having some concurrency). Different tests run in parallel so you have to wait a little less. Tests only run after build is ready. Release only runs if both lint and tests succeed. Deploy is after the release.
You can write this graph as a shell script, but this is not without downsides:
1. You need a DSL (a bunch of pre-defined shell functions or external commands) that control the individual jobs in a sane manner.
2. You can't just look at the script and draw the pipeline graph (so before the pipeline's ran CI/CD can't tell you what's going to happen next).
3. You can't guarantee that the plan will be the same if pipeline is re-ran again. With shell scripts, program output may change, even though all inputs are the same.
If all you need is to run a simple shell script, with no multi-machine parallelism and no fancy conditional logic - all of the YAML stuff is an overkill you don't need. Although I guess all you need is approximately this:
run-ci:
script:
- ./run-ci.sh
> gitlab-ci does some ninja code escape mangling thing (turn on debugging output to see it in action). So in your log you continue to see 'echo id: $CI_BUILD_ID' instead of 'id: 123456'.
Not sure I've encountered this much, but yes, this probably makes things complex. I agree that this is can be a pain point.
> I have no idea why anyone would do that.
I'm not sure, but the probable rationale is likely that they didn't want secrets to leak. Variables are the place where you can store various secret information, like CI signing keys or remote server credentials. They probably didn't want to leak what happens with e.g. `curl --user "ci:$CI_DEPLOY_PASSWORD" "$CI_DEPLOY_URL"`.
Earlier quoted context omitted.
Yep, it was busy and we had to scale up but we're on top of it now. Thanks for your patience! https://twitter.com/mdelaossa/status/1003805667394834432
Sorry, but you really aren't, quite yet. I'm trying to import a very small repo from github (literally 1 branch and 2 files with hardly any revisions and no issues) and it's still sitting there showing "Starting...". I had tried to mass import a lot and after 11+ hours of "Starting..." I decided to remove them and just try one at a time. Still no luck after almost 20 minutes.
This tweet is, unsurprisingly, too light on details. I wonder what the plus for Xcode is here? I'm sure it already had Git integration. Is Xcode getting project, issue, merge-request etc. management support? And they chose to start that with (or exclusively base it on) GitLab?
This is good.
Honestly, pretty much al of Yesterday's news from WWDC was great (I'm especially excited for the multi-cursor thing) the only bad news (and it was terrible) was about OpenGL/OpenGL ES/OpenCL support being deprecated.
Our team loves Gitlab. We have had a bunch of slow responses today. Also lots of CI/CD glitches yesterday and today... but we recognize this is just due to the exodus so we know it will go back to normal - we're just laughing about it a bit.
Thing is it’s not even an exodus. It’s just a few thousand repos. And they aren’t even prepared to handle that. If there actually was a mass migration GitLab would completely fall over. I’m sure that would give folks a lot of confidence in the platform though.
This tweet is, unsurprisingly, too light on details. I wonder what the plus for Xcode is here? I'm sure it already had Git integration. Is Xcode getting project, issue, merge-request etc. management support? And they chose to start that with (or exclusively base it on) GitLab?