@kkimurak The ci pipeline failed at stagetest by testing the image bootup. It failes due to connection issues:

• Hostname in DNS cache was stale, zapped
• Trying 127.0.0.1:80...
• connect to 127.0.0.1 port 80 failed: Connection refused
• Failed to connect to localhost port 80 after 0 ms: Connection refused

Is this related to numerous changes in theconfig.toml?

Do you have an idea how to proceed or make progress? How can we work together efficiently?

When I see the amount of changes, a four-eyes review would be the best. Do you have any objections and/or suggestions for a platform for real-time exchange?

Unfortunately, several GitLab critical security releases (15.0.1, 14.10.4, and 14.9.5) have been published yesterday (seehttps://about.gitlab.com/releases/2022/06/01/critical-security-release-gitlab-15-0-1-released/).

I guess we should maintain the official releases in parallel with this WIP PR. From your point of view, is there any reason not to at least merge the PR#2569 so that the security release can be prepared?

Sorry for late, I was bit busy.

@kkimurak The ci pipeline failed at stagetest by testing the image bootup. It failes due to connection issues:

• Hostname in DNS cache was stale, zapped
• Trying 127.0.0.1:80...
• connect to 127.0.0.1 port 80 failed: Connection refused
• Failed to connect to localhost port 80 after 0 ms: Connection refused

Is this related to numerous changes in theconfig.toml?

I think so. Maybe upstream config for[gitlab]::url inassets/runtime/config/gitaly/config.toml is not able to be applied directly./home/git/gitlab/tmp/sockets/gitlab-workhorse.socket is used in upstream config but we use/home/git/gitlab/tmp/sockets/gitlab.socket when we start gitlab workhorse.

note: I just copied and pasted upstream config, then started checking git diff.

Unfortunately, several GitLab critical security releases (15.0.1, 14.10.4, and 14.9.5) have been published yesterday (seehttps://about.gitlab.com/releases/2022/06/01/critical-security-release-gitlab-15-0-1-released/).

I guess we should maintain the official releases in parallel with this WIP PR. From your point of view, is there any reason not to at least merge the PR#2569 so that the security release can be prepared?

Just please merge#2569 and prepare for security release. I'm not sure v15.0.0 works but at least test is passing. And I have learned from history that the releasing is much important than missing (or stale) parameters for this project. Thank you for your work.

BTW, I'm going to work on this PR this weekend (since 2022-06-03T20:00:00+0900)

This sounds good. I can confirm that GitLab CE works at least for me in version 15.0.0 and 15.0.1. The only downside is that I do not use all features.

I just added an additional section about the state (important notes) of the release in the release notes.

I'm back, confirmed that gitlab works on relative URL enabled/disabled. Also simple git push/pull works.

Here're list of changes for configurations.

• gitaly
  • config.toml
    • add commented-out configruntime_dir
    • fix value for commented-out configtls_listen_addr (lacking trailing" )
    • add commented-out config for git (fetch.fsckObjects=true)
    • addcustom_hooks_dir : moved fromgitlab-shell configuration. seedeprecations page.TODO: parameterize?
    • move[gitlab] section before[[concurrency]] section
    • add section[gitlab.http-settings]
      • TODO: apply parameters
    • add many more commented-out configurations for resource limitation
• gitlab-pages
  • config
    • addlisten-http,pages-root,pages-domain
    • sort based on upstream config
• gitlab-shell
  • config.yml
    • add comment forgitlab_relative_url_root (we don't usehttp+unix:// protocol so we have nothing to do)
    • remove deprecatedhttp_settings::self_signed_cert : seeupstream mr 602 : since v13.26.0, v14.0.0
    • addssl_cert_dir:TODO maybe we need to set it usingSSL_CERTIFICATE_PATH, but this is the path for file itself. We need directory path.
    • default log format is changed to json : seeupstream MR 476 : since v13.21.0
• gitlabhq
  • database.yml: No notable update. just added commented-outload-balancing configurations
    • stale: official documentation says thatDB_POOL (pool: indatabase.yml) is not very practical and gitlab override the number of allowed connections in the database connection-pool based on the configured number of application threads. Seedocs about client-side connection pool
  • gitlab.yml: too many changes
    • Merge Request -> merge request
    • add header note for those who submitting MR
    • some URLs for docs are updated. Eg.http://doc.gitlab.com/ce is changed tohttps://docs.gitlab.com/ee
    • some empty line are removed
    • add commented-out configgitlab:cdn_host to support Rails asset host: seeupstream MR 67710 : since v14.2.0 :TODO: parameterize?
    • removeunicorn from comment, now onlyPuma configurations are written.
    • addgitlab:allowed_hosts to controlRails.application.config.hosts : seeupstream MR 55491 : since v13.10.0 :TODO: parameterize?
    • add commented-out configgitlab:email_smtp_secret_file: seeupstream MR 67802 : since v14.2.0 :TODO: parameterize?
    • add commented-out configgitlab:application_settings_cache_seconds : seeupstream MR 51889 : since v13.9.0 :TODO: parameterize?
    • add commented-out configdisplay_initial_root_password (default tofalse): Security commit, no MR. seeupstream commit b48d80d : since v14.5.0
    • many update onincoming_email section. They are all commented out.q
    • addobject_store section on top-level as default value :TODO: parameterize? (need to check compatibility withGITLAB_OBJECT_STORE_CONNECTION_PROVIDER and so on)
    • addlocal_store section on top-level : seeupstream MR 55470 : since v13.11.0
    • addpackages:dpkg_deb_path ; seeupstream MR 44029 : since v13.6.0
    • renamepackages:path topackages:storage_path
    • addci_secure_files section for secure files API: seeupstream MR 78227 : since v14.8.0 :TODO: parameterize?
    • add commented-out configldap:secret_file
    • add commented-out configldap:servers:main:retry_empty_result_with_codes
    • add commented-out configkerberos:simple_ldap_linking_allowed_realms
    • add commented-out configomniauth:saml_message_max_byte_size
    • addforti_authenticator section for one time password method : seeupstream MR 45055 : since v13.5.0
    • addforti_token_cloud section
    • addencrypted_settings section and commented-out configentrypted_settings:path
    • removegitaly:client_path : seeupstream MR 61987 : since 14.0.0
    • some additional configs forbackup:upload
    • removepseudonymizer configurations : seeupstream MR 86087 : since v15.0.0
    • many update oncron_jobs (also onee_cron_jobs that we don't use) : deleted or modified schedules ware not parameterized.
    • many more updates on non-production (develop/test) settings
  • puma.rb: No notable changes for us.
    • shorter call forGitlab::Cluster::PumaWorkerKillerInitializer.start
    • additional behavior via environment variablePUMA_WAIT_FOR_LESS_BUSY_WORKER (default to 0.001) andDISABLE_PUMA_NAKAYOSHI_FORK
    • add low-level error handling to Sentry. Seeupstream MR 66712
  • resque.yml: No notable changes.
    • Merge Request -> merge request
    • DB wording: slave -> replica
    • update URL for docs
  • secrets.yml: No notable changes for configuration.
    • note: minimum secret key length is increased from 30 chars to 32 chars. first introduced: v13.12.0 : seeupstream MR 53602
    • note: Do we need to parameterizeopenid_connect_signing_key andencrypted_settings_key_base?
  • smtp_settings.rb: NO notable changes for configuration.
    • Merge Request -> merge request
    • add commented-out configurations example for those who uses encrypted smtp credentials.
      to achieve this, add local variablesecrets to referGitlab::Email::SmtpConfig.secrets.{user_name,password}

note:http+unix protocol is used in some configuration but I kept traditional valuehttp://localhost:8181{GITLAB_RELATIVE_URL} for simplicity.

Additional note: I have noticed that puma dies on startup so that gitlab did not come up. I have submit a separate PR#2579

Now I can continue developing thanks to#2579 is merged

@sachilles Is there a backporting request? If so, I'll split the commit to make it easier (although it will take some time, of course).

@kkimurak If we will be able to merge in the near future, I'd like to avoid backporting.

@kkimurak Sorry for the extremely long delay in processing this PR. Can we try to incorporate this PR next (and before the next release of GitLab)?

Hi@sachilles , I apologize for leaving the pull request for so long.
I thought a lot, but I want to split this PR into some feature-based individual PRs (and minor typo PRs). This PR contains too many changes so that make diff larger, it makes harder to review the functionality.

As usual, the new version of GitLab will be released on the 22nd. I'm sorry, but I've been busy with work this month and it may be difficult to get things done (including checking against the new release, rebase on some concurrent works e.g.#2598#2610 ) by then. I think I will be able to work on it in early October.

I'm still busy and progress is slow, but the work is definitely nearing completion. Most of the changes were cleaned up and sorted by released tag. A little work left over from v15.4 and confirmation of new additions in v15.5 is required.
Anyway, I'm really sorry I'm a month late to do just this. I hope I can work on in a week...

I also want to split them into separate pull requests for easier review.
I haven't decided where to split it, but if you have any suggestions (and requests for access via configuration parameters that are currently largely untouched) I'd be happy to hear them.