third party repos in gnome-initial-setup are not covered by tests #506

Closed
opened 2026-03-20 10:17:35 +00:00 by kparal · 9 comments
Owner

This bug appeared in Fedora 44 cycle:

gnome-initial-setup does not enable third party repos
https://bugzilla.redhat.com/show_bug.cgi?id=2446745

It is likely a blocker due to this criterion:

If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test.

https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria#First_boot_experience

It seems we haven't caught it in our OpenQA test suite. Can we please cover this functionality?
(And if there are other parts of gnome-initial-setup, where basic functionality of individual panels is not tested, let's cover those as well).

Thanks!

This bug appeared in Fedora 44 cycle: **gnome-initial-setup does not enable third party repos** https://bugzilla.redhat.com/show_bug.cgi?id=2446745 It is likely a blocker due to this criterion: > If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and **each page or panel of the initial setup utility should withstand a basic functionality test**. https://fedoraproject.org/wiki/Fedora_44_Final_Release_Criteria#First_boot_experience It seems we haven't caught it in our OpenQA test suite. Can we please cover this functionality? (And if there are other parts of gnome-initial-setup, where basic functionality of individual panels is not tested, let's cover those as well). Thanks!
Owner

It seems we haven't caught it in our OpenQA test suite. Can we please cover this functionality?

Sure, we could. (There might be an issue for that already, though).

(And if there are other parts of gnome-initial-setup, where basic functionality of individual panels is not tested, let's cover those as well).

This gets a bit tricky because one thing it can do is set up 'enterprise accounts', i.e. FreeIPA and AD, so we have to add yet another client test to those sets. It's doable, it's just a bit of work.

> It seems we haven't caught it in our OpenQA test suite. Can we please cover this functionality? Sure, we could. (There might be an issue for that already, though). > (And if there are other parts of gnome-initial-setup, where basic functionality of individual panels is not tested, let's cover those as well). This gets a bit tricky because one thing it can do is set up 'enterprise accounts', i.e. FreeIPA and AD, so we have to add yet another client test to those sets. It's doable, it's just a bit of work.
Author
Owner

Enterprise login seems to be requested in #290 , so we can keep this ticket to just third-party repos. In my eyes, this one is more important, because it's likely used by many more users.

Enterprise login seems to be requested in #290 , so we can keep this ticket to just third-party repos. In my eyes, this one is more important, because it's likely used by many more users.
Owner

I would like to know more. Currently, we use the gnome_initial_setup function in lib/utils.pm which is rather complex and able to handle all possible variants of the initial setup. How the initial setup is presented and which screens it has on each deliverable is not too straightforward and is affected by various things.

The current situation of testing coverage looks like this:

  1. Language screen:

    • Checks if correct language selected
    • Can search and select different language (inactive code path)
    • Handles "Start Setup" vs "Next" button
  2. Timezone screen:

    • Detects geolocation failure
    • Manual city search (washington-d or berlin)
    • Version-specific handling (GNOME 49+)
  3. Keyboard screen:

    • No actual testing of keyboard layout
  4. Privacy screen:

    • Just clicks "Next"
    • No testing of location services
    • No testing of reporting options
  5. Software screen:

    • Just clicks "Next"
    • No testing of third-party repos
  6. User creation (when user not created in advance):

    • Creates user with username/password
    • Validates keyboard layout worked (if LANGUAGE set)

How deep should basic functionality go?

  • Point 3 - is it enough to check later in the installed system, that a correct locales are set? Or should we click a new keyboard layout and then test it?
  • Point 4 - is it ok to confirm those things and check in the installed system?
  • Point 5 - is it ok to click on the button and check in the installed system?
I would like to know more. Currently, we use the `gnome_initial_setup` function in `lib/utils.pm` which is rather complex and able to handle all possible variants of the initial setup. How the initial setup is presented and which screens it has on each deliverable is not too straightforward and is affected by various things. The current situation of testing coverage looks like this: 1. Language screen: - Checks if correct language selected - Can search and select different language (inactive code path) - Handles "Start Setup" vs "Next" button 2. Timezone screen: - Detects geolocation failure - Manual city search (washington-d or berlin) - Version-specific handling (GNOME 49+) 3. Keyboard screen: - No actual testing of keyboard layout 4. Privacy screen: - Just clicks "Next" - No testing of location services - No testing of reporting options 5. Software screen: - Just clicks "Next" - No testing of third-party repos 6. User creation (when user not created in advance): - Creates user with username/password - Validates keyboard layout worked (if LANGUAGE set) How deep should _basic functionality_ go? - Point 3 - is it enough to check later in the installed system, that a correct locales are set? Or should we click a new keyboard layout and then test it? - Point 4 - is it ok to confirm those things and check in the installed system? - Point 5 - is it ok to click on the button and check in the installed system?
Author
Owner

I think it would be useful if general automated tests used "default values" for a standard installation testing, but there would be an extra test that would try non-default values. So for example, it could try selecting a different language, a different keyboard layout, configuring privacy values to non-defaults and enabling third-party repos. Then it would test if all those settings were applied correctly. (Maybe it's good to do VM snapshotting here, so that each of those changes can be tested individually, and one failure doesn't break running all the other tests).

I think it would be useful if general automated tests used "default values" for a standard installation testing, but there would be an extra test that would try non-default values. So for example, it could try selecting a different language, a different keyboard layout, configuring privacy values to non-defaults and enabling third-party repos. Then it would test if all those settings were applied correctly. (Maybe it's good to do VM snapshotting here, so that each of those changes can be tested individually, and one failure doesn't break running all the other tests).
Owner

We already test language and keyboard layout to some degree in the non-English install tests on Workstation live. But on the whole that's probably a reasonable approach. It would have to be a standalone test, though, I think, because install_default_upload uploads after it's run through gnome-initial-setup.

We already test language and keyboard layout to some degree in the non-English install tests on Workstation live. But on the whole that's probably a reasonable approach. It would have to be a standalone test, though, I think, because `install_default_upload` uploads *after* it's run through gnome-initial-setup.
Owner

Ok, I agree. The standalone test will provide better freedom of doing things and better safety not to break existing code. I'll be on it.

Ok, I agree. The standalone test will provide better freedom of doing things and better safety not to break existing code. I'll be on it.
lruzicka added this to the Sprint 6 project 2026-03-24 08:50:42 +00:00
Owner

remember to reuse needles, though.

remember to reuse *needles*, though.
adamwill modified the project from Sprint 6 to Sprint 7 2026-04-07 15:13:29 +00:00
adamwill modified the project from Sprint 7 to Sprint 8 2026-04-21 15:13:10 +00:00
adamwill modified the project from Sprint 8 to Sprint 9 2026-05-05 15:22:27 +00:00
Owner

This is currently blocked waiting for Silverblue team to decide about https://github.com/fedora-silverblue/issue-tracker/issues/700 ; we don't want to merge the PR till we're sure whether they want to keep the divergence with Workstation behavior or not.

This is currently blocked waiting for Silverblue team to decide about https://github.com/fedora-silverblue/issue-tracker/issues/700 ; we don't want to merge the PR till we're sure whether they want to keep the divergence with Workstation behavior or not.
Owner

Upstream issue now says "We're still setting up all the CI for the new Atomic Desktops config repos so we'll slow down merges for a short while. So if you can keep the state as is for Silverblue that should be good and I'll open a discussion in the Workstation tracker about this" so I guess we can call this unblocked. It should probably be mergeable as is, maybe with a note somewhere about the situation.

Upstream issue now says "We're still setting up all the CI for the new Atomic Desktops config repos so we'll slow down merges for a short while. So if you can keep the state as is for Silverblue that should be good and I'll open a discussion in the Workstation tracker about this" so I guess we can call this unblocked. It should probably be mergeable as is, maybe with a note somewhere about the situation.
adamwill 2026-05-11 23:55:09 +00:00
Sign in to join this conversation.
No milestone
No project
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
quality/os-autoinst-distri-fedora#506
No description provided.