- 08 May, 2020 1 commit
-
-
Georges Racinet authored
The main advantage is that this looks more uniform from the upper layers, at the price of making `Git::Repository.create_repository` accept arbitrary arguments. Also `Gitlab::Shell` is slowly being faded away. By calling the raw repo's `create_repository` we are actually anticipating on later versions. The saner structure can be also be felt in that we don't need to give some methods a classmethod version any more. --HG-- branch : heptapod
-
- 31 Mar, 2020 1 commit
-
-
Georges Racinet authored
In the case of the hashed storage, we keep a subset of the directory hierarchy for namespaces and the repo HGRC includes from that, hence depending on the namespace path from the storage root and the depth of the hashed storage (currently a constant, at two intermediate subdirectories). In both the hashed and non-hashed cases, this is provided by `relative_path_from`, whose result is just `../../hgrc` in the non hashed case. The inclusion path is relative to the storage root, hence this independent of the storage location, which can change (reconfig, change of host by backup & restore) with no need to crawl through repositories. This partially defeats one of the advantages of the hash storage: avoiding too much top level directories. This shouldn't be critical for Heptapod because 1. By the time we have instances that big that this cluttering is a problem, assuming we just don't use a FS with hashmap directories (XFS for instance), we'll be able to come up with other mechanisms 2. It's about namespaces having either HGRC settings or subgroups. These should be the minority. After all, using subgroups reduces the number of toplevel groups. --HG-- branch : heptapod
-
- 18 Feb, 2020 1 commit
-
-
Georges Racinet authored
This anticipates a bit on the future `"hg"` value for `vcs_type`, but it's easy to use from various parts of the code. --HG-- branch : heptapod
-
- 25 Jan, 2020 1 commit
-
-
Georges Racinet authored
Before this change, Mercurial repo creation wasn't executed if the Git repo was to be created with Gitaly. This is also the occasion to simplify the diff with respect to GitLab. The add_hg_repository method has useless blocks in this commit, just so that the diff against the parent stays minimal We also take care of the wiki even though it's not it use within Heptapod so that - we don't make it worse - we don't got in the way of repo destruction (the Git wiki repo is removed only after successful remove of the Mercurial) --HG-- branch : heptapod
-
- 05 Jan, 2020 1 commit
-
-
Georges Racinet authored
The gemnasium-gitlab-service gem is not available anymore, making the Rails app impossible to build and start from the given Gemfile. It would be completely useless anyway, because the Gemnasium service has closed, following the buyout by GitLab. Hence we remove anything about Gemnasium from Heptapod. --HG-- branch : heptapod
-
- 17 Dec, 2019 1 commit
-
-
Georges Racinet authored
Actually, 10.4.0-rc2 was not in the main history line that was Git master at the time, so we're reverting to b40d600d09d9. Also, we had some remnants from 10.3.x security fixes (notably the wrapping of HTTParty into GitLab::HTTP, and the symlink protection in imports) Of course concrete Heptapod versions will be made with merges from GitLab stable branches that will put all stability and security fixes back. It's probably more interesting to look at the resulting diff with b40d600d09d9 than at the diff of the present revision. --HG-- branch : heptapod
-
- 10 Nov, 2019 1 commit
-
-
Georges Racinet authored
While top level groups don't need to have an HGRC (inclusion of a non existant HGRC does nothing), subgroups need to propagate to the group. --HG-- branch : heptapod
-
- 01 Oct, 2019 1 commit
-
-
Mark Chao authored
Add spec to test different combinations. Accept string for required_minimum_access_level Allow more flexible project membership query
-
- 20 Sep, 2019 1 commit
-
-
GitLab Bot authored
-
- 18 Sep, 2019 2 commits
-
-
GitLab Bot authored
-
GitLab Bot authored
-
- 17 Sep, 2019 1 commit
-
-
GitLab Bot authored
-
- 16 Sep, 2019 1 commit
-
-
GitLab Bot authored
-
- 13 Sep, 2019 2 commits
-
-
GitLab Bot authored
-
GitLab Bot authored
-
- 10 Sep, 2019 2 commits
-
-
Douglas Barbosa Alexandre authored
-
Krasimir Angelov authored
Update the `/internal/pages` endpoint to return virtual domain configuration for custom domains.
-
- 09 Sep, 2019 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 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.
-