-
Story
-
Resolution: Done
-
Normal
-
None
-
None
-
3
-
False
-
None
-
False
-
SECFLOWOTL-23 - Simplify Jenkins release process
-
None
-
-
-
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?
- links to
-
RHBA-2023:123028 Release of Bug Advisories for the OpenShift Jenkins and Jenkins agent base image
-
RHSA-2023:123027 Red Hat Product OCP Tools 4.14 Openshift Jenkins security update
-
RHSA-2024:127223 Red Hat Product OCP Tools 4.14 Openshift Jenkins security update
-
RHSA-2024:137336 Red Hat Product OCP Tools 4.14 OpenShift Jenkins security update
- mentioned on