Uploaded image for project: 'OpenShift Jenkins'
  1. OpenShift Jenkins
  2. JKNS-344

Design and Document second phase of self-verification process for Jenkins bugs/CVEs

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Normal Normal
    • None
    • None
    • jenkins-server
    • Build + Jenkins Sprint #234, Pipeline Integrations #235, Pipeline Integrations #236

      User Story

      As a maintainer of the Jenkins images I want to have a fully documented  process for kicking off testing of an image that is created by CPaaS in a semi to fully automated way to further verify that the image is working correctly before it is published.

      Acceptance Criteria

      • Documentation is available in a Google Doc (the same one as the Phase I verification) in the teams Google Drive
        • Documentation has been reviewed by the team
        • Add screenshots where applicable for clarity
        • ¬†
      • Any scripts that help to automate the verification workflow are merged into the openshift/jenkins repository under the `scripts` directory
        • Scripts have been reviewed by the team
      • Stretch Goal
        • Potentially add the verification documentation to the openshift/jenkins github repo docs folder as a markdown file

      QE Impact

      Since we are now responsible for the QE of the Jenkins images, there is no direct impact to the QE team, though this will help clarify the verification process if a member of the QE team becomes available in the future.

      Docs Impact

      No impact to the Docs team as this is internal verification of the produced images

      PX Impact

      There is no impact to the PX team as this is internal verification of the produced images

      Launch Checklist

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

      Notes

      Add pertinent notes here:

      • Enhancement proposal link
      • Previous product docs
      • Best practices
      • Known issues

      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?

      QE Impact

      • How can QE verify the story works as intended?
      • Can QE automate some or all of the verification?

      Docs Impact

      • What documentation will users need to utilize the feature in the story?
      • Who will write the docs? Who will edit/approve the docs, and when?

      PX Impact

      • Will customers need supplemental materials beyond documentation?
      • Will CEE/support need any additional materials to debug this feature or help a customer?

      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?

            rh-ee-apjagtap Apoorva Jagtap
            cdaley Corey Daley
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: