Bug 1020851 - Unsetting ARCH breaks task execution
Unsetting ARCH breaks task execution
Status: NEW
Product: Beaker
Classification: Community
Component: beah (Show other bugs)
develop
Unspecified Unspecified
medium Severity medium (vote)
: ---
: ---
Assigned To: beaker-dev-list
tools-bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-18 07:32 EDT by Petr Šplíchal
Modified: 2016-05-31 21:49 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Petr Šplíchal 2013-10-18 07:32:42 EDT
Description of problem:

It seems that test harness is unable to handle situation when the
ARCH parameter with empty value is provided to the task. I believe
the harness should not be sensitive to such common env parameter.

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

Steps to Reproduce:
<task name="/CoreOS/wget/Sanity/download" role="None">
    <params>
        <param name="ARCH" value=""/>
    </params>
</task>

Actual results:
No handlers could be found for logger "rhts_task"

Expected results:
Task successfully executed.
Comment 3 Raymond Mancy 2013-10-21 01:46:30 EDT
This is actually rhts-test-runner.sh that causes the problem, and throws the error if the string is null.

rhts-environment.sh will actually fix this by assigning the result of 'uname -i' to the ARCH var if it is a null string, but the problem is that rhts-environment.sh is not called until _after_ rhts-test-runner.sh tests ARCH and throws this error. 

The best solution may be to always call rhts-environment first. In fact if we do that we may even be able to get rid of those sanity checkers (not sure).

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