This project is mirrored from https://:***** Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 16 Oct, 2020 1 commit
  2. 14 Oct, 2020 1 commit
  3. 28 Aug, 2020 1 commit
  4. 11 Aug, 2020 1 commit
  5. 13 Jul, 2020 1 commit
  6. 08 Jul, 2020 1 commit
  7. 30 Jun, 2020 1 commit
  8. 25 Jun, 2020 1 commit
  9. 03 Jun, 2020 1 commit
  10. 26 Feb, 2020 1 commit
    • Stan Hu's avatar
      Move PostgreSQL runtime logging configuration to runtime.conf · 22420d18
      Stan Hu authored
      As discussed in, many of
      the logging parameters can be changed at runtime. Those that have a
      context of `sighup` can be reloaded with a SIGHUP and not require a full
      database restart.
      gitlabhq_development=# select name, context from pg_settings where name like 'log_%' order by context;
                  name             |      context
       logging_collector           | postmaster
       log_checkpoints             | sighup
       log_destination             | sighup
       log_directory               | sighup
       log_autovacuum_min_duration | sighup
       log_file_mode               | sighup
       log_filename                | sighup
       log_hostname                | sighup
       log_line_prefix             | sighup
       log_rotation_age            | sighup
       log_rotation_size           | sighup
       log_timezone                | sighup
       log_truncate_on_rotation    | sighup
       log_lock_waits              | superuser
       log_min_duration_statement  | superuser
       log_min_error_statement     | superuser
       log_min_messages            | superuser
       log_parser_stats            | superuser
       log_planner_stats           | superuser
       log_replication_commands    | superuser
       log_statement               | superuser
       log_statement_stats         | superuser
       log_duration                | superuser
       log_error_verbosity         | superuser
       log_executor_stats          | superuser
       log_temp_files              | superuser
       log_disconnections          | superuser-backend
       log_connections             | superuser-backend
      (28 rows)
  11. 21 Feb, 2020 1 commit
  12. 23 Oct, 2019 1 commit
  13. 02 Oct, 2019 1 commit
    • Ian Baum's avatar
      Updates per the MR · d6d1b767
      Ian Baum authored
      * Rename enabled? to service_dir_enabled?
      * Add changelog
      * Remove dev cruft
  14. 30 Sep, 2019 1 commit
  15. 12 Aug, 2019 1 commit
  16. 09 Aug, 2019 1 commit
  17. 24 Jun, 2019 1 commit
  18. 13 May, 2019 1 commit
  19. 31 Jan, 2019 1 commit
  20. 17 Jan, 2019 1 commit
  21. 09 Nov, 2018 1 commit
    • DJ Mountney's avatar
      Update the postgresql bin command to look in the correct directory · b2fa5b9b
      DJ Mountney authored
      Fix errors with regex espression
      Update tests for the new bin behaviour
      Update pg-upgrade with the correct dir information for the move to the
      major dir
      Add tests for the pg_version library
      Stub out the running db version in the db tests
      Fix rubocop error
      Symlink in the old postgres install directory in order to keep upgrade
      Use relative symlink in order to survive packaging process
      Move the old postgres dir symlink into postinst
      Use the proper directory test for symlink creation
      Avoid automatic restarts of the postgres runit service
      Update the geo-postgres spec with some missing PGVersion syntax
      Fix duplicate method running_version
      In base_pg_helper
      A previous merge conflict must have been resolved incorrectly
      Remove extra pgversion work that is no longer needed in this branch
      Stick with the old postgres version for now, we will bump the verison in
      a new MR
  22. 08 Nov, 2018 1 commit
  23. 07 Nov, 2018 1 commit
  24. 06 Nov, 2018 1 commit
  25. 01 Nov, 2018 1 commit
  26. 22 Oct, 2018 1 commit
  27. 19 Oct, 2018 1 commit
  28. 19 Jun, 2018 1 commit
  29. 29 Mar, 2018 1 commit
  30. 09 Mar, 2018 2 commits
  31. 23 Feb, 2018 1 commit
    • Richard Clamp's avatar
      Upgrade to Chef 13.6.4 from 12.21.31 · a82d010e
      Richard Clamp authored
      * Upgrades from chef 12.21.31 to 13.6.4, including dependent gems
      * Updates chefspec to 7.1.1
      * Fixes usage of node.default.gitaly in gitaly recipe
      * Fixes logging configuration under chef 13
      * Updates CHANGELOG
      * Multiple rspec fixes
      ** Changes uses of `old_run_action` to a more compatible call
      ** More complete Kernel.load mocking
      ** Globally mocks `#freeze` on helper instances
      ** Reset the Gitlab singleton in global `before`
      ** Fixes bad cache interactions in `services_spec`
      ** Remove pending from Chef 13 dependent example
      = Chef 13.6.4
        $EDITOR Gemfile # pin Chef to 13.6.4
        bundle upgrade chef
        git add --patch Gemfile Gemfile.lock
        $EDITOR config/software/*.rb # reflect changes in Gemfile.lock
        git add config/software
      13.6.4 is the most-recent-but-one release in the `stable` series of chef
      We had tried with the latest `stable` release of chef 13, 13.7.16, but
      hit issues with the defaulting of array properties:
      Care should be taken to upgrade over 13.7.16 to the next stable release,
      though we do have examples that will fail if these bugs are not fixed.
      = Chefspec 7.1.1
      It's necessary to upgrade to chefspec >= 7 to support chef 13.  We take
      the opportunity to go to 7.1.1 which is the latest stable version.  7.1
      auto-generates matchers, so we are able to remove
      `spec/support/matchers.rb` and `package/libraries/matchers.rb`
      == Fixes usage of node.default.gitaly in gitaly recipe
      Chef 13 no longer auto-generates accessors on the `attributes` Mashes,
      and instead expects you to access them using the `#[]=` method.
      We had one use in the gitaly recipe, which has been corrected to follow
      common style.
      = Be more explicit about the run mode for chef-client
      The run-mode of the chef-client was not configured explcitly, and
      instead relies on `interval` not being specified to mean 'run once and
      exit', rather than using the `once` configuration option.
      Additionally, when specifying `once` it also makes sense to specify
      `client_fork false` as it avoids a needless fork.
      = Fixes logging configuration under chef 13
      Due to some refactorings in the development of chef 13, it is no longer
      possible to have just a logfile and logging formatter configured
      *without* an additional STDOUT logger.
      This issue has been raised upstream as in the interim we monkey-patch
      the application class to surpess the creation of the STDOUT logger.
      = rspec fixups
      == Fix uses of `ruby_block('example').old_run_action(:run)`
      We were using the (internal to chefspec) `old_run_action` method to test
      the behaviour of the wrapped ruby blocks in `ruby_block` resources.
      Due to internal refactorings in chefspec 7.1 `old_run_action` is no
      longer available to us.
      Here we change uses of the `ruby_block('example').old_run_action(:run)`
      pattern to the more compatible `ruby_block('example')`.
      == More complete Kernel.load mocking
      Chef 13 freezes modules as it loads them.  This prevents accidental
      redefinition of the methods, but was initially clashing with itself as
      during a chefspec run the cookbook compiler was attempting to load all
      libraries after we had already loaded them in the chef_helper for ease
      of mocking.
      We extended our existing mocking of Kernel.load to be consistent with
      the loads of libraries from cookbooks other than the gitlab one.
      == Globally mocks `#freeze` on helper instances
      Related to the changes to mocking Kernel.load, once this was implemented
      we are bitten by default values in LWRPs being frozen in the attribute
      validator.  In order to keep on being able to mock all instances of
      `PgHelper` and related classes we add a mock of `#freeze` to several
      helper classes.
      == Reset the Gitlab singleton in global `before`
      The Gitlab global object was carrying state from one example group to
      another, this was causing subtle issues when running example groups that
      mutated the global Gitlab configuration in incompatible ways.
      Here we save the empty state of the Gitlab configuration singleton at
      the start of the test run, and then reset back to that state in the
      global `before`.
      == Fixes bad `cached` interaction in `services_spec`
      As a knock-on effect of resetting the Gitlab singleton for every
      example, we hit problems with how the `services_spec` was making use of
      the `cached` rspec helper.
      == Remove pending from Chef 13 dependent example
      An example that had initially raised awareness of the need for a chef13
      upgrade started working.  As this was a pending rspec example this made
      the tests fail.  Here we remove the pending qualifier.
  32. 17 Feb, 2018 1 commit
  33. 07 Feb, 2018 1 commit
    • Richard Clamp's avatar
      Extract BasePgHelper#extension_can_be_enabled? · f7b296d6
      Richard Clamp authored
      When gitlab_rails['enable'] = false, the database won't be created for
      the load to happen, causing an error from the
      postgresql_extension[pg_trgm] resource:
        postgresql_extension[pg_trgm] (gitlab::postgresql line 213) had an error: Mixlib::ShellOut::ShellCommandFailed: postgresql_query[enable pg_trgm extension] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/postgresql/resources/extension.rb line 6) had an error: Mixlib::ShellOut::ShellCommandFailed: execute[enable pg_trgm extension (gitlab-psql)] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/postgresql/resources/query.rb line 11) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '2'
        ---- Begin output of /opt/gitlab/bin/gitlab-psql -d gitlabhq_production -c "CREATE EXTENSION IF NOT EXISTS pg_trgm" ----
        STDERR: psql: FATAL:  database "gitlabhq_production" does not exist
        ---- End output of /opt/gitlab/bin/gitlab-psql -d gitlabhq_production -c "CREATE EXTENSION IF NOT EXISTS pg_trgm" ----
        Ran /opt/gitlab/bin/gitlab-psql -d gitlabhq_production -c "CREATE EXTENSION IF NOT EXISTS pg_trgm" returned 2
      Looking at the postgresql_extension LWRP we see that the logic around
      whether to enable the extension is a quite hairy not_if expression,
      which is hard to follow and debug.  To improve this here we extract the
      existing BasePgHelper#extension_can_be_enabled? and use that to simplify
      the flow of the `postgresql_extension` LWRP and `recipes/postgresql_spec`
  34. 06 Feb, 2018 1 commit
  35. 02 Jan, 2018 1 commit
  36. 22 Dec, 2017 1 commit
  37. 08 Dec, 2017 1 commit
  38. 15 Nov, 2017 1 commit
  39. 06 Nov, 2017 1 commit