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.
Here was the problem:
1. When determining whether a given blob is viewable text, gitlab_git reads the first 1024 bytes and checks with Linguist whether it is a text or binary file.
2. If the blob is text, GitLab will attempt to display it.
3. However, if the text has binary characters after the first 1024 bytes, then GitLab will attempt to load the entire contents, but the encoding will be ASCII-8BIT since there are binary characters.
4. The Error 500 results when GitLab attempts to display a mix UTF-8 and ASCII-8BIT.
To fix this, we load as much data as we are willing to display so that the detection will work properly. Requires
an update to gitlab_git: gitlab-org/gitlab_git!86
Closes#13826
The problem occurred because asset compilation takes a long time, so
when the asset cache didn't exist and the first test ran, it would often
(randomly) time out during the generation before the actual test even
had a chance to run.
Now we check if the cache exists before the suite runs, and if not, we
manually fire a request to the root URL in order to generate it. This
should allow subsequent tests to use the cached assets.
See http://schacon.github.io/git/git-init.html#_template_directory
Without this variable, any global git hooks a developer might have in
~/.git_template would be linked in the `.git/hooks` folder for every
test repository that gets checked out by TestEnv, and would cause
certain specs to fail due to pre-existing hook files.
Before this it would fail because git hooks automatically prepend
things to the path, which can lead the wrong Ruby version to be called
in which dependencies are not installed.
To make sure that this is correct, the forked_merge_requests commented
out test that depends on this change was uncommented.
For that test to pass, it is also necessary to setup the mock server
on port 3001 under test_env.rb.