Updates the excon gem which was the one with ruby 2.7 problems

Signed-off-by: Balasankar "Balu" C <balasankarc@autistici.org>

Omnibus still rely on aws-sdk-s3, but we don't need to require
everything from aws-sdk ecosystem.

Ian Baum authored 4 years ago and DJ Mountney committed 4 years ago

* 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

Robert Marshall authored 4 years ago and DJ Mountney committed 4 years ago

- Update `parser` gem version to fix warnings
- Update `unparser` gem version so that it does not depend on a version
  of parser one lower than fixes the warnings

Closes https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5393



Signed-off-by: Robert Marshall <rmarshall@gitlab.com>

This allows for being more concise in specs that test a state when
changing multiple variables.

[┐∵]┘GitLab Dependency Bot authored 5 years ago and Balasankar C committed 5 years ago

Upstream chef hasn't changed the mixlib-log, so let's leave it as is

This reverts commit be5f683e, reversing
changes made to a82be75c.

The gem in rubygems has been restored, and the workaround is no longer
needed.

Signed-off-by: Balasankar "Balu" C <balasankar@gitlab.com>

Ian Baum authored 5 years ago and DJ Mountney committed 5 years ago

* Add rubocop-rails and rubocop-performance gems
* Update renamed gems in .rubocop.yml
* Auto-correct where possible
* Manually fix remaining gems

Signed-off-by: Balasankar "Balu" C <balasankar@gitlab.com>

Signed-off-by: Balasankar "Balu" C <balasankar@gitlab.com>

John Jarvis authored 5 years ago and DJ Mountney committed 5 years ago

This reverts commit dacdfba9.

Signed-off-by: Balasankar "Balu" C <balasankar@gitlab.com>

This adds an additional step in the `Ubuntu-16.04-staging` to trigger
the takeoff pipeline on ops.gitlab.net so that staging deploys are
immediately triggered when this job complete.

This step will only run if `TAKEOFF_TRIGGER_TOKEN` is defined as a
secret CICD var.

* Use helper for takeoff task
* Add check for latest tag and gitlab-ee package.

This elmiminates the deprecation warning in rubocop:

"NOTE: Gem.gunzip is deprecated; use Gem::Util.gunzip instead. It will
be removed on or after 2018-12-01."

* 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.

Omnibus 5.6.10 (amongst other changes) loosens the pinning of ohai to
allow Ohai 13 to be installed.

https://github.com/chef/omnibus/blob/master/CHANGELOG.md#v5610-2018-02-17

* 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]'

* Making an explicit dependency. It has included due to a dependency
from package cloud.
* Used by Chef::Formatters::Gitlab as well as Geo related gitlab-ctl
commands.

Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

Missed this as part of !2046, so pipelines are failing.