updates copy for workflow rules and rules failure messages

Store the first 10 errors in redis for 15 days

Changelog: added
EE: true

The `clear` method was not bound to the correct context, preventing it
from referencing the `input` property. This fixes it by properly binding
the method in the class constructor.

Changelog: fixed

We are dropping the work_item_types.namespace_id
column, so we first need to ignore it in this release (17.3)
so it can be dropped from the DB in 17.4

Shows just IID if same namespace
or full path if not same namespace.

This commit introduces an advisory lock at the lfs_objects_model level
to ensure uniqueness of new records (only one lfs_objects_project
per repository type).

After this, we need to add a migration that deduplicates
lfs_objects_projects by lfs_object_id, project_id and repository_type.
After the migration is finalized, we need to add a unique index on all
three columns to ensure data integrity since the unique validation
already exists at the model level.

Changelog: other

In an effort to help developers debug their local setup
and features, we are adding an info button to the perf
bar for local development. In this first step, we are
adding the host information inside this new modal.

Changelog: performance

Only in rspec context

Synchronously removes the index on project_statistics for wiki
size and project id, only for GitLab.com

Changelog: removed

Synchronously removes the index on project_statistics for packages
size and project id, only for GitLab.com

Changelog: removed

Add the left side of 'code flow' that including description and steps

Disable feature flag

Update 'vulnerability_file_contents' with new highlighted component

remove unnecessary code

move functions

fix pipeline errors

CR changes

Fix unit test

Fix error

With the introduction of the [RolledupDates] we also introduced
`WorkItems::DatesSource` model to be the work item single source of
truth for dates. However, the `StartAndDueDate` widget still writing
dates directly on the `issues` table.

To make matters worse, there's also some confusion between the
`RolledupDates` and the `StartAndDueDate` widgets, not writting to the
same table, making it hard to query work items based on their date
fields. Now with more knowledge, we see that the `RolledupDates` widget
should be actually just an EE extension for the already existing
`StartAndDueDate`.

To simplify all that, we need to:

1. https://gitlab.com/gitlab-org/gitlab/-/issues/469379: First, during
   this transition period, ensure that `issues` table is our initial
   Single Source of Truth for work items `star_date` and `due_date`
   fields. This where we introduced a database trigger to ensure every
   `start_date` and `due_date` writes on the `work_item_dates_sources`
   update the same fields in the `issues` table.
1. (>> this work) Ensure that `StartAndDueDate` widget writes to the
   `work_item_dates_sources` table. This way, both widgets are writting
   to the same place, which is synced with the `issues` table.
1. Change the `RolledupDates` widget to be an `EE` extension of the
   `StartAndDueDate` widget. This will simplify the ~frontend and
   ~backend as we will need to manage a single widget for the dates
   fields.
1. Migrate the `start_date` and `due_date` fields from `issues` table
   to the `work_item_dates_sources` table and ensure all writting of the
   `start_date` and `due_date` fields also writes to the
   `work_item_dates_sources` table (invert the `#1`). This is a larger
   work, and would block the migration of the Epics -> WorkItems, that's
   why it'll be done later.
1. Change all the readings of dates to be done through the
   `work_item_dates_sources` table, instead of issues `table`
1. Remove the `start_date` and `due_date` columns from the `issues`
   table.

Related to: https://gitlab.com/gitlab-org/gitlab/-/issues/470375

[RolledupDates]: https://gitlab.com/gitlab-org/gitlab/-/issues/409936

Previously if you ran this:

```
FOSS_ONLY=1 bundle exec rspec spec/models/audit_event_spec.rb \
    spec/support/shared_examples/lint_factories_shared_examples.rb
```

The shared example file hooks into whatever example groups are loading
and attempts to lint them, which is why the audit event model has to
run.

This would fail with `NameError: uninitialized constant
Gitlab::Audit::InstanceScope` because instance-type audit events are
only implemented in EE. To avoid this error, only define the
`instance_type` trait in EE.

Prevents errors if we rename models/columns of referenced data

Previously the second test would fail if you did this:

```
bundle exec rspec spec/lib/gitlab/redis/queues_spec.rb \
  spec/lib/gitlab/sidekiq_queue_spec.rb
```

This happens because the `@instances` class variable is memoized
by the first spec with some temporary settings. Clear this out
to ensure this doesn't pollute the global state.

Fixes bug on the Usage trends page in which the tooltips in the
Total projects & groups, Pipelines and Issues & Merge Requests charts
are empty upon fetching paginated data

