QA » openQA Project

Hello,
Let me clearly it a bit more.

I have a test data, a hash which have some scc code for internal test:

$ltss= {
sles15sp1 => "ltss code1",
sles15 => "ltss code2",
sles12sp4 => "ltss code3"
...
}

I don't know where to define/place it because the places which are supposed to store test data in source tree: test module, the files in factory/other/, data/, schedule/ are all public in github.

So, my request is that OpenQA infrastructure should provide someplace for us to store private test data. It should be easy to retrieve in test run.

By the way, gitlab.nue.suse.com isn't working. Maybe, you mean gitlab.suse.de? I know the job groups schedule and settings are stored in gitlab.suse.de. However, they do not support data structure, like hash.

tonyyuan wrote:

I don't know where to define/place it because the places which are supposed to store test data in source tree: test module, the files in factory/other/, data/, schedule/ are all public in github.

Well, https://github.com/os-autoinst/os-autoinst-distri-opensuse/tree/master/data and https://github.com/os-autoinst/os-autoinst-distri-opensuse/tree/master/schedule are public, correct. But what do you mean with "factory/other/" being on github? It's merely a simple local directory on OSD which is filled from assets copied there. Which means that you can also copy data there which can be made available as assets and then provided as tests to be read there. So you could put your hash as perl code in a file, put it into these other assets, register in tests as assets and access from tests.

Another alternative might be to checkout a git submodule from an internal git repo into a subfolder of the checkout folder of os-autoinst-distri-opensuse. The management of that git checkout folder should be done in https://gitlab.suse.de/openqa/salt-states-openqa where you can create a merge request.

By the way, gitlab.nue.suse.com isn't working. Maybe, you mean gitlab.suse.de?

Well, I did mean gitlab.nue.suse.com but that points to gitlab.suse.de . So using either is fine although in a properly configured network both domains nue.suse.com as well as suse.de should work

I know the job groups schedule and settings are stored in gitlab.suse.de. However, they do not support data structure, like hash.

Well, I don't know if anybody has used test settings in this way but I am pretty sure that for example a properly escaped YAML document in a test setting could be defined and read from test code. The low-tech alternative of course would be to define the hash values as individual job settings, e.g. following your above example

• SCC_REGCODE_LTSS_SLES15SP1="ltss code1"
• SCC_REGCODE_LTSS_SLES15="ltss code2"

The simplest workaround I have thought of is to create one single VAR, like:
LTSS_PRODUCTS_CODES="15.1,INTERNAL-USE-xxxxxx,15,INTERNAL-USE-ONLY-yyyyyyy,12.4,INTERNAL-USE-ONLY-cccccc,12.3,INTERNAL-USE-ONLY-dddddd".

This VAR can be placed in testsuite definitions or jobgroup template settings which are not public.

Then ,convert it to hash in the test code:
my %ltss_products_codes = @{get_var_array("LTSS_PRODUCTS_CODES")};

The hash key is product version and value is the ltss code.

However, the value of LTSS_PRODUCTS_CODES is quite lengthy string. It looks wired and ugly. That is why I am asking: maybe openQA should provide a better way for us to keep private data.

However, the value of LTSS_PRODUCTS_CODES is quite lengthy string. It looks wired and ugly. That is why I am asking: maybe openQA should provide a better way for us to keep private data.

have you read my comment in https://progress.opensuse.org/issues/98664#note-5 regarding putting assets in the "other/" directory?

okurz wrote:

However, the value of LTSS_PRODUCTS_CODES is quite lengthy string. It looks wired and ugly. That is why I am asking: maybe openQA should provide a better way for us to keep private data.

have you read my comment in https://progress.opensuse.org/issues/98664#note-5 regarding putting assets in the "other/" directory?

Yes, I have.
A question: Is there a way to handle the file in worker pool directory? You know, it might not make sense to handle file with data like ltss code in SUT. I mean that downloading it into SUT, then retrieving it via "script_output" does not look good.

Yes. Files in the pool directory can be directly opened by standard perl code. The pool directory is the "current directory" so just opening by filename should work