Skip to content

Extend Ci::Bridge to be compatible with Build method calls

Hunter Stewart requested to merge hustewart-bridge-no-method into master

Why

See #428465 (closed) for more context. There are new failures in the REST api for deployments and environments.

As Deployable behavior was introduced into Ci::Bridge, it caused a regression in the API because previously we only expected Ci::Build to get exposed in Entities::Deployment. Once Ci::Bridge started getting exposed, it didn't have the required attributes and so failed with NoMethodError.

What

This MR adds a spec that reproduces the error reported in the issue linked.

Before updating the entities, the spec fails with:

Failures:

  1) API::Environments GET /projects/:id/environments/:environment_id when the deployable is a bridge returns project environments
     Failure/Error: expect(response).to have_gitlab_http_status(:ok)
       expected the response to have status code :ok but it was 500. The response was: {"message":"\nNoMethodError (API::Entities::Ci::Job missing attribute `job_artifacts' on #\u003cCi::Bridge:0x000000016d4fc0b8\u003e\n\n            is_delegatable || raise(\n                              ^^^^^):\n

The resolve the issue this MR updates the Entities::Deployment to expose different entities conditionally based on the deployment's associated deployable's type, with the goal of still abiding by the documented API response.

[UPDATE] We also ended up needing to change a select clause that was including Ci::Bridge where we only want Ci::Build

Note

This MR also drops the expose downstream_pipeline from the existing Ci::Bridge entity. I couldn't find the Ci::Bridge entity being used anywhere in the code and wasn't sure what this part was trying to accomplish. Deleting this part simplifies the entity into a state where it's just allowing the api requests to be satisfied. It's not trying to return anything useful at this point when the deployable is Ci::Bridge.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Hunter Stewart

Merge request reports