-
Feature Request
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
False
-
None
-
False
-
Not Selected
-
-
- Proposed title of this feature request
2. What is the nature and description of the request?
3. Why does the customer need this? (List the business requirements here)
4. List any affected packages or components.
Current behavior:
for v2, and especially for those using it in automation pipelines, it was decided that failure in mirroring images leads to exit code non zero for release images only. But for operators, helm related images and additional images, the process returns in success, but errors are available in the console output and in a specific log file.
Customer perspective:
If you need to differentiate between types of errors, e.g. errors in release vs operators, can you return say “2” for operators and “1" for release images? Having to search in log files for success vs failure is error-prone and cumbersome IMHO.
The logic i need is a bulletproof way to know if all images have succeeded or not. If I search logs how can I do that with 100% certainty?
Is this the specific log file? “workspace/working-dir/logs/mirroring_errors_20250109_171922.txt”?
It would be more Linux/UNIX conformant if you return non-zero on ANY error and then let those who need to know more look at log files (or look at the non-zero value, e.g. 1 for release errors, 2 for operator errors, 3 for helm errors etc) (edited)
If there are multiple errors, e.g. for both release and operator images you would return error 1 (i.e. release image errors have prioritiy over operator image errors. The same for other images and helm related. )
Release errors = 1
Operator errors = 2
Other errors = 3
Helm related errors = 4
You would always return the lowest number or i.e. the most relevant/significant error.
- is related to
-
OCPBUGS-49880 v2: oc-mirror reports success exit (0) even in case of errors
-
- ASSIGNED
-