- Apr 01, 2024
-
-
Balasankar 'Balu' C authored
- Continue conversion to the new style redis helper with refactors against the redis server functionality methods Signed-off-by:
Balasankar 'Balu' C <balasankar@gitlab.com>
-
- Feb 15, 2024
-
-
Robert Marshall authored
- Create a single versioned SELinux policy module for GitLab similar to other policy module components. - The first iteration of the consolidated policy is opt-in if the user sets `package['selinux_policy_version'] to anything other than nil. Closes https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7453 Closes https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8235 Changelog: changed Signed-off-by:
Robert Marshall <rmarshall@gitlab.com>
-
- Apr 18, 2022
-
-
DJ Mountney authored
This allows us to target their before block to just their tests
-
- Apr 08, 2022
-
-
vincent stchu authored
1. "sort" to make sure they are always loaded in the same order 2. require_related to make sure helper.rb is properly depended.
-
- Mar 24, 2022
-
-
Balasankar 'Balu' C authored
Moving around the chef rspec tests allows developers to more easily discover and maintain them. Additionally, this restructuring clears the path to use projectionist and more clearly see if any test coverage is missing. Related https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6721 Signed-off-by:
Balasankar "Balu" C <balasankar@gitlab.com>
-
- Sep 17, 2021
-
-
DJ Mountney authored
Changelog: fixed
-
- Aug 19, 2021
-
-
Gabriel Mazetto authored
-
- Jun 24, 2021
-
-
Robert Marshall authored
- In Chef Helper, we have an override that returns a String object when it should be returning a PGVersion object Related https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5507 Changelog: other Signed-off-by:
Robert Marshall <rmarshall@gitlab.com>
-
- Jun 11, 2021
-
-
Balasankar "Balu" C authored
Update consul to version 1.9.6 Closes #5908 See merge request gitlab-org/omnibus-gitlab!5344
-
- Jun 07, 2021
-
-
DJ Mountney authored
And notify when running version differs from the installed version Changelog: changed
-
- Jun 04, 2021
-
-
Balasankar "Balu" C authored
Changelog: added Signed-off-by:
Balasankar "Balu" C <balasankar@gitlab.com>
-
- Nov 06, 2020
-
-
Gabriel Mazetto authored
-
- Jan 07, 2021
-
-
Gabriel Mazetto authored
-
- Jan 08, 2021
-
-
Balasankar "Balu" C authored
Signed-off-by:
Balasankar "Balu" C <balasankarc@autistici.org>
-
- Nov 20, 2020
-
-
Robert Marshall authored
- Start the process of improving our PostgreSQL readiness check by adding a service_state method that returns the exit code of pg_isready Related https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4160 Signed-off-by:
Robert Marshall <rmarshall@gitlab.com>
-
- Oct 08, 2020
-
-
Matt Kasa authored
Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/223060
-
- Jun 29, 2020
-
-
DJ Mountney authored
Convert a standalone PostgreSQL to a Patroni member Closes #5265 See merge request gitlab-org/omnibus-gitlab!4350
-
- Jun 23, 2020
-
-
Hossein Pursultani authored
-
- Jun 24, 2020
-
-
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
-
- Dec 17, 2019
-
-
Balasankar "Balu" C authored
Signed-off-by:
Balasankar "Balu" C <balasankar@gitlab.com>
-
- Dec 12, 2019
-
-
Balasankar "Balu" C authored
Signed-off-by:
Balasankar "Balu" C <balasankar@gitlab.com>
-
- Oct 17, 2019
-
-
Ian Baum authored
* Error in GEO due to this. Possible that upgrading the db before migrations will clear the issue
-
- Jul 31, 2019
-
-
Ian Baum authored
* Add rubocop-rails and rubocop-performance gems * Update renamed gems in .rubocop.yml * Auto-correct where possible * Manually fix remaining gems
-
- Jul 08, 2019
-
-
Gabriel Mazetto authored
-
- Mar 09, 2018
-
-
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.
-
- Feb 23, 2018
-
-
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`.
-
- Feb 14, 2018
-
-
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.
-
- Feb 12, 2018
-
-
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]'
-
- Dec 05, 2017
-
-
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/
-
- Nov 02, 2017
-
-
Richard Clamp authored
-
- Oct 27, 2017
-
-
Balasankar C authored
-
Balasankar C authored
-
- Sep 05, 2017
-
-
DJ Mountney authored
-
- Aug 09, 2017
-
-
Ian Baum authored
incorrect By default, the :touch action runs every time.
-
- Aug 08, 2017
-
-
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.
-
- Jul 18, 2017
-
-
DJ Mountney authored
-
- Jul 14, 2017
-
-
DJ Mountney authored
-
- Jul 12, 2017
-
-
DJ Mountney authored
-
- Jul 07, 2017
-
-
DJ Mountney authored
-
- Jul 18, 2017
-
-
DJ Mountney authored
-