Fix switch to console in welcome and addon_dud schedule

[jknphy]

After #7380 we are switching to console in a few scenarios in welcome module during installation before accepting the license and the combination of keys ctrl-alt-shift-x does not work when the focus is on a select box: https://openqa.suse.de/tests/2882740#step/welcome/5 producing strange effect that the following commands that are written in the terminal makes a search in the select box (Galician is selected when grep is typed).
Also related with the change in workflow after #7380, we need to schedule addon_dud after license acceptance.

• Related ticket: https://progress.opensuse.org/issues/50666
• Needles: N/A
• Verification run:
  • sle-12-SP5-MINI-ISO-gnome_http
  • sle-12-SP5-dud_sdk

[b10n1k]

@jknphy i cant see the changes on welcome in the VR links which you provide

[jknphy]

@jknphy i cant see the changes on welcome in the VR links which you provide

Both links appears accessible to me. fqdn is provided ending in suse.cz. Perhaps your dns configuration?

[b10n1k]

they links are accesible. the welcome module is not containing the PR;s changes. So i assume the VRs run with old welcome module or something

[jknphy]

they links are accesible. the welcome module is not containing the PR;s changes. So i assume the VRs run with old welcome module or something

on openQA Web UI you cannot trust on the module code, as it depends on the current git branch you are.

[b10n1k]

they links are accesible. the welcome module is not containing the PR;s changes. So i assume the VRs run with old welcome module or something

on openQA Web UI you cannot trust on the module code, as it depends on the current git branch you are.

yup that s what i am saying. if you are not running the VR from the working branch how do you verify that the VR is correct?

[jknphy]

they links are accesible. the welcome module is not containing the PR;s changes. So i assume the VRs run with old welcome module or something

on openQA Web UI you cannot trust on the module code, as it depends on the current git branch you are.

yup that s what i am saying. if you are not running the VR from the working branch how do you verify that the VR is correct?

I'm running the VR from the working branch, one way to know is to check the logs:
[2019-05-10T14:45:47.0826 CEST] [debug] <<< testapi::send_key(key='alt-y', do_wait=0)

[2019-05-10T15:07:15.0491 CEST] [debug] scheduling accept_license tests/installation/accept_license.pm
[2019-05-10T15:07:15.0492 CEST] [debug] scheduling dud_addon tests/installation/dud_addon.pm

The other way is to check in var.json: TEST_GIT_HASH:
This is my branch related with my PR: https://github.com/jknphy/os-autoinst-distri-opensuse/commits/fix_switch_to_console_welcome and you can find 49b8ef8 related to one commit and 9827b7e related to the other one. In fact that was not true, I checked and was pointing to a previous commit to my work 97c6a65, so I restarted the job again http://rivera-workstation.suse.cz/tests/2696 and now it is fixed to that commit.
What I realized is that even if you trigger the job with your working branch, var.json is written at the end when the job finishes, so if I have a different branch when the job is uploading assets then TEST_GIT_HASH may not be reliable, So I guess when reviewing PRs, we might want to check first this setting and if doesn't match go the logs or go to the logs straightforward to see if the changes are meaningful and corresponds with the PR. I hope it is more clear now

[jknphy]

Ok, let's give it a try and address this specific issues.