As a result, an Internet connection is no longer required
to use relative URLs.
To enable relative url, we execute `gitlab:assets:compile`.
This have been removed in official documentation in v10.0.0
(first committed to gitlab-foss, then ported to gitlab(-ee))
- EE: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1139/
- CE: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8831
An internet connection was required when enabling relative urls
to install the node modules required for compilation.
I reviewed the rake task `gitlab:assets:compile` and investigated
whether it was necessary to compile all assets
just because the relative url changed,
and found that this rake task is internally a separate rake task
`gitlab:assets :fix_urls` which rewrite the reference URL in the css.
I removed rake task `gitlab:assets:compile` at runtime
and confirmed that the gitlab application worked normally as before.
I have confirmed that at least the following functions work properly.
- Administrator password reset at first login
- Create empty project
- Edit/add and commit files using web IDE
- Create merge request/issue
- Attach files to comments
- Create empty group
- Move existing project to group
In addition, we no longer need to do following things
- persist node_modules, recompiled assets and caches
- apply patches to gitlab itself to avoid removing (symlink to) node_modules/
This change also reduces startup time in certain cases
when the relative URL feature is enabled
(when assets are compiled; for example,
when performing a version upgrade or changing the relative URL)
(on my environment, `gitlab:assets:fix_urls` took about 20 seconds)
Because this is required on runtime
and BUILD_DEPENDENCIES will be removed at the end of installation
Installation of `libyaml-dev` is written in Dockerfile
so additional installation is not reeded
if not, following error reported on runtime
> LoadError: libyaml-0.so.2: cannot open shared object file: No such or directory - /usr/local/lib/ruby/3.2.0/x86_64-linux/psych.so
This is because Ruby 3.2.0 (psych 5.0.0) or later
does not contain libyaml any more
https://github.com/ruby/psych/pull/541
Backport: fix behavior of `SecureRandom.gen_random_openssl(n)`
commit:
64e503eb62
This has been merged into the Ruby 3.3 release, but Ruby (at least) 3.0 and later are affected by the issues fixed by this commit.
`Dir.exists?(file_name) -> bool` have been deprecated since Ruby 2.1
and removed on Ruby 3.2.
See https://bugs.ruby-lang.org/issues/17391
Replacement is `Dir.exist?(file_name) -> bool`.
GitLab does not launch after second run if relative url is used.
This is caused by following upstream change to remove assets directory on assets compile.
See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/103715
This is introduced on v15.6.0
````sh
$ git -C ../gitlab.git/ tag --contains e46d92c0 | sort --version-sort | head -n 1
v15.6.0-ee
````
1. `sameersbn/gitlab` create symbolic link /home/git/gitlab/public/assets/
to point /home/git/data/tmp/assets if relative url is used.
This is to store assets in the docker volume to avoid unnecessary recompilations.
These assets are removed and recompiled only when the gitlab version or relative url root is changed.
2. By the change provided by gitlab.com/gitlab-org/gitlab!103715,
rake task `gitlab:assets:compile` became to remove assets directory directly (by `FileUtils.rm_rf()`).
It does not remove compiled assets itself, but remove symlink /home/git/gitlab/public/assets .
Then it compiles assets as usual, but they will be stored in newly-created normal directory /home/git/gitlab/public/assets/
3. On container down, whole container statement (except volumes) will be reset.
These compiled assets will be removed as well because they are not in docker volume.
4. As we store version info and relative url root path to /home/git/data/tmp/,
we cannot recognize we have to recompile assets (that have been removed by mistake)
To avoid the issue, this commit add a build time patch to change the behavior of rake task `gitlab:assets:compile`
to empty assets instead of removing assets directory itself.
There was an issue that `ajv` is not installed by mistake.
This issue have been fixed on upstream, a few years ago.
Now, we can revert the change.
This commit partially reverts 985d57afb9673b2f5acb1f12cbc13f230f6ec074
See sameersbn/gitlab#1358
It seems that fix MR on upstream is https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14543
but we cannot check diff because source / target branch removed by mistake
Anyway, no need to add ajv as an explicit dependency with (at least) gitlab v11 or later
note: Only affected if using the relative_url feature
`gitlab/script/frontent/preinstall.mjs` is introduced since v16.4.0.
This script is executed on container startup, if using the relative url.
This script removes `NODE_MODULES` (/home/git/gitlab/node_modules) when
"the folder seems to end up being a corrupted somehow"
See more detail:
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/130938
On sameersbn/gitlab, the folder node_modules is declared as volume.
The volume is always busy so that cannot be removed in the container.
You can see following error reported on container startup
(sameersbn/gitlab:16.4.0 or later).
````
yarn install v1.22.19
$ node ./scripts/frontend/preinstall.mjs
[WARNING] package.json changed significantly. Removing node_modules to be sure there are no problems. node:internal/process/esm_loader:97
internalBinding('errors').triggerUncaughtException(
^
[Error: EBUSY: resource busy or locked, rmdir '/home/git/gitlab/node_modules'] {
errno: -16,
code: 'EBUSY',
syscall: 'rmdir',
path: '/home/git/gitlab/node_modules'
}
Node.js v18.17.1
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command. -----
````
This PR add a build time patch to change the behavior of
script/frontend/preinstall.mjs to not to remove node_modules directly,
but empty it instead.
`assets/build/config/database.yml.postgresql` is owned by root:root,
and permission is rwxrw----
so the user `git` (`${GILTAB_USER}`) doesn't have a permission to copy the file.
This raises an error while building.
This allows to the client to explicitly select protocol version 2, which is much more efficient. Without allowing that environment variable it seems that SSH connections are always stuck in version1. See https://docs.gitlab.com/ee/administration/git_protocol.html on how to check if protocol 2 is used.
Sidekiq is updated to v6.0 here (first contained tag: v14.4.0-ee)
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69655
In Sidekiq 6.0, these options have been marked as "deprecated":
-P (set pid file)
-L (set log file)
See https://github.com/sidekiq/sidekiq/commit/3f5b1c5
Now, we can see error message in {GITLAB_LOGS_DIR}/supervisor/sidekiq.log
like below:
----
ERROR: PID file creation was removed in Sidekiq 6.0, please use a proper process supervisor to start and manage your services
ERROR: Logfile redirection was removed in Sidekiq 6.0, Sidekiq will only log to STDOUT
----
Just stop using this option.
- [git] set advice.detachHead=false
- [bundle] use `bundle config set --local` instead of
- `--deployment`
- `--with` / `--without`
arguments for `bundle install`
