Otherwise some features would go untested in non-specific contexts
I did need to disable the
`gitlab_git_diff_size_limit_increase`-feature in some specs since we
depend on diffs being expandable while the file we are testing on is
smaller than the increased limit.
Submodules have a name in the configuration, but this name is simply
the path at which the submodule was initially checked in (by default
-- the name is totally arbitrary). If a submodule is moved, it
retains its original name, but its path changes. Since we discover
submodules inside trees, we have their path but not necessarily their
name.
Make the submodules() function return the submodule hash indexed by
path rather than name, so that renamed submodules can be looked up.
Signed-off-by: David Turner <novalis@novalis.org>
This adds an ID-less table containing one row per file, per merge request
diff. It has a column for each attribute on Gitlab::Git::Diff that is serialised
currently, with the advantage that we can easily query the attributes of this
new table.
It does not migrate existing data, so we have fallback code when the legacy
st_diffs column is present instead. For a merge request diff to be valid, it
should have at most one of:
* Rows in this new table, with the correct merge_request_diff_id.
* A non-NULL st_diffs column.
It may have neither, if the diff is empty.
This is controlled with the feature flag gitlab_git_diff_size_limit_increase.
Both of these limits were basically picked arbitrarily in the first place;
disabling the feature flag reverts to the old limits.
- Previously, we sorted commits by date, which seemed to work okay.
- The one edge case where this failed was when multiple commits have the same
commit date (for example: when a range of commits are cherry picked with a
single command, they all have the same commit date [and different author
dates]).
- Commits with the same commit date would be sorted arbitrarily, and usually
break the network graph.
- This commit solves the problem by both sorting by date, and by sorting
topographically (parents aren't displayed until all their children are
displayed)
- Include review comments from @adamniedzielski
A more detailed explanation is present here:
https://gitlab.com/gitlab-org/gitlab-ce/issues/30973#note_28706230
- We upgraded `rugged` to 0.25.1.1 in !10286 for %9.1
- Prior to this upgrade, the default sort order for commits returned by
`Gitlab::Git::Repository#find_commits` was `Rugged::SORT_DATE`, which the
graph relied on.
- While upgrading `rugged`, the MR also changed this default to
`Rugged::SORT_NONE`, which broke commit ordering in the graph.
- This commit adds an option to `Gitlab::Git::Repository#find_commits` to sort
by date, and changes the graph builder `Network::Graph` so it explictly
requests the `:date` sort order
This is analogous to `git log -- foo bar baz`, but not the same as
`Gitlab::Git::Repository#log(path: 'foo bar baz')`, which would run `git
log -- 'foo bar baz'`.
- `raise "string"` raises a `RuntimeError` - no need to be explicit
- Remove top-level comment in the `RevList` class
- Use `%w()` instead of `%w[]`
- Extract an `environment_variables` method to cache `env.slice(*ALLOWED_VARIABLES)`
- Use `start_with?` for env variable validation instead of regex match
- Validation specs for each allowed environment variable were identical. Build them dynamically.
- Minor change to `popen3` expectation.
- Don't define "allowed environment variables" in two places.
- Dispatch to different arities of `Popen.open` without an if/else block.
- Use `described_class` instead of explicitly stating the class name within a
- spec.
- Remove `git_environment_variables_validator_spec` and keep the validation inline.
The list of environment variables in `Gitlab::Git::RevList` need to be validate
to make sure that they don't reference any other project on disk.
This commit mixes in `ActiveModel::Validations` into `Gitlab::Git::RevList`, and
validates that the environment variables are on the level (using a custom
validator class). If the validations fail, the force push is still executed
without any environment variables set.
Add specs for the validation using shared examples.
Note: This feature was developed independently on master while this was
in review. I've removed the conflicting bits and left the relevant
additions, mainly a test for `Gitlab::Git::Hook`. The original commit
message follows:
1. `gitlab-shell` outputs errors to `stderr`, but we weren't using this
information, prior to this commit. Now we capture the `stderr`, and
display it in the flash message when branch creation fails.
2. This can be used to display better errors for other git operation
failures with small tweaks.
3. The return value of `Gitlab::Git::Hook#trigger` is changed from a
simple `true`/`false` to a tuple of `[status, errors]`. All usages
and tests have been updated to reflect this change.
4. This is only relevant to branch creation _from the Web UI_, since SSH
and HTTP pushes access `gitlab-shell` either directly or through
`gitlab-workhorse`.
5. A few minor changes need to be made on the `gitlab-shell` end. Right
now, the `stderr` message it outputs is prefixed by "GitLab: ", which
shows up in our flash message. This is better removed.
Alejandro Rodríguez
Ahmad Sherif
Rémy Coutable
Andrew Newdigate
Sean McGivern
Jacob Vosmaer
Bob Van Landuyt
blackst0ne
Robert Speicher
Grzegorz Bizon
David Turner
Sean McGivern
Robert Speicher
Douwe Maan
Douwe Maan
Bob Van Landuyt
Timothy Andrew
Kim "BKC" Carlbäcker
James Lopez
mhasbini
Mark Fletcher
Oswaldo Ferreira
George Andrinopoulos
Grzegorz Bizon
Dmitriy Zaporozhets