This adds and documents an `alpha_feature_available?` method to groups
and projects, and also documents the existing `beta_feature_available?`
method.

Igor Drozdov authored Dec 04, 2019 and Bob Van Landuyt :neckbeard: committed Dec 04, 2019

That's useful in case we need a certain number of approvals
from a particular group and a certain number of approvals
from any developer

mo khan authored Nov 28, 2019 and Mayra Cabrera committed Nov 28, 2019

* Add a software license policy update endpoint
* Apply the correct id to a license for known licenses

Adds a migration that creates the ci_subscriptions_projects table.

* Remove config transient
* Remove factory for 1 job pipeline
* Remove factory for 0 job pipeline

As hashed storage is the default storage type since v10.0, and we
encourage people to migrate to hashed storage, design management now
has a hard requirement for hashed storage in order for us to handle
moving the design repository when the project repository moves on disk.

https://gitlab.com/gitlab-org/gitlab/issues/13428

and change token from `encrypted: :optional` to `encrypted:
:required`.

Add `token` to ignored columns so that we can drop it in the next
release.

Related to https://gitlab.com/gitlab-org/gitlab/issues/29594.

NPM packages presence is checked before these actions:
* group at the root namespace has a path update
* subgroup is transfered to a different root namespace
* project is transfered to a different root namespace

Move `Project#alerts_service_activated?` method into EE namespace

Ran: bundle exec rubocop --only RSpec/EmptyLineAfterSubject -a

Allow jobs to use CI_JOB_TOKEN to trigger downstream pipelines

Releases Generic alerts integration that accepts alerts
from any source via a generic webhook receiver.

Avielle Wolfe authored Oct 10, 2019 and Grzegorz Bizon committed Oct 10, 2019

Project security dashboards were displaying no vulnerabilities for
public projects, even when the latest pipeline reported
vulnerabilities.

The issue was our Namespace#store_security_reports_available? method,
which had no knowledge of the project or whether it was public, and
only checked for availability based on the instance's license.

I've added Project#can_store_security_reports?, which calls into
Namespace to check for license availability and _also_ checks
whether the project is public. Now public projects can get the
security scanning they've been wanting!

https://gitlab.com/gitlab-org/gitlab/issues/13422

Samantha Ming authored Oct 08, 2019 and Paul Slaughter committed Oct 08, 2019

- Removes project wide setting from UI

Added usage activity data for monitor stage

With this setting we can set a prefix to branches during pull mirroring

Added usage activity data for the verify stage

Alex Buijs authored Oct 01, 2019 and Mayra Cabrera committed Oct 01, 2019

Added usage activity data for the create stage

Ash McKenzie authored Oct 01, 2019 and Mayra Cabrera committed Oct 01, 2019

Added usage_statistics concern with scope for models

Simon Knox authored Sep 25, 2019 and Bob Van Landuyt :neckbeard: committed Sep 25, 2019

This adds a generic alerts service to a project's settings. Enabling it generates a new token to be used when calling the alert service.

Each time design is created we need to push notification to secondaries

This reverts merge request !16187

Yorick Peterse authored Sep 17, 2019 and Achilleas Pipinellis committed Sep 17, 2019

This changes any mention of gitlab-ce to gitlab-foss, and any mention of
gitlab-ee to just gitlab.

Kerri Miller authored Sep 17, 2019 and James Lopez committed Sep 17, 2019

I've set this up as a post-deploy background migration, taking advantage
of `each_batch` to set up jobs for Sidekiq workers to copy the project's
`merge_requests_require_code_owner_approval` to each of its protected
branch's `code_owner_approval_required` attribute. I've added some basic
tests here, as well.

I initially added a pair of #after_commit hooks to make sure projects
get updated while we were asynchronously chewing through the projects
and branches. However, I abandoned this, as a database reviewer supplied
a faster approach that shouldn't be an issue in terms of the total time
required to process the entities.

Applying only to ProtectedBranches, this is a squashed commit of 40+
commits building out support for this feature. We begin the process here
of moving from applying CODEOWNER validation rules on a project level,
to enabling CODEOWNER validations to run more granularly, by moving this
attribute to the ProtectedBranches themselves. A latter project will
follow that enable managing this feature via the UI, but in this commit
we allow for manipulation of this value via the API. Finally, we extend
CODEOWNER validation checks to closed MRs as well, as the rules are
attached to the merge request with each new ref in the changeset, rather
than being stateful to the time the action is initiated; the rules that
applied at the moment of creation are the rules we apply in the future.

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31741
changed the behavior to fire hooks only if project or system
hooks needed to be fired. We also need to consider group hooks
as well.

Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/13752

Bob Van Landuyt :neckbeard: authored Aug 13, 2019 and Douwe Maan committed Aug 13, 2019

**Prevention of running 2 simultaneous updates**

Instead of using `RemoteMirror#update_status` and raise an error if
it's already running to prevent the same mirror being updated at the
same time we now use `Gitlab::ExclusiveLease` for that.

When we fail to obtain a lease in 3 tries, 30 seconds apart, we bail
and reschedule. We'll reschedule faster for the protected branches.

If the mirror already ran since it was scheduled, the job will be
skipped.

**Error handling: Remote side**

When an update fails because of a `Gitlab::Git::CommandError`, we
won't track this error in sentry, this could be on the remote side:
for example when branches have diverged.

In this case, we'll try 3 times scheduled 1 or 5 minutes apart.

In between, the mirror is marked as "to_retry", the error would be
visible to the user when they visit the settings page.

After 3 tries we'll mark the mirror as failed and notify the user.

We won't track this error in sentry, as it's not likely we can help
it.

The next event that would trigger a new refresh.

**Error handling: our side**

If an unexpected error occurs, we mark the mirror as failed, but we'd
still retry the job based on the regular sidekiq retries with
backoff. Same as we used to

The error would be reported in sentry, since its likely we need to do
something about it.

As decided in https://gitlab.com/gitlab-org/gitlab-ce/issues/53593

* Adds Projects::Security::VulnerabilitiesController
* Adds Projects::Security::DashboardHelper
* Adds project security dashboard vulnerabilities routes
* Includes Vulnerable module in Project

Fixes https://gitlab.com/gitlab-org/gitlab-ee/issues/12381
and https://gitlab.com/gitlab-org/gitlab-ee/issues/12244

These are not required because MySQL is not
supported anymore

Ensure the Insights configuration project is part of the group and is accessible to the current user
Signed-off-by: Rémy Coutable <remy@rymai.me>

Steve Abrams authored Jul 17, 2019 and Bob Van Landuyt :neckbeard: committed Jul 17, 2019

To allow for the publishing of NPM packages from groups and subgroups,
packages must be able to be named without the forward slash character.
This change removes requiring the package name match the full project
path and name, and updates the query for finding a package by its
name.

Luke Duncalfe authored Jul 12, 2019 and Mayra Cabrera committed Jul 12, 2019

This avoids the bug in
https://gitlab.com/gitlab-org/gitlab-ce/issues/64468

This endpoints are only accessible by an admin.