a new repository location class.

it's not nil nor false.

GITLAB_USERNAME and GITLAB_PASSWORD may be specified for an LDAP login, but QA
scenarios may need to know which type it is in order to log in successfully.

For a new instance, the root password needs to be set, regardless of whether
LDAP is enabled.

and use an invalid user name that is random so we know it's invalid

This reverts commit e6579d82, reversing
changes made to afcd9fc7.

The `has_css?` line was always timing out false because `$(‘…’).val(url)` does not change the input’s value attribute.

See https://gitlab.com/gitlab-org/gitlab-ce/issues/39118

Conflicts:
	app/views/ci/variables/_form.html.haml
	app/views/ci/variables/_table.html.haml
	ee/app/views/ci/variables/_environment_scope.html.haml
	spec/javascripts/ci_variable_list/ci_variable_list_ee_spec.js
	spec/javascripts/fixtures/projects.rb

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

This allows to open the file address printed in the terminal, otherwise
the address started with `tmp` which was relatove to the `qa/` dir.

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

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

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

I ran into some issues when trying it out
https://gitlab.slack.com/archives/C3JJET4Q6/p1517384135000134

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

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

We always clone over HTTP, so if the QA spec attempts to clone over SSH, we know it gathered the wrong repo URI.

I haven’t seen `go_to_new_subgroup` fail in the same way, but it seems best to modify it also.

in certain conditions. And `first` was causing it to succeed even though the criteria were ambiguous.