HubController tests and new APIs to list organizations and channels on the peripheral server

[CDellaGiusta]

What does this PR change?

The aim is to test a HubController API call without actually setting up a remote server and using tools like postman.
The idea is that unit tests can be done to test the behaviour and the returned values, while a single manual test can be done from the external (e.g. postman) to check that the API endpoint is really visible.

I tested all the old API endpoints with this testing method.

Also, I added two API endpoints to list all organizations and all the channels in the peripheral server.

GUI diff

No difference.

• DONE

Documentation

• No documentation needed: only internal and user invisible changes
• DONE

Test coverage

• Unit tests were added
• DONE

Links

Issue(s): https://github.com/SUSE/spacewalk/issues/25353
Port(s):

• DONE

Changelogs

If you don't need a changelog check, please mark this checkbox:

• No changelog needed

Re-run a test

• Re-run test "changelog_test"
• Re-run test "backend_unittests_pgsql"
• Re-run test "java_pgsql_tests"
• Re-run test "schema_migration_test_pgsql"
• Re-run test "susemanager_unittests"
• Re-run test "javascript_lint"
• Re-run test "spacecmd_unittests"

[github-actions]

👋 Hello! Thanks for contributing to our project.
Acceptance tests will take some time (aprox. 1h), please be patient ☕
You can see the progress at the end of this page and at https://github.com/uyuni-project/uyuni/pull/9720/checks
Once tests finish, if they fail, you can check 👀 the cucumber report. See the link at the output of the action.
You can also check the artifacts section, which contains the logs at https://github.com/uyuni-project/uyuni/pull/9720/checks.

If you are unsure the failing tests are related to your code, you can check the "reference jobs". These are jobs that run on a scheduled time with code from master. If they fail for the same reason as your build, it means the tests or the infrastructure are broken. If they do not fail, but yours do, it means it is related to your code.

Reference tests:

• https://github.com/uyuni-project/uyuni/actions/workflows/acceptance_tests_secondary_parallel.yml?query=event%3Aschedule

• https://github.com/uyuni-project/uyuni/actions/workflows/acceptance_tests_secondary.yml?query=event%3Aschedule

KNOWN ISSUES

Sometimes the build can fail when pulling new jar files from download.opensuse.org . This is a known limitation. Given this happens rarely, when it does, all you need to do is rerun the test. Sorry for the inconvenience.

For more tips on troubleshooting, see the troubleshooting guide.

Happy hacking!
⚠️ You should not merge if acceptance tests fail to pass. ⚠️

[github-actions]

Suggested tests to cover this Pull Request

• min_deblike_ssh
• min_salt_minions_page
• min_bootstrap_api
• srv_sync_fake_channels
• min_retracted_patches
• minssh_move_from_and_to_proxy
• min_salt_lock_packages
• min_recurring_action
• srv_content_lifecycle
• srv_power_management_api
• min_salt_software_states
• srv_delete_channel_with_tool
• min_action_chain
• allcli_system_group
• min_salt_minion_details
• min_change_software_channel
• srv_clone_channel_npn
• min_deblike_salt_install_package
• srv_power_management
• srv_dist_channel_mapping
• srv_create_dev_channels
• srv_cobbler_distro
• minssh_tunnel
• min_salt_user_states
• srv_power_management_redfish
• srv_create_activationkey
• srv_manage_channels_page
• sle_minion
• buildhost_bootstrap
• srv_enable_sync_products
• min_rhlike_monitoring
• allcli_action_chain
• srv_check_channels_page
• min_salt_pkgset_beacon
• srv_sync_dev_channels
• buildhost_docker_build_image
• buildhost_osimage_build_image
• min_rhlike_ssh
• srv_patches_page
• min_bootstrap_reactivation
• proxy_container_retail_mass_import
• min_rhlike_salt
• proxy_container
• min_custom_pkg_download_endpoint
• srv_sync_channels
• allcli_software_channels_dependencies
• min_deblike_openscap_audit
• allcli_software_channels
• min_move_from_and_to_proxy
• allcli_config_channel
• srv_cobbler_profile
• min_rhlike_openscap_audit
• min_cve_id_new_syntax
• srv_create_fake_repositories
• min_deblike_salt
• min_monitoring
• min_activationkey
• srv_manage_activationkey
• minssh_ansible_control_node
• min_salt_openscap_audit
• srv_handle_software_channels_with_ISS_v2
• srv_create_fake_channels
• min_salt_formulas
• srv_salt_download_endpoint
• allcli_reboot
• min_deblike_salt_install_with_staging
• srv_maintenance_windows
• srv_first_settings
• allcli_update_activationkeys
• srv_channel_api
• min_salt_install_package
• minssh_action_chain
• proxy_container_retail_pxeboot
• srv_push_package
• min_salt_formulas_advanced
• minssh_salt_install_package
• min_config_state_channel_api
• min_ansible_control_node
• allcli_overview_systems_details
• srv_sync_products
• min_rhlike_salt_install_package_and_patch
• min_deblike_monitoring
• srv_check_sync_source_packages
• proxy_traditional_retail_pxeboot
• srv_user_configuration_salt_states
• allcli_sanity
• minssh_bootstrap_api
• srv_menu
• srv_delete_channel_from_ui
• min_salt_install_with_staging
• min_cve_audit
• min_check_patches_install
• proxy_container_branch_network
• min_salt_mgrcompat_state
• srv_menu_filter
• proxy_container_cobbler_pxeboot

[mackdk]

Discussion point here: this conversion (and the similar one happening in collectAllChannelsInfo()) seems like something that should happen in the controller, rather than in the manager.

It depends in fact on the format we want to return to the API caller, rather than on the data we want to extract. If we just return a list of Orgs, the code using the manager will be able to adapt the data as it needs and this method will be easier to reuse in other context.

[CDellaGiusta]

In these two cases your point is valid, since the returned value to the api caller is a direct mapping of Org and Channel objects.
I tried to mime the case of collectManagerInfo, which is a different case: the ManagerInfo structure has to be directly filled by the HubManager, since it is collecting and merging data here and there.

[wweellddeerr]

Although other methods in this and other manager classes already perform similar conversions, I agree that the best place for this conversion is in the controller.

[CDellaGiusta]

Agree. Fixed. Please have a look.