* Uses the same supporting code as used in EE
* Includes automated cleanup
* Install external-dns helm chart to review apps cluster if it isn't
already
* Adds variables REVIEW_APPS_AWS_SECRET_KEY and
REVIEW_APPS_AWS_ACCESS_key
* review-apps-ce uses a different cipher
This is needed because `GITLAB_VERSION` has a special meaning in
`omnibus-gitlab` triggers: this is the GitLab version to build.
The problem is that `omnibus-gitlab` also has triggers to run QA for an
`omnibus-gitlab` commit, and if we use `GITLAB_VERSION` in that case,
the comment would be posted on the GitLab CE/EE commit (stored in
`GITLAB_VERSION`), whci hwouldn't make any sense.
Thus we need `TOP_UPSTREAM_SOURCE_SHA` to represent the commit on
which we want to leave a comment.
Signed-off-by: Rémy Coutable <remy@rymai.me>
Cleanup code, and refactor tests that still use Rugged. After this, there should
be no Rugged code that access the instance's repositories on non-test
environments. There is still some rugged code for other tasks like the
repository import task, but since it doesn't access any repository storage path
it can stay.
- Stop review app's environment after 2 days
- Delete review app's environment after 3 days
- Delete Helm release after 4 days
Signed-off-by: Rémy Coutable <remy@rymai.me>
When on a tag, trigger a multi-project pipeline in the CNG repostiory.
Opting for a trigger rather than an addition to our release-tools
project for a few reasons:
- The Dockerfiles in the CNG image repo change infrequently, and as a result
I don't feel the need/overhead for stable branches in that repo at this time
- My intent with the CNG repo, is that once stable, the Dockerfiles
would actualy move to their component projects, to be versioned with the
code they are building
- It is likely that we will want to followup with a manually triggered package
for branches for devs, and possibly review apps, so it made sense to
build the CNG ci jobs to accept this sort of pipeline.
* upstream/master: (621 commits)
Add a note about GitLab QA page objects validator to docs
Refactor dispatcher projects blame and blob path
Update export message to mention we can download the file from the UI
Fix Ctrl+Enter keyboard shortcut saving comment/note edit
fix case where tooltip messes up :last-child selector
Add reason to keep postgresql 9.2 for CI
Remove warning noise in ProjectImportOptions
Add changelog entry
Add RedirectRoute factory
Update Ingress extra cost note to be more generic
Fix Rubocop offense
Refactor dispatcher project branches path
Revert "Revert "Fix Route validation for unchanged path""
Document that we need rsync for backing up
Docs: move article "Laravel and Envoy w/ CI/CD"
Recommend against the use of EFS
Adds Rubocop rule for line break around conditionals
Update CHANGELOG.md for 10.1.6
Filter out build traces from logged parameters
Refactored project:n* imports in dispatcher.js
...
The default behavior of seed_fu is to load the fixtures using the RAILS_ENV
environment. In CI, since we set RAILS_ENV=test, nothing is ever
loaded. Instead of `rake db:seed_fu`, use `rake gitlab:setup`, which sets up
MySQL properly with limits.
Closes#41517
Without this patch, I would end up with:
```
An error occurred in a `before(:suite)` hook.
Failure/Error: raise "could not connect to gitaly at #{socket.inspect} after #{sleep_time} seconds"
RuntimeError:
could not connect to gitaly at "tmp/tests/gitaly/gitaly.socket" after 10 seconds
```
Digging into it, it's because `scripts/gitaly-test-spawn` could not
spawn the process, because it cannot find the installed gems.
I personally installed all my gems under $HOME, namely with:
* `gem install rake --user-install` or:
* `bundle install --path ~/.gem`
The gems would be installed to `~/.gem/ruby/2.4.0/gems`, where
the version is Ruby ABI version.
Now we're changing $HOME, making RubyGems think that the gems
would be installed to `tmp/tests/ruby/2.4.0/gems` which is
apparently not the case.
In order to workaround this, we could preserve $GEM_PATH
populated by RubyGems, ignoring the default path based on $HOME.
We have run into permission issues with MySQL triggers in #36633 that
would have been caught earlier either if our migration tests or GitLab QA
tests had been testing against non-superuser users. This change creates
a non-superuser that has access to the GitLab test database and uses that.
Closes#39932
When a changelog has invalid YAML (typically, there is an unquoted @ at the
start of the author field), then the entry will be discarded. This script checks
all unreleased changelogs for validity, and runs as part of the static-analysis
step, so the pipeline will fail if this happens in future.