add OSS build for windows and linux based on latest Robot Framework core version

[test-fullautomation]

In addition to our releases with extended Robot Framework core we need a windows- and linux OSS release which is based on the latest released unchanged Robot Framework core.

Latest version is currently https://github.com/robotframework/robotframework/blob/master/doc/releasenotes/rf-7.1.1.rst

[ngoan1608]

Hi @test-fullautomation , Cc @namsonx , @milanac030988 , @HolQue

I define the versions for our release packages as below:

• basic version: build with latest release of robotframework core (currently 7.1.1)
• custom version: build with our extended robotframework (include UNKNOWN, THREAD, return code, and USER log features) => Please give your idea(s) about these version names.

Besides, while testing basic version, I observed that our testsuitemanagement library does not work properly because it uses UNKNOWN feature (which is only available in our version of robotframework) inside the implementation.

So, do you have any proposal for this case? Do we remove testsuitemanagement from the basic package or we adapt the testsuitemanagement library to work properly without UNKNOWN feature?

Referent build pipeline: https://github.com/test-fullautomation/RobotFramework_AIO/actions/runs/11623248868

Thank you, Ngoan

[ngoan1608]

Hi Thomas,

We have discussed from my side, the small change from testsuitemanagement will make it work properly with robotframework core.

However, the UNKNOWN related test cases (in TSM) should be skipped (update) for the selftest for the basic version.

Thank you, Ngoan

[HolQue]

Oh no, this is really not nice. Then the self test needs something like a bundle handling (similar to the variant handling):

./component_test.py --bundle="basic|custom"

Effort!

And what does this mean? There are a lot of BADCASE test cases available. With result is UNKNOWN. This term is part of a lot of reference log files and also part of the self test code (e.g. a counter for UNKNOWN tests). We would need a separate bunch of reference log files for every bundle and we would need adaptions in the code.

Much more effort.

Or we skip these test cases. But this also means that we remove important parts of the self test.

Do the results really justify the required effort?

[test-fullautomation]

Hi @ngoan1608 , @namsonx , @HolQue , yes, we need basic and custom. yes, testsuites-management must run with a standard RobotFramework core. yes, all meaningful parts of the testsuites-management SelfTest need to executed with basic version, too. This all is relevant for 0.13.2. Thank you, Thomas

[HolQue]

Hi Thomas,

current situation: a single testsuites-management repository containing the self test. The self test I have to made configurable. OK so far. But how about the testsuites-management itself? Will this component also be made configurable or do we need a separate repository for that (with an own subfolder containing a self test)?

How about tutorial and testsuites-management documentation? At least they need to be reviewed - to see if there is also content that need to be separated.

[test-fullautomation]

Hi @HolQue , testsuites-management should recognize environment (custom / basic) and adapt automatically to it. Same for tutorial and documentation. Thank you, Thomas

[HolQue]

How shall this bundle recognition work?

Or. Will this be a recognition, or a command line parameter? And how to configure this?

What shall be mentioned and what shall not be mentioned in documentation, and what shall be explained in which way depending on which bundle? Currently I cannot believe that this can work in documentation and tutorial. Either an explosion of if-else-conditions or self test, docu and tutorial divided into two different versions.

[test-fullautomation]

Ideally there should be an automatic recognition.

Documentation shall describe first behaviour with basic core. Then extra behaviour in case of custom core or RobotFramework AIO project.

[ngoan1608]

Conclusion from team meeting:

• create ticket on TSM to update implementation and test due unknown and return value
• use terms original and extended instead of basic and custom
• separated Document and Release info for original and extended versions
• same pipeline for BIOS