This fixes https://gitlab.com/gitlab-org/gitlab/issues/37766 which is
caused by the fact that we leave the stale permissions data in the index
after a group is moved to another group.

When a user updates a merge request coming from a fork, they should
not be able to set `force_remove_source_branch` if they cannot push
code to the source project.

Otherwise developers of the target project could remove the source
branch of the source project by setting this flag through the API.

This is to be more consistent as there is already a :read_note policy in
NotePolicy. To keep other behaviour the same we've introduced a
Note#noteable_ability_name that is used anywhere this was expected.

This makes it so we mask Sentry's auth token. This mask only occurs in
the UI.

Aakriti Gupta authored 5 years ago and mksionek committed 5 years ago

in a project members' list. Add tests for possible scenarios

Re-factor and remove N + 1 queries

Remove author from changelog

Don't use memoisation when not needed

Include users part of parents of project's group

Re-factor tests

Create and add users according to roles

Re-use group created earlier

Add incomplete test for ancestoral groups

Rename method to clarify category of groups

Skip pending test, remove comments not needed

Remove extra line

Include ancestors from invited groups as well

Add specs for participants service

Add more specs

Add more specs

use  instead of

Use public group owner instead of project maintainer to test owner acess

Remove tests that have now been moved into participants_service_spec

Use :context instead of :all

Create nested group instead of creating an ancestor separately

Add comment explaining doubt on the failing spec

Imrpove test setup

Optimize sql queries

Refactor specs file

Add rubocop disablement

Add special case for project owners

Add small refactor

Add explanation to the docs

Fix wording

Refactor group check

Add small changes in specs

Add cr remarks

Add cr remarks

Add specs

Add small refactor

Add code review remarks

Refactor for better database usage

Fix failing spec

Remove rubocop offences

Add cr remarks

This prevents a MITM attack where attacker could
still access Git repository if any jobs were
running long enough.

Creating a MR from an issue using a tag as ref correctly creates the
source branch starting from the tag.

In case the source and the target project are the same, the
source branch is the default branch, and the target branch
is not present, we will avoid prefilling the target branch
with the repository default branch. Letting the user decide.

When a pipeline fails to create in `PostReceive`, the error is silently
discarded, making it difficult to understand why a pipeline was not
created. We now add a Sidekiq warning message for this. Adding a Sentry
exception when this happens would generate a lot of noise for invalid CI
files.

Relates to https://gitlab.com/gitlab-org/gitlab-ee/issues/14720

Detect if pipeline runs for a GitHub pull request

When using a mirror for CI/CD only we register a pull_request
webhook. When a pull_request webhook is received, if the
source branch SHA matches the actual head of the branch in the
repository we create immediately a new pipeline for the
external pull request. Otherwise we store the
pull request info for when the push webhook is received.

When using "only/except: external_pull_requests" we can detect
if the pipeline has a open pull request on GitHub and create or
not the job based on that.

Since it is not possible to dynamically detect if a job is automatically
cancellable or not, a this new attribute is necessary. Moreover, it let
the maintainer of the repo to adjust the behaviour of the auto cancellation
feature to match exactly what he needs.

Kerri Miller authored 5 years ago and Nick Thomas committed 5 years ago

These are the structural changes for supporting the EE feature of moving
"code_owner_approval_required" state from existing on a project to being
on the protected branches individually, allowing for CODEOWNER
validation on push events.

João Cunha authored 5 years ago and Mayra Cabrera committed 5 years ago

- We're also improving specs to avoid this could happen again

- Add new service that transfers milestones
from a group to a project
- Include new service in Projects transfer service
- Include FromUnion module in Milestone model
to use in transfer service
- Add specs for new milestones service
- Add specs for transferring milestones in
project transfer service

IssuableBaseService::filter_labels() has been refactored to call
a new `label_ids_to_filter` method.

IssuableBaseService has been updated so that labels are not
created when push options to remove them are received.

MergeRequests::PushOptionsHandlerService has been updated to allow
adding and removing labels to a merge request using git push options.

To create a new merge request and add 2 labels to it:

      git push -u origin -o merge_request.create \
        -o merge_request.label="My label 1" \
        -o merge_request.label="My label 2"

To update an existing merge request and remove a label while
adding a different label:

      git push -u origin -o merge_request.label="My added label" \
        -o merge_request.unlabel="My removed label"

Issue https://gitlab.com/gitlab-org/gitlab-ce/issues/64320

Jan Provaznik authored 5 years ago and Thong Kuah committed 5 years ago

Creates new event when an epic is created, closed, reopened or
commented.

Etienne Baqué authored 5 years ago and Andreas Brandl committed 5 years ago

Modified schema via migrations.
Added one-to-one relationship between the two models.
Added changelog file

Giorgenes Gelatti authored 5 years ago and Thong Kuah committed 5 years ago

Extends the permission of $CI_REGISTRY_USER to allow them
to delete tags in addition to just pushing.

https://gitlab.com/gitlab-org/gitlab-ce/issues/40096

When updating group and project members, new system hooks
`user_update_for_group` and `user_update_for_team` will be executed.

Fixes https://gitlab.com/gitlab-org/gitlab-ee/issues/12252