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

Fixes #37998 - deb-repos not shown on host repo-set #11212

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

m-bucher
Copy link
Contributor

@m-bucher m-bucher commented Nov 8, 2024

What are the changes introduced in this pull request?

Host did not show any debian repositories on Content->RepositorySet tab.
Error-toast is shown.

Todo:

  • test coverage

Considerations taken when implementing this change?

We have to make sure that we do not show duplicate repo-entries in case structured-apt feature is enabled.
That is the reason to also check the environment.

What are the testing steps for this pull request?

  1. create ActivationKey with deb-repositories
  2. register a (deb-)host
  3. go to RepositorySet on new HostDetails' Content-tab
  4. deb-repos are displayed

@@ -16,6 +16,7 @@ def initialize(params = {})
def product_content
if match_environment
versions = consumable.content_view_environments.select(:content_view_version_id).map(&:content_view_version_id)
environment = consumable.respond_to?(:environment) ? consumable.environment : consumable.content_view_environments.select(:environment_id).map(&:environment_id)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am afraid this looks a little bit hacky. I would rather implement environment() on SubscriptionFacet as well so we do not have to differentiate, here.

Problem there is that I am unsure on if we can determine a single value for environment for SubscriptionFacet as it gets content_version_environments through ContentFacet, which is a has_many relation.

Copy link
Contributor

Choose a reason for hiding this comment

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

What about putting that in a condition to only evaluate if structured apt is enabled? The risk of breaking something for other OSes would be lower.

Copy link
Contributor

@nadjaheitmann nadjaheitmann Nov 11, 2024

Choose a reason for hiding this comment

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

You could even move the line to line 29 such that it will only be in the structured apt block.

The code itself works fine for content views and also the Default Organization view.

Copy link
Contributor

Choose a reason for hiding this comment

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

Even if we move it into the structured APT block, we still need to consider the case where some of the content uses structured APT, and some of it does not. In that case we enter the block, which should then not influence how the non structured APT content is handled.

Copy link
Contributor

Choose a reason for hiding this comment

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

This is exactly the reason to move the code into the structured apt block. If we have the structured apt code in one block, that will significantly simplify testing because the rest of the code is not affected.

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.

4 participants