Changelog: fixed

Changelog: fixed

GitLab 17.2 shipped a migration
(https://gitlab.com/gitlab-org/gitlab/-/merge_requests/158711) that
dropped `p_ci_builds.id`. However, we received a number of reports of
users who had unrelated sequences owned by `p_ci_builds.id`, so the
migration failed because the objects depended on that column existing.

To allow migrations to go through, scan the system catalog for all
sequences owned by either `p_ci_builds` or `ci_builds`. Generate the
`ALTER SEQUENCE` statement to update the ownership of the sequence
using the technique described in
https://wiki.postgresql.org/wiki/Fixing_Sequences.

Note that we could run all 600+ `ALTER SEQUENCE` commands to bring the
database to a consistent state, but to minimize risk we target only on
the ones to allow the CI builds migration to proceed.

Changelog: fixed

Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/468541

Since the `disable_git_http_fetch_writes` FF does not define
a feature flag actor, it is currently not possible to increment
the fetch project statistics without enabling or disabling it
for all projects.

This commit introduces the `allow_git_http_fetch_writes` FF
that allow us to control this and unskip the statistics
for specific projects.

Changelog: changed

Coung Ngo 创作于 8 months ago ，Stanislav Lashmanov 提交于 7 months ago

Adds confidential, group, and my-reaction filters

Behind feature flags
- work_item_epics
- work_item_epics_rollout
- namespace_level_work_items

Changelog: changed

## What does this MR do and why?

Add and backfill project_id for evidences.

This table has a
[desired sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#define-a-desired_sharding_key-to-automatically-backfill-a-sharding_key)
configured ([view configuration](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/docs/evidences.yml)).

This merge request is the first step towards transforming the desired sharding key into a
[sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables).

This involves three changes:

- Adding a new column that will serve as the sharding key (along with the relevant index and foreign key).
- Populating the sharding key when new records are created by adding a database function and trigger.
- Scheduling a [batched background migration](https://docs.gitlab.com/ee/development/database/batched_background_migrations.html)
  to set the sharding key for existing records.

Once the background migration has completed, a second merge request will be created to finalize the background
migration and validate the not null constraint.

## How to verify

We have assigned a random backend engineer from ~"group::compliance" to review these changes. Please review this merge
request from a ~backend perspective. The main thing we are looking to verify is that the added column and association
match the values specified by the [desired sharding key](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/docs/evidences.yml)
configuration and that backfilling the column from this other table makes sense in the context of this feature.

When you are finished, please:

1. Trigger the [database testing pipeline](https://docs.gitlab.com/ee/development/database/database_migration_pipeline.html)
   as instructed by Danger.
1. Request a review from the ~backend maintainer and ~database reviewer suggested by Danger.

If you have any questions or concerns, reach out to `@tigerwnz` or @manojmj.

This merge request was generated by a once off keep implemented in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/143774

This change was generated by
[gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper)
using the Keeps::BackfillDesiredShardingKeySmallTable keep.

To provide feedback on your experience with `gitlab-housekeeper` please comment in
<https://gitlab.com/gitlab-org/gitlab/-/issues/442003>.

Changelog: other

GraphQL filters out the SAML groups where the current user
is a member and the SAML session has expired because the
`needs_new_sso_session` condition in EE::GroupPolicy evaluates to true
for expired SAML sessions which in turn makes the `read_group` policy to
evaluate to false. This results in GraphQL returning less groups than
queried.

Here we filter out the inactive SAML session groups from the database
itself and return the expected number of groups requested by GraphQL
query.

Removes duplicate projects from the list when
selecting the project a child item should be
created in. If a project is in the 'Recently used'
group in the list, it will not appear in the
'Projects' group

Changelog: fixed

Initially we assumed that auto closing issues via merge request
was enabled for issues that exist at the group level. Now we
want to default to disabled if an issue exists at the group
level. In the future, we could add a setting to groups to add
the auto close feature. Better this way, as the other way, there's
no way to disable it.

Changelog: changed

Co-authored-by: Terri Chu <tchu@gitlab.com>

Click Flux sync badge to view resource details in a drawer.

Changelog: added

This change migrates the new UI
to use Vue Router rather than
direct url manipulation.

Part of a larger effort to move everything to Tailwind CSS

We track generic include file load times in the
`config_file_fetch_content_hash` metric. However, we might introduce a
feature that would increase the load times specifically when loading
components, so we need a metric that only tracks component content load
times.

Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/438275?work_item_iid=471843