PUT/DELETE methods for /repositories/{id}/builds

[akash2237778]

For implementing DELETE/PUT methods for /repositories/{id}/builds endpoint we need to figure out a plan for handling the consequences of deleting/modifying a build. There will be various scenarios to deal with:

• What should happen if the build is deleted/modified before the start? Do we count that (deleted/unmodified) build and maintain history OR simply eliminate/update it as nothing was posted.
• What should happen if the build is started but not finished yet?
• What should happen if some/all deployments have been notified?
• If the solution has something to do with history or revert back to the previous build, then we also need to figure out for corner cases like DELETE/PUT request after the first build.

Broker Specs (broker.yaml)
Broker Swagger UI

[lvarin]

What should happen if the build is deleted/modified before the start? Do we count that (deleted/unmodified) build and maintain history OR simply eliminate/update it as nothing was posted.

I like the idea of marking it as CANCELED, and keep the information we have about it

What should happen if the build is started but not finished yet?

Again, I think it should be marked as CANCELED

What should happen if some/all deployments have been notified?

This is interesting. If the deployment have been notified, it means there was an image already built. It the image/build is then deleted, the deployment pulling it will fail. This should only happen if the image is dangerous or unsecured, and then a new fixed image should be built by the developer.

If the solution has something to do with history or revert back to the previous build, then we also need to figure out for corner cases like DELETE/PUT request after the first build.

In docker hub, when a tag is deleted, the tag is lost. Docker hub will not allow you to come back to a previous tag. So IMHO losing the image is the desired outcome. There should be a history in the API of past builds even the deleted/canceled ones.