Gitaly-Ruby is not a Rails application, which made the method not exist
after the vendor. This patch uses direct indexing, which has the same
properties that `#first` has.
Found while working on: https://gitlab.com/gitlab-org/gitaly/merge_requests/699
Today, when fetching diffs of a note, we always go to Gitaly in order to diff between commits and return the diff of each discussion note. With this change we avoid doing that for notes on the "current version" of the MR.
Since we only need the `can?` view helpers there, it's better to
include those in a separate controller.
If we inherit from `ApplicationController` we also need to deal with
authentication, that needs to be done in some, but not all doorkeeper controllers.
Storage shards should only be used, the exact paths are the
responsibilty of Gitaly. This will create deprecation warning, and in
this instance the path is initialized, but never used so it could be
removed.
In Arel 7.0.0 (Arel 7.1.4 is used in Rails 5.0) the `engine` parameter
of `Arel::UpdateManager#initializer` was removed.
This commit makes the gitlab database helpers work both in rails 4 and
rails 5.
Fixes errors like this one:
```
1) Gitlab::Database::MigrationHelpers#update_column_in_batches when running outside of a transaction updates all the rows in a table
Failure/Error:
update_arel = Arel::UpdateManager.new(ActiveRecord::Base)
.table(table)
.set([[table[column], value]])
.where(table[:id].gteq(start_id))
ArgumentError:
wrong number of arguments (given 1, expected 0)
# ./lib/gitlab/database/migration_helpers.rb:317:in `new'
# ./lib/gitlab/database/migration_helpers.rb:317:in `block in update_column_in_batches'
# ./lib/gitlab/database/migration_helpers.rb:307:in `loop'
# ./lib/gitlab/database/migration_helpers.rb:307:in `update_column_in_batches'
# ./spec/lib/gitlab/database/migration_helpers_spec.rb:367:in `block (4 levels) in <top (required)>'
```
In Rails 4.2.10 the `ActiveSupport::TimeZone.find_tzinfo(timezone_name)`
method calls `TZInfo::TimezoneProxy.new(timezone_name)` which returns
`timezone_name` if it is invalid.
But in Rails 5.0 the `ActiveSupport::TimeZone.find_tzinfo(timezone_name)`
method now calls the `TZInfo::Timezone.new(timezone_name)` method which
throws the `TZInfo::InvalidTimezoneIdentifier: Invalid identifier`
exception if `timezone_name` is invalid.
This commit adds the rescue block to return timezone name if the
exception is raised.
Also this change fixes the error:
```
1) Ci::PipelineSchedule validations does not allow invalid cron patters
Failure/Error: ActiveSupport::TimeZone.find_tzinfo(timezone).name
TZInfo::InvalidTimezoneIdentifier:
Invalid identifier
# ./lib/gitlab/ci/cron_parser.rb:28:in `timezone_name'
# ./lib/gitlab/ci/cron_parser.rb:9:in `initialize'
# ./app/validators/cron_validator.rb:6:in `new'
# ./app/validators/cron_validator.rb:6:in `validate_each'
# ./spec/models/ci/pipeline_schedule_spec.rb:26:in `block (3 levels) in <top (required)>'
```
Has been in opt out for 5 months, and within GitLab been in production
for longer than that.
No code needs to be migrated as this is implemented in GoLang over at
Gitaly.
Closes https://gitlab.com/gitlab-org/gitaly/issues/314
Direct disk access is done through Gitaly now, so the legacy path was
deprecated. This path was used in Gitlab::Shell however. This required
the refactoring in this commit.
Added is the removal of direct path access on the project model, as that
lookup wasn't needed anymore is most cases.
Closes https://gitlab.com/gitlab-org/gitaly/issues/1111
* processes any pending records which are not migrated yet
* bumps import_export version because of new commits_count attribute
* removes commits_count fallback method
Kim Carlbäcker
Fabio Busatto
Douwe Maan
Robert Speicher
Tim Zallmann
Zeger-Jan van de Weg
Alexis Reigel ( 🌴 may 2nd - may 9th 🌴 )
Rémy Coutable
Kamil Trzciński
Jan Provaznik
Grzegorz Bizon
Oswaldo Ferreira
Alessio Caiazza
Jacob Vosmaer
Bob Van Landuyt
blackst0ne
Nick Thomas
Grzegorz Bizon