User Story

As a developer using OpenShift for builds
I want ImageChanges to trigger builds based on information recorded in the BuildConfig status
So that I can use ImageChange triggers with builds in a GitOps workflow

Acceptance Criteria

• The last image ID used to trigger a build from a BuildConfig is recorded in the BuildConfig status this was done in 4.8
• The lastImageTriggeredID field in the BuildConfig spec is marked as deprecated this was done in 4.8
• Changes to lastImageTriggeredID field in the BuildConfig spec are ignored. this was done in 4.8
• lastImageTriggeredID is not updated in spec when an image change trigger is fired.
• We do not fire an event if `lastImageTriggeredID` is changed in the spec.
• e2e testing is updated so that it does not look for changes for image trigger ID in spec. This may include running specific test suites not run by default in origin (builds, image-registry).
• API godoc for this field reports that it is deprecated and will not be populated.

Docs Impact

Release note in 4.9 should indicate the field is completely ignored and will not be populated.

Launch Checklist

Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated

Notes

In OCP 4.8 the status field is already used to drive the image change trigger, however we are still populating the `spec` version of the field.

For OCP 4.9 we can get rid of this logic in openshift-apiserver. We may need to verify that the build and image change controllers don't set this field inside of openshift-controller-manager, and ensure e2e tests do not reference the spec version of the field.

The warning event in openshift-controller-manager should no longer be issued. The e2e test that detects this event should be removed.

The following extra e2e test suites need to be run:

1. Builds
2. Image Registry

Guiding Questions

User Story

• Is this intended for an administrator, application developer, or other type of OpenShift user?
• What experience level is this intended for? New, experienced, etc.?
• Why is this story important? What problems does this solve? What benefit(s) will the customer experience?
• Is this part of a larger epic or initiative? If so, ensure that the story is linked to the appropriate epic and/or initiative.

Acceptance Criteria

• How should a customer use and/or configure the feature?
• Are there any prerequisites for using/enabling the feature?

Notes

• Is this a new feature, or an enhancement of an existing feature? If the latter, list the feature and docs reference.
• Are there any new terms, abbreviations, or commands introduced with this story? Ex: a new command line argument, a new custom resource.
• Are there any recommended best practices when using this feature?
• On feature completion, are there any known issues that customers should be aware of?