Shouldn't it be the responsibility of the forks' owners to maintain files for their CI servers?

If there are enough GitLab users I wouldn't mind adding this. Otherwise owners will need to rebase the change on every sync and sending a PR without that change. Doable but a pain.

I think it depends how many devs use GitLab. It's hard to keep track of that. I would like to see some 👍 from gitlab users.

I would suggest to try to use ./bin/ci script maybe setting some env vars before so there is no duplication w.r.t. what to run.

I would be against including any CI files in a project that the project does not use itself. They simply won't get maintained unless used.

@bcardiff I like the idea to re-use ./bin/ci so maintainability will be less of an issue (as @RX14 mentioned).

Lemme try

I was able to re-use ./bin/ci by adding a pseudo os "docker" to it (:eyes: @jhass).

The .gitlab-ci.yml looks more straightforward now, I think.

The builds are passing: https://git.zilium.de/splattael/crystal/pipelines/266

@splattael weren't you able to trigger on_linux for CI Lab?

I don't know if it makes sense to trigger docker within docker. The plain "docker:latest" image is not shipped with bash, so re-using bin/ci would have been difficult.

I've squashed both commits.

@bcardiff @jhass Any thoughts? Yay or nay? 😃

@splattael I still find disturbing that bin/ci needs to be modified.
I tried the following that will use docker in docker and won't need to modify bin/ci, but after doing cd to /builds/{user}/{project} it is not finding ./bin/ci although a ls shows it is.

A solution in this lines avoids the duplication of the docker image to be used that the current proposed changes still has.

If something like this can be accomplish I think we are fine to support forking in gitlab.

image: docker:latest

# https://docs.gitlab.com/ce/ci/docker/using_docker_build.html
variables:
  DOCKER_DRIVER: overlay

services:
  - docker:dind

variables:
  TRAVIS_OS_NAME: linux

.test-crystal: &test-crystal
  before_script:
    - cd /builds
    # cd /builds/{user}
    - cd $(ls -1 .)
    # cd /builds/{user}/{project}
    - cd $(ls -1 .)
    - ./bin/ci prepare_system
    - ./bin/ci prepare_build
  script:
    - ./bin/ci build

x86_64:
  <<: *test-crystal
  variables:
    ARCH: x86_64
    ARCH_CMD: linux64

i386:
  <<: *test-crystal
  variables:
    ARCH: i386
    ARCH_CMD: linux32

My concern is that if we merge CI configuration code for a CI platform that the core developers don't use, it sets a precedent for merging config for every CI software under the sun.

@bcardiff Interesting. I'll give it a try: https://git.zilium.de/splattael/crystal/pipelines

@RX14 I understand your concern but at least 2 Crystal users are willing to support .gitlab-ci.yml.
In any case, it's just one file which can easily be removed once really no one uses GitLab CI.

@bcardiff The working directory at the start of the build will be the project root, which happens to already be /builds/{user}/{project} without the cd $(ls -1 .) hackery.

@splattael Why do we need to specify a separate OS named "docker" here? Why not just reuse the existing linux one? Also, what's the benefit of placing commands in the before_script section versus script? Is there a re-run benefit where it caches the before_script state?

FWIW, I typically use gitlab.com as my primary platform, mirroring to github after the fact and using github for pull requests since it remains more popular.

@TheLonelyGhost You can see the latest .gitlab-ci.yml at https://git.zilium.de/splattael/crystal/blob/gitlab/.gitlab-ci.yml. Right now, I am having some difficulties to make the build pass.
See my desperation at https://git.zilium.de/splattael/crystal/pipelines

Any hints are welcome! 😃

I am going to close this PR as I am not able to re-use bin/ci using docker-in-docker 😞