Edit: https://gitlab.com/groups/gitlab-org/-/work_items/21373 may also affects this.

I was going to add that for Self-managed and Dedicated instances, we could auto derive the namespace as default

however, in the remote model, as @jdrpereira noted,

slug uniqueness can no longer be scoped to a single deployment. It needs to be globally unique across all connecting instances

which also means we cannot derive a default slug from organization name for Self-managed and Dedicated instances.

Rahul Chanila (2bad9ed7) at 17 Mar 04:29

... and 1 more commit

Rahul Chanila (81077ab3) at 17 Mar 04:29

What does this MR do and why?

Refactor Enable modals warning for AI catalog

No user facing changes

References

Screenshots or screen recordings

Scenario	ai_catalog_project_level_enablement FF off	ai_catalog_project_level_enablement FF on
Developer - Public agent
Developer - Private agent
Maintainer - Public agent
Maintainer - Private agent

How to set up and validate locally

1. Test with and without the FF

   Feature.enable(:ai_catalog_project_level_enablement)

2. From the AI Catalog, try enabling agents, flows and external agents with different permission and visibility scenarios

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #591866 Solves: #592413

What does this MR do and why?

Refactor Enable modals warning for AI catalog

No user facing changes

References

Screenshots or screen recordings

Scenario	ai_catalog_project_level_enablement FF off	ai_catalog_project_level_enablement FF on
Developer - Public agent
Developer - Private agent
Maintainer - Public agent
Maintainer - Private agent

How to set up and validate locally

1. Test with and without the FF

   Feature.enable(:ai_catalog_project_level_enablement)

2. From the AI Catalog, try enabling agents, flows and external agents with different permission and visibility scenarios

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #591866 Solves: #592413

Rahul Chanila (824986cc) at 17 Mar 02:51

What does this MR do and why?

Expands the available retention period options for container registry cleanup policies to address two customer needs:

1. Shorter retention periods - Users with ephemeral pipeline images (e.g., images built per-pipeline that are only used for the duration of that pipeline) need to clean up images sooner than 7 days to reduce storage usage.

2. Longer retention periods - Customers with production or compliance-grade artifacts need retention windows that reflect real-world software lifecycle needs, often spanning one to three years.

New options added:

Related to #592757 and #353047

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist.

How to set up and validate locally

1. Navigate to a project's Settings > Packages and registries > Cleanup policies
2. Verify the "Remove tags older than" dropdown shows all new options (1 day through 3 years)
3. Select a new option and save - verify it persists

Database

No database migration required. The older_than column is character varying(12) with no constraints on values - validation is handled at the Rails model level.

Looks great, thanks!

What does this MR do and why?

Refactor Enable modals warning for AI catalog

No user facing changes

References

Screenshots or screen recordings

Scenario	ai_catalog_project_level_enablement FF off	ai_catalog_project_level_enablement FF on
Developer - Public agent
Developer - Private agent
Maintainer - Public agent
Maintainer - Private agent

How to set up and validate locally

1. Test with and without the FF

   Feature.enable(:ai_catalog_project_level_enablement)

2. From the AI Catalog, try enabling agents, flows and external agents with different permission and visibility scenarios

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #591866 Solves: #592413

Left some minor suggestions, looks good otherwise @fguibert

nit: this test is redundant since the next line is already tests the component

suggestion(a11y, non-blocking): Link with just Learn more is not descriptive for accessibility, https://design.gitlab.com/patterns/contextual-help/#link-text I think we should get some input from the docs team to improve this.

question: should https://gitlab.com/gitlab-org/gitlab/-/blob/591866-refactor-enable-modals-warning-for-ai-catalog-item/ee/app/assets/javascripts/ai/duo_agents_platform/components/catalog/add_third_party_flow_warning.vue also be removed?

Thanks for your input.

Since these feature flags are enabled, the checks to check maven & container features run whenever users navigate to the groups page because of the side nav entry. I think it is better to keep this optimised. thoughts @mkhalifa3 ?

What does this MR do and why?

Expands the available retention period options for container registry cleanup policies to address two customer needs:

1. Shorter retention periods - Users with ephemeral pipeline images (e.g., images built per-pipeline that are only used for the duration of that pipeline) need to clean up images sooner than 7 days to reduce storage usage.

2. Longer retention periods - Customers with production or compliance-grade artifacts need retention windows that reflect real-world software lifecycle needs, often spanning one to three years.

New options added:

Related to #592757 and #353047

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist.

How to set up and validate locally

1. Navigate to a project's Settings > Packages and registries > Cleanup policies
2. Verify the "Remove tags older than" dropdown shows all new options (1 day through 3 years)
3. Select a new option and save - verify it persists

Database

No database migration required. The older_than column is character varying(12) with no constraints on values - validation is handled at the Rails model level.

Thanks for the contribution 🙇🏽 Looks good to me, minor UX thought, maybe the dropdown should read years instead of days for these.

Merged in %18.10, closing issue.

Merged in %18.10, closing issue.