| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update the `/internal/pages` endpoint to return virtual domain
configuration for custom domains.
|
|
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.
|
|
|
|
This change limits the number of emails
for new access requests notifications to
10 most recently active owners/maintainers
|
|
|
|
A new param with_security_reports was added to
GET /groups/:id/projects API and the code to
support this logic in GroupProjectsFinder and
Project model. Also, a DB index was added to
ci_job_artifacts table to speed up the search
of security reports artifacts for projects
|
|
The flag defaulted to true, so there's no change unless users turned it
off. Given there's a lack of issues regarding object pools, this should
be OK.
|
|
Sorting preference functionality has been extracted
from `IssuableCollections` to a new `SortingPreference`
concern in order to reuse this functionality in projects
(and groups in the future).
|
|
This change lays the foundation for customizable cycle analytics stages.
The main reason for the change is to extract the event definitions to
separate objects (start_event, end_event) so that it could be easily
customized later on.
|
|
- Adds UI to configure in group and project settings
- Removes notification configuration for users when
disabled at group or project level
|
|
This commit reduces I/O load and memory utilization during PostReceive
for the common case when no project hooks or services are set up.
We saw a Gitaly N+1 issue in `CommitDelta` when many tags or branches
are pushed. We can reduce this overhead in the common case because we
observe that most new projects do not have any Web hooks or services,
especially when they are first created. Previously, `BaseHooksService`
unconditionally iterated through the last 20 commits of each ref to
build the `push_data` structure. The `push_data` structured was used in
numerous places:
1. Building the push payload in `EventCreateService`
2. Creating a CI pipeline
3. Executing project Web or system hooks
4. Executing project services
5. As the return value of `BaseHooksService#execute`
6. `BranchHooksService#invalidated_file_types`
We only need to generate the full `push_data` for items 3, 4, and 6.
Item 1: `EventCreateService` only needs the last commit and doesn't
actually need the commit deltas.
Item 2: In addition, `Ci::CreatePipelineService` only needed a subset of
the parameters.
Item 5: The return value of `BaseHooksService#execute` also wasn't being
used anywhere.
Item 6: This is only used when pushing to the default branch, so if
many tags are pushed we can save significant I/O here.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/65878
Fic
|
|
Remove KubernetesService integration
See merge request gitlab-org/gitlab-ce!31365
|
|
As decided in https://gitlab.com/gitlab-org/gitlab-ce/issues/53593
|
|
Creating new records has been disabled, and all
existing records been migrated to clusters as of
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/28534
|
|
Kubernetes deployments on new clusters will now have
a separate namespace per project environment, instead
of sharing a single namespace for the project.
Behaviour of existing clusters is unchanged.
All new functionality is controlled by the
:kubernetes_namespace_per_environment feature flag,
which is safe to enable/disable at any time.
|
|
|
|
This commit changes how we eager-load projects, routes, and namespaces
required by the deploy keys endpoint, getting a 10x improvement in my
local testing.
The endpoint still doesn't scale in-general, but going from ~13 seconds
to dump a 63K result to generating the same thing in ~1.6 seconds seems
like a good improvement to me.
|
|
All cluster resources are now created on demand when
a deployment job starts.
|
|
Find build by sha from ref
Closes #64534 and #45697
See merge request gitlab-org/gitlab-ce!30843
|
|
* Reword Project#latest_successful_build_for to
Project#latest_successful_build_for_ref
* Reword Ci::Pipeline#latest_successful_for to
Ci::Pipeline#latest_successful_build_for_ref
|
|
Optimise import performance
Closes #64924
See merge request gitlab-org/gitlab-ce!31045
|
|
- Fix `O(n)` complexity of `append_or_update_attribute`,
we append objects to an array and re-save project
- Remove the usage of `keys.include?` as it performs `O(n)`
search, instead use `.has_key?`
- Remove the usage of `.keys.first` as it performs a copy
of all keys, instead use `.first.first`
|
|
Adds ability to find builds by sha when only specifying a ref.
|
|
Multiple pipeline support for Build status
See merge request gitlab-org/gitlab-ce!30828
|
|
Adds specs for testing the new behavior of specifying a pipeline when
POSTing a status.
|
|
This pagination is not used anywhere so there is no reason
to keep it. It seems the usage of offset_id was probably
removed in 90c60138db4e1f86026aac5760febe4ba066ca30
|
|
If `project_auto_devops.enabled` is nil for a project, when setting any
auto devops values via the API, we try to create a new row in the DB,
instead of re-using the existing one. This leads to the project_id
being set to nil, and the database `NOT NULL` constraint leading to a
500 response.
This commit resolves the issue by correctly detecting the presence of a
ProjectAutoDevops row and re-using it. Persistence is also moved away
from explicit `update!` calls and into relying on `autosave: true` on
the model.
|
|
Next models are affected:
* Project
* Namespace
* Issue
* Merge request
* CI Trigger
* CI Pipeline schedule
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
|
|
Updates changed method names and fixes spec failures
|
|
Suggests to use a JSON structured log instead
Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/54102
|
|
|
|
|
|
Object pools allow Git objects to be shared from the parent project to forks,
reducing storage requirements.
|
|
We map the boolean to the string 'fetch' or 'clone', to be more
explicit.
|
|
I forgot to clean up this bit in we switched the `forked_from_project`
relation to use fork networks in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22226
|
|
Now we have terminals for instance and group clusters we can remove the
FF now. Deploying to group clusters has been working without complaints
too.
|
|
Refactor code to allow multiple issue boards management for projects
in CE
|
|
This `ignore_column` was present for a while but recently removed, but
to ensure we don't get error 500s let's keep it for a while.
|
|
In https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21497, we
migrated all project import data into a separate table,
`project_import_data`. In addition, we also added:
```
ignore_column :import_status, :import_jid, :import_error
```
In https://gitlab.com/gitlab-com/gl-infra/production/issues/908, we
observed some of these `import_error` columns consumed megabytes of
error backtraces and caused slow loading of projects whenever a `SELECT
* from projects` query loaded the row into memory.
Since we have long migrated away from these columns, we can now drop
these columns entirely.
|
|
'master'
CE backport for gitlab-ee!13894 (Save repository_type to LfsObjectsProject)
See merge request gitlab-org/gitlab-ce!29179
|
|
This backports to CE changes that allow the recording of the
repository_type in the table lfs_objects_projects.
This is in order to allow future pruning of unreferenced LFS objects,
as we will need to know which repository to look in for the LFS pointer
file.
The EE MR that contains the original code and a full explanation of the
changes is
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/13894
EE Issue https://gitlab.com/gitlab-org/gitlab-ee/issues/9490
Note that there was a lot of CE code changed in the EE MR because we
want to allow the wiki repository to also use LFS. See
https://gitlab.com/gitlab-org/gitlab-ce/issues/43721. As the wiki is
an unlicensed feature, a full backport is required to enable this.
|
|
Consider the scenario:
1. The default visibility level is set to internal
2. A user attempts to create a private project within a private group
Previously this would always fail because default_value_for would
overwrite the private visibility setting, no matter what
visibility_level were specified. This was happening because
default_value_for was confused by the default value of 0 specified by
the database schema.
default_value_for attempts to assign the default value in the block by
checking whether the attribute has changed. The problem is that since
the default value by the database was 0, and the user requested 0, this
appeared as though no changes were made. As a result, default_value_for
would always overwrite the user's preference.
To fix this, we remove the use of default_value_for and only set the
visibility level to the default application setting when no preference
has been given at creation time.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63158
|
