Bug 1146918 - Strings in rlPhaseStartTest are crippled when contain special characters
Summary: Strings in rlPhaseStartTest are crippled when contain special characters
Keywords:
Status: CLOSED DUPLICATE of bug 1159191
Alias: None
Product: Beaker
Classification: Retired
Component: beah
Version: 0.18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-26 11:06 UTC by Aleš Mareček
Modified: 2018-02-06 00:41 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-20 07:41:20 UTC
Embargoed:


Attachments (Terms of Use)

Description Aleš Mareček 2014-09-26 11:06:05 UTC
Description of problem:
rlPhaseStartTest is crippled / truncated when contain spcial characters like : or +.
See the test run: https://beaker.engineering.redhat.com/recipes/1586920#task24759347 where are same phases like
 	CODE-check 
 	CODE-check 

When you look at the test you realize that phase names are actually different:
[alich@mordor simple-tls11-test]$ grep rlPhaseStartTest runtest.sh 
    rlPhaseStartTest "CODE check + TESTSUITE check"
    rlPhaseStartTest "CODE check: MD5 ciphers"
    rlPhaseStartTest "CODE check: NSS_NO_PKCS11_BYPASS constant"
    rlPhaseStartTest "Protocols tests"
    rlPhaseStartTest "TLS1.1 cipher test: same ciphers on server and client"
    rlPhaseStartTest "TLS1.1 cipher test: server cipher use: all except the 'TLS11_RSA_WITH_AES_256_CBC_SHA', client cipher use: only 'TLS11_RSA_WITH_AES_256_CBC_SHA'"
    rlPhaseStartTest "TLS1.1 cipher test: server cipher: 'TLS11_RSA_WITH_AES_256_CBC_SHA', client ciphers all except 'TLS11_RSA_WITH_AES_256_CBC_SHA'"
    rlPhaseStartTest "LOG SECTION - no test here, just logs"

1. STRING1: STRING2 is truncated to STRING1
2. STRING1 + STRING2 is converted to STRING1-STRING2
3. some others?


Version-Release number of selected component (if applicable):
Beaker 0.18.1

How reproducible:
Always

Steps to Reproduce:
1. Schedule test /CoreOS/nss/Sanity/simple-tls11-test

Actual results:
crippled rlPhaseStartTest

Expected results:
same strings that test contains

Additional info:
I'm not sure what exact part of Beaker causes the problem that's why I'm reporting it to "test harness"

Comment 1 Dan Callaghan 2014-09-28 23:38:51 UTC
The rl* bash functions you are using in your task are provided by the beakerlib shell library.

https://fedorahosted.org/beakerlib/

I have a feeling that the phase name munging you are describing is a feature, not a bug, but I'll let the beakerlib developers comment further.

Comment 2 Dalibor Pospíšil 2014-10-07 13:39:00 UTC
I am afraid that the root cause is on beaker side. If you look into to the journal.xml the phase names are ok. The issue is just how the phase name is presented out.

Let beaker devels put their two cents in.

Comment 3 Marian Csontos 2014-10-10 12:38:42 UTC
This is legacy rhts thing which is doing name mangling: the result names are converted to "safe-for-filesystem" names and these are used to store results on the host's FS. IMO the best is to avoid special characters or to include more characters in mangling procedure.

Comment 4 Dan Callaghan 2014-11-20 07:41:20 UTC
And onwards the merry-go-round turns! I am going to dupe this onto a beakerlib bug I found and fixed yesterday: bug 1159191. rlPhaseEnd is mangling the phase name to an RHTS-compatible result name, but it doesn't handle embedded colons properly. This explains the truncated names you are seeing.

As for why we do the mangling at all... that is really an old RHTS-ism, as noted by Marian in comment 3, and it is not something we can realistically change in the rhts-* scripts. Beaker itself will does not care about the result names, it will accept any value. If this limitation in the rhts-* scripts bothers you, the best bet is an alternative harness like restraint.

*** This bug has been marked as a duplicate of bug 1159191 ***

Comment 5 Aleš Mareček 2014-11-20 09:31:57 UTC
I don't understand how this bug can be duplicate of the bug filed a month later. Also, this bug contains more info than BZ#1159191...


Note You need to log in before you can comment on or make changes to this bug.