docker-compose file refers to non-existant image

[JKHSDTV]

The docker-compose.yml file does not seem to work, it refers to an image named sameersbn/gitlab:17.6.0 which does not seem to resolve nor can I find it on Docker hub. Did something possibly go wrong with a release or tag ?

If it takes more time to release that's fine, don't want to rush anyone, but as the compose file is upgraded I figured it might not be intentional.

[kkimurak]

The release process (CI triggered by pushing a tag with a specific version number) is failing before publishing the image to Docker Hub due to a timeout (exceed 1h limitation). Either build it yourself or wait for a fix. The CI status is displayed to the right of the latest commit (it turns into a green check mark when successful).

[kkimurak]

Also, you can check if the release succeed by checking https://github.com/sameersbn/docker-gitlab/releases

[JKHSDTV]

Oh, I'm not worried about getting it myself, just wanted to notify that the current repo as it is isn't usable; meaning a new user who would check it out would not be able to run it (without knowing how to build it themselves). Like I said, I'm not in a rush.

[sachilles]

@kkimurak Unfortunately since GitLab version 17.6.0 our build time larger than 1 hour and overcomes to built time limit of 1 hour. Honestly, I tried to restart the CI several times and the result is always the same.

I guess, we should refactorize the entire build process or change the baseimage in order to reduce the build time. Do you have any thougts on this?

[kkimurak]

@sachilles yeah Yes, I received the CI timeout notification email. I'm really thankful for your usual work but it may be a time to do unusual work.

Some middleware (gitlab-shell, gitlab-workhorse, gitlab-pages, gitaly) are written in golang and uses only a single binary and configuration file. I believe these can be built using golang:${GOLANG_VERSION} image. This should eliminate the time it takes to compile golang itself (we need to pull the image but I believe it is much faster than compilation).
I'm also trying to split them up to form multi-stage builds. If all goes well, the middleware build should be able to be parallelized. But I'm not sure when can I complete it..

[sachilles]

Another way could be to use the ruby image. I don't know, which build process (go or ruby) takes more time.

[kkimurak]

I think we can use both - I mean build middlewares on golang image and do asset compile of gitlab itself on ruby image, then COPY binaries from each middleware builder to final image.
However, the fact that the codebase for the middleware that needs to be built in golang (gitlab-workhorse) is integrated into the gitlab mainframe is what is bugging me. the gitlab codebase is huge and it would be inefficient to clone it twice. I'm trying to figure out how to reuse the gitlab codebase for the one that builds workhorse and the one that runs gitlab.