-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a few exceptions class for yum transaction handler #674
Add a few exceptions class for yum transaction handler #674
Conversation
We discovered that we were missing a few exception classes to catch during the package download. We went ahead and added a couple of exceptions to catch gpg checks and mirror exceptions too. Signed-off-by: Rodolfo Olivieri <[email protected]>
Codecov ReportBase: 93.47% // Head: 93.47% // No change to project coverage 👍
Additional details and impacted files@@ Coverage Diff @@
## main #674 +/- ##
=======================================
Coverage 93.47% 93.47%
=======================================
Files 22 22
Lines 3188 3188
Branches 568 568
=======================================
Hits 2980 2980
Misses 146 146
Partials 62 62
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Signed-off-by: Rodolfo Olivieri <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Lets wait for integration tests
While testing convert2rhel manually in a vagrant box, I realized that the conversion stopped in the yum transaction validation phase, generating a traceback and not doing a proper rollback after the error appeared. Since the transaction validation is supposed to trigger the rollback in case of any failures, it was strange that the tool was not behaving the way it should. As part of oamg#674 that introduced the fix, we left out the integration tests that were supposed to cover this scenario. Signed-off-by: Rodolfo Olivieri <[email protected]>
While testing convert2rhel manually in a vagrant box, I realized that the conversion stopped in the yum transaction validation phase, generating a traceback and not doing a proper rollback after the error appeared. Since the transaction validation is supposed to trigger the rollback in case of any failures, it was strange that the tool was not behaving the way it should. As part of oamg#674 that introduced the fix, we left out the integration tests that were supposed to cover this scenario. Signed-off-by: Rodolfo Olivieri <[email protected]>
While testing convert2rhel manually in a vagrant box, I realized that the conversion stopped in the yum transaction validation phase, generating a traceback and not doing a proper rollback after the error appeared. Since the transaction validation is supposed to trigger the rollback in case of any failures, it was strange that the tool was not behaving the way it should. As part of oamg#674 that introduced the fix, we left out the integration tests that were supposed to cover this scenario. Signed-off-by: Rodolfo Olivieri <[email protected]>
While testing convert2rhel manually in a vagrant box, I realized that the conversion stopped in the yum transaction validation phase, generating a traceback and not doing a proper rollback after the error appeared. Since the transaction validation is supposed to trigger the rollback in case of any failures, it was strange that the tool was not behaving the way it should. As part of oamg#674 that introduced the fix, we left out the integration tests that were supposed to cover this scenario. Signed-off-by: Rodolfo Olivieri <[email protected]>
While testing convert2rhel manually in a vagrant box, I realized that the conversion stopped in the yum transaction validation phase, generating a traceback and not doing a proper rollback after the error appeared. Since the transaction validation is supposed to trigger the rollback in case of any failures, it was strange that the tool was not behaving the way it should. As part of oamg#674 that introduced the fix, we left out the integration tests that were supposed to cover this scenario. Signed-off-by: Rodolfo Olivieri <[email protected]>
While testing convert2rhel manually in a vagrant box, I realized that the conversion stopped in the yum transaction validation phase, generating a traceback and not doing a proper rollback after the error appeared. Since the transaction validation is supposed to trigger the rollback in case of any failures, it was strange that the tool was not behaving the way it should. As part of oamg#674 that introduced the fix, we left out the integration tests that were supposed to cover this scenario. Signed-off-by: Rodolfo Olivieri <[email protected]>
While testing convert2rhel manually in a vagrant box, I realized that the conversion stopped in the yum transaction validation phase, generating a traceback and not doing a proper rollback after the error appeared. Since the transaction validation is supposed to trigger the rollback in case of any failures, it was strange that the tool was not behaving the way it should. As part of oamg#674 that introduced the fix, we left out the integration tests that were supposed to cover this scenario. Signed-off-by: Rodolfo Olivieri <[email protected]>
While testing convert2rhel manually in a vagrant box, I realized that the conversion stopped in the yum transaction validation phase, generating a traceback and not doing a proper rollback after the error appeared. Since the transaction validation is supposed to trigger the rollback in case of any failures, it was strange that the tool was not behaving the way it should. As part of oamg#674 that introduced the fix, we left out the integration tests that were supposed to cover this scenario. Signed-off-by: Rodolfo Olivieri <[email protected]>
While testing convert2rhel manually in a vagrant box, I realized that the conversion stopped in the yum transaction validation phase, generating a traceback and not doing a proper rollback after the error appeared. Since the transaction validation is supposed to trigger the rollback in case of any failures, it was strange that the tool was not behaving the way it should. As part of oamg#674 that introduced the fix, we left out the integration tests that were supposed to cover this scenario. Signed-off-by: Rodolfo Olivieri <[email protected]>
While testing convert2rhel manually in a vagrant box, I realized that the conversion stopped in the yum transaction validation phase, generating a traceback and not doing a proper rollback after the error appeared. Since the transaction validation is supposed to trigger the rollback in case of any failures, it was strange that the tool was not behaving the way it should. As part of oamg#674 that introduced the fix, we left out the integration tests that were supposed to cover this scenario. Signed-off-by: Rodolfo Olivieri <[email protected]>
…677) * Add missing integration tests for single yum transaction While testing convert2rhel manually in a vagrant box, we've bumped into a traceback when the conversion stopped in the yum transaction validation phase and no rollback happened. Since the transaction validation is supposed to trigger the rollback in case of any failures, it was strange that the tool was not behaving the way it should. As part of #674 that introduced a fix for that, we left out the integration test that was supposed to cover this scenario. Signed-off-by: Rodolfo Olivieri <[email protected]> Co-authored-by: Michal Bocek <[email protected]> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
…677) * Add missing integration tests for single yum transaction While testing convert2rhel manually in a vagrant box, we've bumped into a traceback when the conversion stopped in the yum transaction validation phase and no rollback happened. Since the transaction validation is supposed to trigger the rollback in case of any failures, it was strange that the tool was not behaving the way it should. As part of #674 that introduced a fix for that, we left out the integration test that was supposed to cover this scenario. Signed-off-by: Rodolfo Olivieri <[email protected]> Co-authored-by: Michal Bocek <[email protected]> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
We discovered that we were missing a few exception classes to catch during the package download. We went ahead and added a couple of exceptions to catch gpg checks and mirror exceptions too.
Signed-off-by: Rodolfo Olivieri [email protected]
Jira Issue: RHELC-
Checklist
[RHELC-]
is part of the PR titleRelease Pending