Feature Overview

The Argo CD Image Updater is a popular project, but its maintenance is currently non-existing. It is a one-person show with that person not having proper time to perform maintenance.

There are a lot of open issues and PRs that are not being worked on, and the last release is over a year ago. The community is upset.

Goals

Contributors and customers will benefit from this feature because its implementation will ensure that new features and bug fixes will be merged in a timely manner, and the quality of the code base and future releases will improve vastly.

The main goals are:

• Establish at least two persons from the GitOps team as maintainers in the project. Technically, this is easy (we have full governance), but people need to understand how Image Updater works and how it's being used.
• Establish Red Hat as a trusted partner for customers and users of Image Updater,
• Going forward, ensure no regressions are introduced with new features or modifications of existing code while avoiding as much manual testing as possible by covering important use cases in an automated way,
• Decrease time-to-market for new features and bug fixes,

While the Image Updater has extensive unit test coverage (>60%) already, this is not sufficient to ensure that new or modified code will not break important use cases.

In order for developers, contributors and reviewers to be fairly confident that a change will not introduce a regression.

Right now, the effort of testing this in an end-to-end manner is mainly manual, tedious and requires a lot of manual labor.

Requirements

Use Cases

• As a customer, I want to know that the project is actively maintained and supported by Red Hat
• As a customer, I want to rest ensured that a new release I am going to install meets production quality and does not introduce new regressions
• As an external contributor, I want my contribution to be included as quickly as possible
• As a maintainer and reviewer, I want to rest ensured that the code I review and approve does not break existing functionality

Out of scope

• Developing a manual testing process or strategy
• Nominating external maintainers (that can come at a later point)

Dependencies

<Link or at least explain any known dependencies.>

Background, and strategic fit

<What does the person writing code, testing, documenting need to know?>

Assumptions

<Are there assumptions being made regarding prerequisites and dependencies?>

<Are there assumptions about hardware, software or people resources?>

Customer Considerations

<Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

Documentation/QE Considerations

<What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?>

<Does this feature have a doc impact? Possible values are: New Content, Updates to existing content,  Release Note, or No Doc Impact?>

<Are there assumptions being made regarding prerequisites and dependencies?>

<Are there assumptions about hardware, software or people resources?>

Impact

<If the feature is ordered with other work, state the impact of this feature on the other work>

Related Architecture/Technical Documents

<links>

Definition of Ready

• The objectives of the feature are clearly defined and aligned with the business strategy.
• All feature requirements have been clearly defined by Product Owners.
• The feature has been broken down into epics.
• The feature has been stack ranked.
• Definition of the business outcome is in the Outcome Jira (which must have a parent Jira).

• …