- 05 Sep, 2019 1 commit
-
-
Fabio Pitino authored
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.
-
- 31 Aug, 2019 1 commit
-
-
dineshpanda authored
-
- 30 Aug, 2019 1 commit
-
-
Manoj MJ authored
This change limits the number of emails for new access requests notifications to 10 most recently active owners/maintainers
-
- 29 Aug, 2019 1 commit
-
-
George Koltsov authored
-
- 28 Aug, 2019 1 commit
-
-
Victor Zagorodny authored
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
-
- 26 Aug, 2019 1 commit
-
-
Zeger-Jan van de Weg authored
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.
-
- 21 Aug, 2019 1 commit
-
-
George Koltsov authored
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).
-
- 15 Aug, 2019 2 commits
-
-
Adam Hegyi authored
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.
-
Brett Walker authored
- Adds UI to configure in group and project settings - Removes notification configuration for users when disabled at group or project level
-
- 13 Aug, 2019 1 commit
-
-
Stan Hu authored
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
-
- 08 Aug, 2019 1 commit
-
-
Hordur Freyr Yngvason authored
As decided in https://gitlab.com/gitlab-org/gitlab-ce/issues/53593
-
- 07 Aug, 2019 2 commits
-
-
Tiger authored
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
-
Tiger Watson authored
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.
-
- 06 Aug, 2019 1 commit
-
-
Matija Čupić authored
-
- 05 Aug, 2019 1 commit
-
-
Nick Thomas authored
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.
-
- 31 Jul, 2019 1 commit
-
-
Tiger authored
All cluster resources are now created on demand when a deployment job starts.
-
- 25 Jul, 2019 1 commit
-
-
Matija Čupić authored
* 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
-
- 24 Jul, 2019 1 commit
-
-
Kamil Trzciński authored
- 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`
-
- 23 Jul, 2019 2 commits
-
-
Matija Čupić authored
Adds ability to find builds by sha when only specifying a ref.
-
Matija Čupić authored
Adds specs for testing the new behavior of specifying a pipeline when POSTing a status.
-
- 22 Jul, 2019 1 commit
-
-
Jan Provaznik authored
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 eb4acc986901
-
- 19 Jul, 2019 1 commit
-
-
Nick Thomas authored
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.
-
- 15 Jul, 2019 1 commit
-
-
Dmitriy Zaporozhets authored
Next models are affected: * Project * Namespace * Issue * Merge request * CI Trigger * CI Pipeline schedule Signed-off-by:
Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 13 Jul, 2019 1 commit
-
-
Daniel Danner authored
-
- 12 Jul, 2019 2 commits
-
-
Igor authored
-
Heinrich Lee Yu authored
Updates changed method names and fixes spec failures
-
- 10 Jul, 2019 2 commits
-
-
Mayra Cabrera authored
Suggests to use a JSON structured log instead Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/54102
-
Grzegorz Bizon authored
-
- 09 Jul, 2019 1 commit
-
-
James Ramsay authored
Object pools allow Git objects to be shared from the parent project to forks, reducing storage requirements.
-
- 03 Jul, 2019 1 commit
-
-
Mathieu Parent authored
We map the boolean to the string 'fetch' or 'clone', to be more explicit.
-
- 28 Jun, 2019 1 commit
-
-
Bob Van Landuyt authored
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
-
- 27 Jun, 2019 1 commit
-
-
Thong Kuah authored
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.
-
- 26 Jun, 2019 1 commit
-
-
Alexandru Croitor authored
Refactor code to allow multiple issue boards management for projects in CE
-
- 24 Jun, 2019 1 commit
-
-
Stan Hu authored
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.
-
- 19 Jun, 2019 1 commit
-
-
Stan Hu authored
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.
-
- 16 Jun, 2019 1 commit
-
-
Luke Duncalfe authored
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.
-
- 14 Jun, 2019 1 commit
-
-
Stan Hu authored
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
-
- 12 Jun, 2019 1 commit
-
-
Fabio Pitino authored
Enable Get and Update of ci_default_git_depth for Project API. Renaming Project#default_git_depth to :ci_default_git_depth to give more context through the API usage. Add API documentation
-
- 06 Jun, 2019 1 commit
-
-
Krasimir Angelov authored
Introduce default_git_depth in project's CI/CD settings and set it to 50. Use it if there is no GIT_DEPTH variable specified. Apply this default only to newly created projects and keep it nil for old ones in order to not break pipelines that rely on non-shallow clones. default_git_depth can be updated from CI/CD Settings in the UI, must be either nil or integer between 0 and 1000 (incl). Inherit default_git_depth from the origin project when forking projects. MR pipelines are run on a MR ref (refs/merge-requests/:iid/merge) and it contains unique commit (i.e. merge commit) which doesn't exist in the other branch/tags refs. We need to add it cause otherwise it may break pipelines for old projects that have already enabled Pipelines for merge results and have git depth 0. Document new default_git_depth project CI/CD setting
-
- 29 May, 2019 1 commit
-
-
Reuben Pereira authored
- On Operations settings page - On Metrics dashboard page
-