| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
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.
|
|
When Kubernetes clusters were originally built they could only
exist at the project level, and so there was logic included
that assumed there would only ever be a single Kubernetes
namespace per cluster. We now support clusters at the group
and instance level, which allows multiple namespaces.
This change consolidates various project-specific fallbacks to
generate namespaces, and hands all responsibility to the
Clusters::KubernetesNamespace model. There is now no concept of
a single namespace for a Clusters::Platforms::Kubernetes; to
retrieve a namespace a project must now be supplied in all cases.
This simplifies upcoming work to use a separate Kubernetes
namespace per project environment (instead of a namespace
per project).
|
|
|
|
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.
|
|
This was removed by a previous MR but broke some links
|
|
|
|
|
|
This reverts merge request !26481
|
|
Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161
(code out of ee/ folder).
|
|
|
|
Extend CTE search optimisation to projects
Closes #55170
See merge request gitlab-org/gitlab-ce!26908
|
|
**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`
|
|
This fixes the bug, when approver filter is provided,
but dashboard asks to enter any filter
|
|
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.
|
|
|
|
Previously when a user requested a list of projects,
`Project#public_or_visible_to_user` would search all authorized projects
and public/internal projects as well. However, when a user requests a
specific `visibility_level` (e.g. private), that should reduce the
search space, and we shouldn't need to load public/internal projects.
Improves https://gitlab.com/gitlab-org/gitlab-ce/issues/59329
|
|
The Upcoming milestone filter only considers active milestones, but the
Started one included closed milestones, too. This was inconsistent.
|
|
|
|
Previously, you could only access personal snippets in the API if you
had authored them. The documentation doesn't state that this is the
case, and it's quite surprising.
|
|
|
|
Don't allow non-members to see private related MRs
Closes #2787
See merge request gitlab/gitlabhq!2866
|
|
IssuableFinder - Always use CTE for group counts
Closes #54643
See merge request gitlab-org/gitlab-ce!25411
|
|
Since the CTE is faster than a subquery and the only reason we're using
a subquery is that the CTE can't handle sorting by certain attributes,
let's use the CTE always (when the feature flag is enabled) when
counting, since we can ignore ordering if we just want a count of
results.
|
|
|
|
Due to performance reasons we cannot use the type filter on the tags.
The table for ActsAsTaggableOn is too big and too unoptimized, such that
the queries time out on production.
See the discussion
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19740#note_120087938
for more info.
|
|
The query generated by ActsAsTaggableOn `@taggable_type.all_tags` is
very inefficient (joins too much, grouping, inner select, ...).
|
|
the potential number of available runner tags is too large to load it
statically to a dropdown. we use the same lazy loaded dropdown as is
used for the users dropdown already.
|
|
|
|
Resolve "Project fetch statistics API (HTTP only)"
Closes #42086
See merge request gitlab-org/gitlab-ce!23596
|
|
The API get projects/:id/traffic/fetches allows user with write
access to the repository to get the number of clones for the
last 30 days.
|
|
As discussed in https://github.com/mbleigh/acts-as-taggable-on/issues/91,
we can avoid N+1 queries if we use `tags` instead of `tag_list`.
Seen while reviewing
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19740.
|
|
Fix misspellings in app/spec comments
See merge request gitlab-org/gitlab-ce!25517
|
|
Ability to filter confidential issues
Closes #50747
See merge request gitlab-org/gitlab-ce!24960
|
|
This reverts commit 9202bbd129537a698b986e6295d0c783b5a84815, reversing
changes made to 4b282e9ce1ae246c4538b3ede18d1380ea778029.
|
|
This reverts commit d133bf84c668df3dfc9938bb04150754cb873c8b, reversing
changes made to 7981c0292b07a0138b096fa082341fcb13e9ce2b.
|
|
Ability to filter confidential issues
Closes #50747
See merge request gitlab-org/gitlab-ce!24960
|
|
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>
|
|
Use internally only boolean params.
|
|
'56492-implement-new-arguments-state-closed_before-and-closed_after-for-issuesresolver-in-graphql' into 'master'
Implement new arguments `state`, `closed_before` and `closed_after` for `IssuesResolver` in GraphQL
Closes #56492
See merge request gitlab-org/gitlab-ce!24910
|
|
|
|
Add a new search bar filter for confidential issues. Add filtering
support to the IssuesFinder.
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
We shouldn't care about the ordering here; if we did, it would be more
appropriate to use `take` or `first`. Having the ordering can result in
the database picking a bad query plan, as it might think sorting the
whole table first is the best option.
|
|
|
|
Add 'in' filter that modifies scope of 'search' filter to issues and merge requests API
See merge request gitlab-org/gitlab-ce!24350
|
|
|
|
|
