Skip to content
Snippets Groups Projects

Configuration options in gitlab.rb

Merged Marin Jankovski requested to merge configuration_options into master

Related to #356 (closed)

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Author Maintainer

    Currently all settings are listed in doc/settings/gitlab.rb.example.

    The layout is as follows:

    • Required section - lists the minimal settings required for gitlab to be setup
    • Optional section - everything else

    Inside of optional section we have:

    • GitLab settings in order: gitlab.yml settings; application, database, smtp, redis and initialisers settings
    • GitLab settings related to external services: users,gitlab-shell, unicorn, sidekiq, redis, database, nginx, logging
    • CI settings in order: application.yml settings; database, smtp, redis
    • CI settings related to external services: ci users, ci unicorn, ci sidekiq, ci redis, ci database, ci nginx

    I am unsure if it would be better to have a different layout, maybe:

    • GitLab: gitlab.yml and application, database etc settings
    • GitLab CI: application.yml, database etc settings
    • External services: users, database, redis etc.

    First approach (the one in the MR) groups per GitLab, GitLab CI.

    Second approach groups per service: GitLab, CI, database etc.

    Since I am unsure which approach is more user friendly, I am open for suggestions.

    @all

  • I think the current layout makes more sense than the alternative.

    Everything that concerns GitLab should be together, same with CI.

  • @marin Sorry, didn't see the WIP tag. I would advise against two levels (required, non-required). Just mark the url clearly as required (in title, add note that this is the only thing required). And comment out all the other options.

  • Thanks for this work @marin :)

    I'm in favor of the second approach, list everything per service, but on the other hand we would have two databases, two redis, etc. for GitLab and GitLabCI, which could be confusing.

    As for the optional settings, I agree with @sytses, comment out them. One good path would be to write description comments with double ## and settings comments with one #.

  • I also agree with commenting out as much as possible. The more is uncommented in the default gitlab.rb, the harder it is for the Omnibus maintainers to update defaults in the future.

  • Marin Jankovski Added 1 new commit:

    Added 1 new commit:

    • bb460c5d - Remove unecessary nesting in headers for example gitlab.rb.
  • Marin Jankovski Added 2 new commits:

    Added 2 new commits:

    • dc4a299d - Update the settings template.
    • a366bfb5 - Add the configuration options to gitlab.rb.
  • Author Maintainer

    Updated after discussion with @jacobvosmaer

  • Marin Jankovski Added 1 new commit:

    Added 1 new commit:

  • Marin Jankovski Added 5 new commits:

    Added 5 new commits:

    • 8bd39ba9 - Give better examples of that the external url should include a protocol.
    • 8add502a - Merge branch 'include-protocol' into 'master'
    • 4b5f7df8 - Remove aws information from readme.
    • 0a6320ab - Merge branch 'aws_readme' into 'master'
    • 7225d100 - Merge branch 'master' into configuration_options
  • @marin Looks better. Consider having the comments outside of the # rectangles (just place them below the rectangle).

  • Marin Jankovski Added 1 new commit:

    Added 1 new commit:

    • 0bc9d55a - Move the comment blocks out of the headers.
  • Marin Jankovski mentioned in merge request !260 (closed)

    mentioned in merge request !260 (closed)

  • mentioned in commit 6080f125

  • Marin Jankovski mentioned in merge request !263 (closed)

    mentioned in merge request !263 (closed)

  • Please register or sign in to reply
    Loading