Use project scopes to filter project labels
Add changelog file
Check issuables visibility in LabelsFinder
Add specs for issuables visibility cases
Rename Project method to reuse in LabelsFinder
Remove commented code
Improve changelog title
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
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
**Prevention of running 2 simultaneous updates**
Instead of using `RemoteMirror#update_status` and raise an error if
it's already running to prevent the same mirror being updated at the
same time we now use `Gitlab::ExclusiveLease` for that.
When we fail to obtain a lease in 3 tries, 30 seconds apart, we bail
and reschedule. We'll reschedule faster for the protected branches.
If the mirror already ran since it was scheduled, the job will be
skipped.
**Error handling: Remote side**
When an update fails because of a `Gitlab::Git::CommandError`, we
won't track this error in sentry, this could be on the remote side:
for example when branches have diverged.
In this case, we'll try 3 times scheduled 1 or 5 minutes apart.
In between, the mirror is marked as "to_retry", the error would be
visible to the user when they visit the settings page.
After 3 tries we'll mark the mirror as failed and notify the user.
We won't track this error in sentry, as it's not likely we can help
it.
The next event that would trigger a new refresh.
**Error handling: our side**
If an unexpected error occurs, we mark the mirror as failed, but we'd
still retry the job based on the regular sidekiq retries with
backoff. Same as we used to
The error would be reported in sentry, since its likely we need to do
something about it.
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.
Remove project from NotesFinder constructor
Add project parameter to specs
Also look for methods in private scope
Fix specs to match new NotesFinder constructor
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
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 8c0923babf.
Method is no longer needed
Check whether noteable can be read by user
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.
**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.
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
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.
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.
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.
Implement new arguments `state`, `closed_before` and `closed_after` for `IssuesResolver` in GraphQL
Closes#56492
See merge request gitlab-org/gitlab-ce!24910
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.
Instead of querying relations into ids we just pass them to the model
scope because the scope supports it now.
Also changes other calls to `Milestone.for_projects_and_groups`
This commit introduces Releases API under /api/v4/projects/:id/releases
* We are introducing release policies at project level.
* We are deprecating releases changes from tags, both api and web
interface.
* Tags::CreateService no longer create a release
This feature is controlled by :releases_page feature flag
We're filtering the events using `Event#visible_to_user?`.
At most we're loading 100 events at once.
Pagination is also dealt with in the finder, but the resulting array
is wrapped in a `Kaminari.paginate_array` so the API's pagination
helpers keep working. We're passing the total count into that
paginatable array, which would include confidential events. But we're
not disclosing anything.
Given the note is about how to interpret ancestor clusters, use the
finder which actually knows if there are any ancestor clusters to find
out if the note should be shown, rather than passing the same info via a
view to a helper
Added note about Kaminari.paginate_array
Link to followup issue too
We already had a flag to use a CTE, but this broke searching in some
cases where we need to sort by a joined table. Disabling the CTE flag
makes searches much slower.
The new flag, to use a subquery, makes them slightly slower than the
CTE, while maintaining correctness. If both it and the CTE flag are
enabled, the subquery takes precedence.
By using the parameters `?labels=None|Any` the user can filter
issues/mrs from the API that has `none/any` label.
Affected endpoints are:
- /api/issues
- /api/projects/:id/issues
- /api/groups/:id/issues
- /api/merge_requests
- /api/projects/:id/merge_requests
- /api/groups/:id/merge_requests