Expose project details in the user pipelines API

Marcel van Remmerdenrequested to merge
feature/user-pipelines-api-expose-project into master

What does this MR do and why?

The instance-level endpoint GET /pipelines (introduced in !250635 (merged)) lists pipelines triggered by the authenticated user, but each entry only included project_id. Consumers who wanted to display a project name had to make an extra request per project.

This MR adds a project object to each pipeline entry in the response, containing basic project identity fields.

Implementation

  • Adds API::Entities::Ci::PipelineBasicWithProject, which subclasses PipelineBasicWithMetadata and exposes project using the existing API::Entities::ProjectIdentity entity (id, description, name, name_with_namespace, path, path_with_namespace, created_at).
  • lib/api/ci/user_pipelines.rb now presents this new entity instead of PipelineBasicWithMetadata.
  • Updates doc/api/pipelines.md (history note and example responses) and regenerates doc/api/openapi/openapi_v3.yaml.

Performance

No additional database queries are issued. The endpoint already scopes pipelines with Ci::Pipeline.with_api_entity_associations, which preloads the project along with its route and namespace route (PROJECT_ROUTE_AND_NAMESPACE_ROUTE) because building web_url already required them. The newly exposed project attributes read only from these already-preloaded records.

This is verified by the existing N+1 QueryRecorder spec in spec/requests/api/ci/user_pipelines_spec.rb ("avoids N+1 queries when pipelines from more projects are returned"), which still passes unchanged (21 examples, 0 failures).

The response payload grows by seven small scalar fields per pipeline, with at most 100 pipelines per page.

Backwards compatibility

This is a purely additive change: a new response field. No fields are removed, renamed, or change type, which is non-breaking under REST API v4 compatibility guidelines.

PipelineBasicWithMetadata itself is untouched, so GET /projects/:id/pipelines, which also uses it, returns exactly the same payload as before. The new entity is used only by GET /pipelines.

No changes to authentication, authorization, parameters, or status codes.

How to set up and validate locally

  1. Run GDK.

  2. Trigger or seed a pipeline as your user.

  3. Run:

    curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" --url "http://gdk.test:3000/api/v4/pipelines?per_page=5"

  4. Confirm each entry in the response contains a project object.

References

Merge request reports