Uploaded image for project: 'OpenShift Builds'
  1. OpenShift Builds
  2. BUILD-188

builds: Only use status to trigger builds

    XMLWordPrintable

Details

    • Story
    • Status: Closed
    • Undefined
    • Resolution: Done
    • None
    • None
    • builds-classic
    • 5
    • Sprint 203, Sprint 204, Sprint 205, Sprint 206, Sprint 207

    Description

      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?

      Attachments

        Activity

          People

            irum@redhat.com Alice Rum (Inactive)
            adkaplan@redhat.com Adam Kaplan
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: