Skip to content
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

Use manifester from fixture #14377

Closed

Conversation

dosas
Copy link
Collaborator

@dosas dosas commented Mar 12, 2024

Problem Statement

There were two tests that were not using manifester from fixture

Solution

see PR

@dosas dosas requested a review from a team as a code owner March 12, 2024 15:15
@ogajduse ogajduse requested a review from synkd March 12, 2024 16:02
Copy link
Contributor

@synkd synkd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should check with the authors of these tests, but I believe it was by design that they did not use Manifester via fixtures in these cases. function_entitlement_manifest returns a Request object, not a Manifester object, so the Manifester instance methods are not available to it or the other Manifester fixtures. If a test requires Manifester instance methods, it's currently necessary to instantiate Manifester locally in order to access those methods.

@omkarkhatavkar @ColeHiggins2 can you confirm that these tests are intentionally instantiating Manifester objects?

@dosas
Copy link
Collaborator Author

dosas commented Mar 14, 2024

@synkd It makes sense to ask the original authors.

But this function https://github.com/SatelliteQE/robottelo/blob/master/pytest_fixtures/component/taxonomy.py#L226 IMHO returns an Instance of Manifester

@vsedmik
Copy link
Contributor

vsedmik commented Mar 14, 2024

Apart from the question above, in master (targets Satellite 6.16) we need to replace *_entitlement_manifest by *_sca_manifest, since 6.16 will be SCA-only so we are going to refactor these tests anyway.

In other words, this PR needs to be raised against 6.15.z if we want to use the proposed changes.

@dosas
Copy link
Collaborator Author

dosas commented Mar 14, 2024

#14405

@dosas dosas closed this Mar 14, 2024
@dosas dosas reopened this Mar 14, 2024
@dosas
Copy link
Collaborator Author

dosas commented Mar 14, 2024

@vsedmik Isn't that an argument for this PR to go into master? Now you would have to change the manifester in 3 places. After this fix the change would only be in one place.

@vsedmik
Copy link
Contributor

vsedmik commented Mar 14, 2024

@vsedmik Isn't that an argument for this PR to go into master? Now you would have to change the manifester in 3 places. After this fix the change would only be in one place.

@dosas My thought was it needs to be resolved in master differently anyway in a separate PR. Your changes appeared to me reasonable, but for 6.15.z and older branches.

@dosas
Copy link
Collaborator Author

dosas commented Mar 14, 2024

Alright, I created and linked the PR for 6.15.z. Feel free to close/merge the PR you see fit.

@dosas dosas closed this Mar 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants