Skip to content
Snippets Groups Projects
  1. Apr 01, 2024
  2. Feb 15, 2024
  3. Apr 18, 2022
  4. Apr 08, 2022
  5. Mar 24, 2022
  6. Sep 17, 2021
  7. Aug 19, 2021
  8. Jun 24, 2021
  9. Jun 11, 2021
  10. Jun 07, 2021
  11. Jun 04, 2021
  12. Nov 06, 2020
  13. Jan 07, 2021
  14. Jan 08, 2021
  15. Nov 20, 2020
  16. Oct 08, 2020
  17. Jun 29, 2020
  18. Jun 23, 2020
  19. Jun 24, 2020
    • Ian Baum's avatar
      Upgrade chef and it's related gems to version 15.9.17 · 2ca338862698
      Ian Baum authored
      * Curently on 14, which was set to end of life at on April 30, 2020.
      * Adds chef-bin gem
      * Automatically accept the chef license EULA
      * Update chef libraries in Gemfile to newer versions
      * Update trigger jobs to use ruby 2.6 image
      2ca338862698
  20. Dec 17, 2019
  21. Dec 12, 2019
  22. Oct 17, 2019
  23. Jul 31, 2019
    • Ian Baum's avatar
      Upgrade rubocop to 0.73.0 · cc3bc60d8868
      Ian Baum authored
      * Add rubocop-rails and rubocop-performance gems
      * Update renamed gems in .rubocop.yml
      * Auto-correct where possible
      * Manually fix remaining gems
      cc3bc60d8868
  24. Jul 08, 2019
  25. Mar 09, 2018
    • Richard Clamp's avatar
      Enable LetsEncrypt when external_url is https · c434c03122a2
      Richard Clamp authored
      Here we change the default value of letsencrypt['enable'] from `false`
      to `nil`.
      
      This allows a user to specify explicit `true` or `false` if they want
      to, and then when they don't specify we use the code in
      `LetsEncrypt.should_enable?` as a heuristic to see if we should enable.
      
      The initial version of the heuristic is:
      
        url has https AND
        nginx is not disabled AND
        nginx is listening to https AND (
          ( nginx certficate file is absent AND
            nginx key file is absent ) OR
          we previously were enabled
        )
      
      The furry part is the 'we previously were enabled'.  As enabling the
      letsencrypt module creates certificate files we would then treat these
      as user-supplied certificates and so fail to renew or otherwise manage
      the lifecycle of the certificates.
      
      * Changes default of `letsencrypt['enable']` to nil.  It's falsey, but not
        definitive
      * Adds LetsEncrypt parse helper to the `letsencyrpt` attribute
      * Adds LetsEncrypt.should_enable? to hold the heuristic
      * Adds Gitlab['letsencrypt]['auto_enabled'] to the secrets file
      * Adds LetsEncrypt.save_auto_enabled to persist to the secrets file only
        if the ['letsencrypt]['auto_enabled'] attribute is missing from the
        secrets file
      * Splits SecretsHelper.load_gitlab_secrets out from read_gitlab_secrets,
        so we can load inspect the secrets file without fully loading it.
      c434c03122a2
  26. Feb 23, 2018
    • Richard Clamp's avatar
      Extract spec_helper from chef_helper · fe47ba8e8165
      Richard Clamp authored
      chef_helper loads a lot of chef related testing libraries, and includes
      a call to ohai to configure them.  This is not always needed when
      testing library code/rake tasks.
      
      When running examples directly from the command-line during development
      we can see a speedup of around 1.5 seconds, by using the reduced
      `spec_helper` rather than the full `chef_helper`.
      fe47ba8e8165
  27. Feb 14, 2018
    • Richard Clamp's avatar
      Upgrade to Chef 13.6.4 from 12.21.31 · 6561eaf9c2e1
      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
      releases. https://downloads.chef.io/chef/stable
      
      We had tried with the latest `stable` release of chef 13, 13.7.16, but
      hit issues with the defaulting of array properties:
      
      https://github.com/chef/chef/issues/6784
      https://github.com/chef/chef/issues/6792
      
      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
      https://github.com/chef/chef/issues/6889 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').block.call`.
      
      == 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.
      6561eaf9c2e1
  28. Feb 12, 2018
    • Richard Clamp's avatar
      Update to Chef 12.21.31 · d2d2df0ecc7d
      Richard Clamp authored
      * Updates the Gemfile.lock used by `bundle` CI tasks and rspec
      * Updates the software definitions to match Gemfile.lock
      * Tweaks Ohai Logging to supress noise in the rspec run
      * Fix deprecations in `account` and `templatesymlink` LWRPs
      
      = Gemfile and software definitions
      
      Initially generated by
      
          $ bundle upgrade chef
      
          $ git add --patch Gemfile.lock
      
      Reflecting pinning changes from Gemfile.lock into the software
      definitions.
      
          $ git add config/software
      
      This let us rely on bundler doing the hard work of solving for transient
      dependencies, but also allowed us to keep the versions of chef used for
      rspec testing aligned with the versions of components we add to the
      packages.
      
      = Ohai Logging
      
      With the update to ohai 8.26.1 we started to see an additional logging
      line during test startup:
      
        $ bundle exec rspec spec/chef/recipes/unicorn_spec.rb
        [2018-02-13T09:27:01+00:00] INFO: The plugin path /etc/chef/ohai/plugins does not exist. Skipping...
        Platform mac_os_x 10.13.3 not supported. Falling back to ubuntu 14.04
      
      Here we configure the loglevel of Ohai down to error before we call it
      to find our current platform, to tidy up the test output.
      
      = `account` LWRP's use of user type
      
      In Chef 12.14 the supports property of the user type was deprecated, to
      be removed in Chef 13.  Here we avoid this deprecation by changing our
      single use of the accounts LWRP to take/pass a manage_home property,
      rather than the previous `user_supports manage_home: false` property.
      
      https://docs.chef.io/deprecations_supports_property.html
      
      = `templatesymlink` LWRP property deprecations
      
      In moving to Chef 12.21.31 we are alerted of deprecations that will
      become fatal errors in moving to Chef 13.
      
      For `templatesymlink` they were both of the class of shadowing
      properties, as `sensitive` and `notifies` are both defined as methods in
      Chef::Resource which is an eventual parent class of the LWRPs.
      
      Fixing `sensitive` was simple, as the parent property behaves like a
      simple setter, so we can remove our and simply make use of the inherited
      behaviour from the baseclass, and just call `new_resource.sensitive`.
      
      https://github.com/chef/chef/blob/v12.21.33/lib/chef/resource.rb#L456-L466
      
      `notifies` was a little more complex.  Instead of attempting to supply
      this property, we instead use `new_resource.updated_by_last_action` if
      the wrapped templates :create action reported an update via
      `#updated_by_last_action?`
      
      This moves the thing that generates the notification from the wrapped
      template to the instance of `templatesymlink`, so some tests needed to
      be updated.
      
      This has also been manually tested by editing
      /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml and then
      observing that the reconfigure ran 'execute[clear the gitlab-rails cache]'
      d2d2df0ecc7d
  29. Dec 05, 2017
    • Richard Clamp's avatar
      Only set the password when it is supplied · c47547622f60
      Richard Clamp authored
      Here we make use of the `property_is_set?` function to gate the
      management of the password when the property has been supplied, and then
      treat `nil` to mean explicitly reset the password.
      
      In order to add confidence that it is working we add a new test
      cookbook, and add a spec/chef/resources/postgres_user_spec.rb to make
      use of it.
      
      We also add an explcit execute resource, to fixup user options if needed
      
      Sadly these tests reveal that the handling of nil values for properties
      fails when using chef 12.  When extracted[1] we can see this works
      with chef 13, but as an upgrade is out of scope for now, we mark the
      example as pending.
      
      [1] https://gitlab.com/richardc/lwrp-nil-headache/
      c47547622f60
  30. Nov 02, 2017
  31. Oct 27, 2017
  32. Sep 05, 2017
  33. Aug 09, 2017
  34. Aug 08, 2017
    • DJ Mountney's avatar
      Move the package attributes from being dynamically created to being · 78252781d6d2
      DJ Mountney authored
      declared.
      
      This causes some duplication for changing the install-dir, you need to
      change it in the attributes and in the gitlab project file if you want
      to change it. But we do not intent to change it ourselves, and may just
      drop the variable entirely in the future.
      78252781d6d2
  35. Jul 18, 2017
  36. Jul 14, 2017
  37. Jul 12, 2017
  38. Jul 07, 2017
  39. Jul 18, 2017
Loading