sameersbn
docker-compose file refers to non-existant image
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.
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).
Also, you can check if the release succeed by checking https://github.com/sameersbn/docker-gitlab/releases
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.
@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?
@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..
Another way could be to use the ruby image. I don't know, which build process (go or ruby) takes more time.
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.
By the way, I realized that bundle install for gitlab-shell may not be necessary, at least for compilation (it seems to be used only for testing).
https://github.com/sameersbn/docker-gitlab/blob/76dad7812405afada9701b81fa1cf714fdaaf021/assets/build/install.sh#L123-L125
When I deleted these 3 lines, I was able to reduce the build time by about 2 minutes in my environment.
I have not yet confirmed whether gitlab-shell works properly in runtime, but if this change does not cause any problems, we may be able to reduce the CI of the release process to an hour with this small change.
Is the limit combined or per job ? If it's per job, why not split up the install.sh script into multiple parts ? I would think reducing the build time by 2 minutes would at best be a stop gap until the next upstream change makes it take a bit longer again. Cut the install script in half (at the elapsed time half, not the line half), persist the results of the first run as an intermediate image, then run the second half with that as base image, wouldn't that work ?
@JKHSDTV
why not split up the install.sh script into multiple parts ?
Yes, that's what I'm suggesting above.
Do you plan to submit a PR soon? I'm going to be busy until this weekend and I don't think I'll have time to do the splitting work or build the image locally. I'd really appreciate it if someone could do that.
Not me, I've never worked with CircleCI before nor do I have any way to test it. It's not impossible I'll find some time over the holidays (it's a 'simple' Docker build, so I should be able to do the gross of the work with just local Docker, right ?) but no promises
@sachilles
Is it possible to add me as an administrator on sameersbn/docker-gitlab on CircleCI, so that I can transfer my paid plan to it?
I have done several validation builds and have no effective time-saving results at this time.
I have also noticed that the rake task gitlab:assets:compile takes roughly 75% of the build time.
So, I see no quick fix for this problem.
An interim solution is to upgrade the CircleCI plan to Performance. This will increase the build time limit to 3 hours. It seems that plan can be transfered to an organization which I have admin access (see https://circleci.com/docs/credits/#share-plans-across-organizations-billed-centrally).
@kkimurak @sachilles did you consider the option to move the build on GitHub Actions, seems that the job timeout is generous. I'm unsure if maintainer access is required to run a GitHub Actions workflow for the first time as I only used in repos where I have maintainer rights.
If you think this path valuable I might find some time to test creating a GitHub Action workflow to run the build step.
@avvertix Yeah GitHub actions is alternative way. However, the token for uploading to docker hub should be registered as a CircleCI environment secret, so it should be impossible to publish it to the sameersbn namespace (Since we are talking about namespace migration, I don't think this will be a problem).
@kkimurak I'm testing the build workflow in https://github.com/avvertix/docker-gitlab/pull/1 it seems that the build alone takes roughly 45 minutes
Probably once I'll open the pr someone with rights should confirm so that actions are triggered. Let's see if I can get the whole Circle CI script conversion right and then we will see if runs. The point, as you mentioned, would be to ensure that the push can happen on Docker Hub. Maybe there we can use GitHub Packages as a possible alternative, the container registry should be free to use, the only point is that a maintainer must approve the first push to the registry and allow workflows to publish there.
I saw in https://github.com/sameersbn/docker-gitlab/issues/3042#issuecomment-2575748329 that options to move to a multi-stage build are in progress. I guess that work could be valuable to figure out ways to reduce the build time (and possibly the weight of those images).