| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
'62284-follow-up-from-resolve-api-to-get-all-project-group-members-returns-duplicates' into 'master'
Resolve "Follow-up from "Resolve "API to get all project/group members returns duplicates"""
Closes #62284
See merge request gitlab-org/gitlab-ce!28887
|
|
|
|
Adding, destroying and toggling emoji previously lacked services and
instead were performed through methods called on Awardable models.
This led to inconsistencies where relevant todos would be marked as done
only when emoji were awarded through our controllers, but not through
the API. Todos could also be marked as done when an emoji was being
removed.
Behaviour changes
- Awarding emoji through the API will now mark a relevant Todo as done
- Toggling an emoji off (destroying it) through our controllers will no
longer mark a relevant Todo as done
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63372
|
|
This finder class acts more as a service, as it only returns mapped
data.
Renaming this class allows us to create a new AwardEmojiFinder without
the ambiguity of there being two similarly-named finders.
https://gitlab.com/gitlab-org/gitlab-ce/issues/63372
|
|
'4221-board-milestone-should-persist-any-none-properly-ce' into 'master'"
This reverts merge request !30613
|
|
|
|
|
|
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.
|
|
API endpoints for requesting container repositories
and container repositories with their tag information
are enabled for users that want to specify the group
containing the repository rather than the specific project.
|
|
Use NotesFinder to fetch notes on API and Controllers
Closes #52123
See merge request gitlab-org/gitlab-ce!31300
|
|
Remove project from NotesFinder constructor
Add project parameter to specs
Also look for methods in private scope
Fix specs to match new NotesFinder constructor
|
|
- DB migration of board milestone values
- issue finder & spec updates
|
|
We dropped MySQL support and a lot of mysql specific code has been
removed in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29608.
This comes in from the other direction and removes any `if postgresql?`
branches.
|
|
'master'"
This reverts merge request !29733
|
|
Use NotesFinder to fetch notes in module IssuableActions
Closes #52123
See merge request gitlab-org/gitlab-ce!29733
|
|
Add spec for concern IssuableActions
Add shared samples for discussions endpoint
Add schema validations for discussions
Fix rubocop style issue
Make target assignable
Use new possibility to provide target
|
|
These are not required because MySQL is not
supported anymore
|
|
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
|
|
|
|
|
|
Add released_at field to releases API
Add released_at column to releases table
Return releases to the API sorted by released_at
|
|
Add endpoint for fetching diverging commit counts
See merge request gitlab-org/gitlab-ce!29802
|
|
Extract diverging_commit_counts into a service class
|
|
Refactor code to allow multiple issue boards management for projects
in CE
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Fix missing iid query on NotesFinder
Changed parameters of find_noteable,
so changes across a few files were needed.
MergeRequest also requires iid instead of id query
Make NotesFinder fail with RecordNotFound again
Add specs for target_iid
Using RSpec tablesyntax for target_iid specs
Revert "Using RSpec tablesyntax for target_iid specs"
This reverts commit ba45c7f569a.
Allow find_by! here
Fix variable name
Add readable check
Revert "Add readable check"
This reverts commit 9e3a1a7aa39.
Remove unnecessary assignment
Add required changes for EE
Fix parameter count
Reduce code duplication by extracting a noteable module method
The call to find_noteable was redundant so
multiple files and lines have changed in that
commit to use the newly introduced module
method `noteable`.
Replace casecmp with include check
Add parent_type parameter
Revert "Reduce code duplication by extracting
a noteable module method"
This reverts commit 8c0923babff16.
Method is no longer needed
Check whether noteable can be read by user
|
|
updated documentation for Geo
|
|
Preventing blocked users and their PipelineSchdules from creating new Pipelines
Closes #47756
See merge request gitlab-org/gitlab-ce!27318
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
updated several specs and factories to accomodate new permissions
|
|
Clusters::Cluster::KnativeServicesFinder becomes
Clusters::KnativeServicesFinder
This is to avoid loading race condition between:
```
module Clusters
class Cluster < ApplicationRecord
```
and
```
module Clusters
class Cluster
```
|
|
Remove Kn services cache from Clusters::Application::Knative
Knative function can exist even if user did not installed Knative via
GitLab managed apps.
-> Move responsibility of finding services into the Cluster
-> Responsability is inside Clusters::Cluster::KnativeServiceFinder
-> Projects::Serverless::FunctionsFinder now calls depends solely on a
cluster to find the Kn services.
-> Detect Knative by resource presence instead of service presence
-> Mock knative_installed response temporarily for frontend to develop
Display loader while `installed === 'checking'`
Added frontend work to determine if Knative is installed
Memoize with_reactive_cache(*args, &block) to avoid race conditions
When calling with_reactive_cache more than once, it's possible that the
second call will already have the value populated. Therefore, in cases
where we need the sequential calls to have consistent results, we'd fall
under a race condition.
Check knative installation via Knative resource presence
Only load pods if Knative is discovered
Always return a response in FunctionsController#index
- Always indicate if Knative is installed, not installed or checking
- Always indicate the partial response for functions. Final response is
guaranteed when knative_installed is either true | false.
Adds specs for Clusters::Cluster#knative_services_finder
Fix method name when calling on specs
Add an explicit check for functions
Added an explicit check to see if there are any functions available
Fix Serverless feature spec
- we don't find knative installation via database anymore,
rather via Knative resource
Display error message for request timeouts
Display an error message if the request times out
Adds feature specs for when functions exist
Remove a test purposed hardcoded flag
Add ability to partially load functions
Added the ability to partially load functions on the frontend
Add frontend unit tests
Added tests for the new frontend additions
Generate new translations
Generated new frontend translations
Address review comments
Cleaned up the frontend unit test.
Added computed prop for `isInstalled`.
Move string to constant
Simplify nil to array conversion
Put knative_installed states in a frozen hash for better read
Pluralize list of Knative states
Quey services and pods filtering name
This way we don't need to filter the namespace in memory.
Also, the data we get from the network is much smaller.
Simplify cache_key and fix bug
- Simplifies the cache_key by removing namespace duplicate
- Fixes a bug with reactive_cache memoization
|
|
When using the members/all api the same user was returned multiple times
when he was a member of the project/group and also of one of the
ancestor groups.
Now the member is returned only once giving priority to the membership
on the project and maintaining the same behaviour of the members UI.
|
|
Removed the conditions added to
Project.with_feature_available_for_user, and moved to the
IssuableFinder. Now, we ensure that, in the projects retrieved
in the Finder, the user has enough access for the feature.
|
|
There are two cluster hierarchies one for the deployment platform and
one for controllers. The main difference is that deployment platforms do
not check user permissions and only return the first match.
|
|
|
|
spec/features/groups/group_page_with_external_authorization_service_spec to EE
|
|
Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161
(code out of ee/ folder).
|
|
|
|
This reverts merge request !26823
|
|
spec/features/groups/group_page_with_external_authorization_service_spec to EE
|
|
Extend CTE search optimisation to projects
Closes #55170
See merge request gitlab-org/gitlab-ce!26908
|
|
- rewords examples starting with 'should'
- rewords examples starting with 'it'
Note: I had to manually fixup "onlies" to "only"
|
|
**Why?**
Currently the IDE loads a merge request based on only the
`source_branch` name. This means it loads MR's from
forks that have the same branch name (not good).
- This required updating the BE API to accept `source_project_id`
|
|
When we use the `search` param on an `IssuableFinder`, we can run into
issues. We have trigram indexes to support these searches. On
GitLab.com, we often see Postgres's optimiser prioritise the (global)
trigram indexes over the index on `project_id`. For group and project
searches, we know that it will be quicker to filter by `project_id`
first, as it returns fewer rows in most cases.
For group issues search, we ran into this issue previously, and went
through the following iterations:
1. Use a CTE on the project IDs as an optimisation fence. This prevents
the planner from disregarding the index on `project_id`.
Unfortunately it breaks some types of sorting, like priority and
popularity, as they sort on a joined table.
2. Use a subquery for listing issues, and a CTE for counts. The subquery
- in the case of group lists - didn't help as much as the CTE, but
was faster than not including it. We can safely use a CTE for counts
as they don't have sorting.
Now, however, we're seeing the same issue in a project context. The
subquery doesn't help at all there (it would only return one row, after
all). In an attempt to keep total code complexity under control, this
commit removes the subquery optimisation and applies the CTE
optimisation only for sorts we know that are safe.
This means that for more complicated sorts (like priority and
popularity), the search will continue to be very slow. If this is a
high-priority issue, we can consider introducing further optimisations,
but this finder is already very complicated and additional complexity
has a cost.
The group CTE optimisation is controlled by the same feature flag as
before, `attempt_group_search_optimizations`, which is enabled by
default. The new project CTE optimisation is controlled by a new feature
flag, `attempt_project_search_optimizations`, which is disabled by
default.
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
