What does this MR do and why?

This MR reverts !221493

In !221493, I introduced a change that would stub Current.organization for all requests specs (Grape specs). But that can mask errors because the actual code does not always have a Current.organization: it needs to be enabled per API.

So we need this disable this for request specs until #558544 is delivered.

References

• #558544
• !221493

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.

@rutgerwessels nicely done! backend LGTM! I don't think we need frontend review here right? Looks like it might have been triggered due to the lines removed in spec/frontend/fixtures/organizations.rb.

LMK if you agree and I can set MWPS 👍

Thanks for the cleanup @JonstonChan!

@garyh as per the roulette would you mind doing the maintainer review for Merge Requests backend? Thanks!

What does this MR do and why?

Fixes non-auto-correctable Style/NumberedParameters offenses

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

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 #589138

No problem @dbalexandre! If you have any more today send them my way. I'm on PTO from tomorrow until 23rd so for the others I'll pick these up when I'm back unless someone else takes them on 👍

::Geo::BulkPrimaryVerificationService

Good shout @c_fons! I've added that and your note about the verified_at index to the description 🙇

There's enough info for option A to go ahead here now so I'll mark this as refined.

So it's a trivial rake task to implement. For the UI work obviously that means we'd need to update the data management API - not a huge task but not trivial, as it's based on model and not state.

Yeah for this one I'm leaning towards the rake task due to this being a somewhat niche case of user error - misconfiguring the notifications or FF. Longer term I can imagine it would be a nice-to-have in the UI for all data types - i.e. being able to reverify more selectively by verified_at or created_at etc.

Thank you @trizzi - backend looks good to me! Setting MWPS 🟢

What does this MR do?

Adds a creator field to the packages API response, exposing information about the user who created the package.

Related issues

Related to: #589248 (comment 3107776882)

Problem

Manually published packages lack traceability. Users could not determine who uploaded a package through the API, making it difficult for product managers and auditors to verify that packages were uploaded by qualified individuals.

Solution

Expose the existing creator association (via creator_id column) in the packages API response. The creator field returns a UserBasic object containing:

• id
• username
• name
• state
• avatar_url
• web_url

The field is conditionally displayed:

• Only when the package has a creator (packages created via deploy tokens will have creator_id = null)
• Only when the requesting user has permission to view the creator (read_user ability)

Implementation details

File	Change
lib/api/entities/package.rb	Added creator exposure using UserBasic entity
app/models/packages/package.rb	Added preload_creator scope
app/finders/packages/package_finder.rb	Added creator preload to avoid N+1
app/finders/packages/packages_finder.rb	Added creator preload to avoid N+1
doc/api/packages.md	Updated API documentation
JSON schemas	Added optional creator field

I've updated the description on this issue to include some proposals for an implementation plan - I think the post FF enablement verification I mentioned above may be the least preferable in hindsight so I've added two additional options to explore -

• A - Ability to reverify container repos based on last verification (reverify items verified more than X days ago) - via a rake task or UI
• B - Ability to do the same as above but use the last_published_at from the ContainerRegistry API so we can find items which had activity

Both the above improve on the "just reverify everything" method we currently recommend in the docs and helps in situations where we know container registry replication was knocked out for X days.

It's a shame the last_published_at isn't queryable in the DB and is only available via an API so this one may not scale that well but it's worth investigating.

cc @mkozono @dbalexandre in case you guys have any extra thoughts on trying to improve the gap we have here 🙇

Scott Murray (21385cb3) at 13 Mar 22:58

Scott Murray (f4a2934b) at 13 Mar 22:58

... and 1 more commit

Purpose of revert

Reverts !224135. Per customer feedback, the behavioral change needs to be reimplemented behind a feature flag so self-managed admins can control when to enable it.

Checklist

• Create an issue to reinstate the merge request and assign it to the author of the reverted merge request.
  • Follow-up MR: !226913
• If the revert is to resolve a broken 'master' incident, please read through the Responsibilities of the Broken master resolution DRI. N/A
• If the revert involves a database migration, please read through Deleting existing migrations. N/A

Milestone info

• I am reverting something in the current milestone. No changelog is needed, and I've added a ~"regression:*" label.

Related issues and merge requests

• Reverts: !224135
• Follow-up: !226913
• Issue: #6054

Scott Murray (5474dbdb) at 13 Mar 18:26

Scott Murray (3a5fe08b) at 13 Mar 18:25

Scott Murray (315ab6e9) at 13 Mar 17:41

Scott Murray (5f25ea65) at 13 Mar 13:38

Scott Murray (3f6748c8) at 12 Mar 16:39

Purpose of revert

Reverts !224135. Per customer feedback, the behavioral change needs to be reimplemented behind a feature flag so self-managed admins can control when to enable it.

Checklist

• Create an issue to reinstate the merge request and assign it to the author of the reverted merge request.
  • Follow-up MR: !226913
• If the revert is to resolve a broken 'master' incident, please read through the Responsibilities of the Broken master resolution DRI. N/A
• If the revert involves a database migration, please read through Deleting existing migrations. N/A

Milestone info

• I am reverting something in the current milestone. No changelog is needed, and I've added a ~"regression:*" label.

Related issues and merge requests

• Reverts: !224135
• Follow-up: !226913
• Issue: #6054

Scott Murray (aaa78580) at 11 Mar 17:50

... and 1 more commit