Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1206059

Summary: support testinfo.desc Environment in restraint
Product: [Retired] Restraint Reporter: Dan Callaghan <dcallagh>
Component: generalAssignee: Matt Tyson 🤬 <mtyson>
Status: CLOSED CURRENTRELEASE QA Contact: Roman Joost <rjoost>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 0.1.18CC: asavkov, bpeck, dcallagh, jburke, mprchlik, mtyson, rjoost
Target Milestone: 0.1.35Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-06-24 23:49:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dan Callaghan 2015-03-26 08:59:41 UTC 
Steps to Reproduce:
1. Run a task that relies on env vars defined with Environment: in testinfo.desc (for example /distribution/beaker/dogfood)

Expected results:
Restraint should set the environment variables in the task's execution environment.
Comment 1 Miloš Prchlík 2017-07-04 07:17:59 UTC 
What are the chances of getting this feature implemented? In BaseOS CI, it was recently pointed out that its jobs - which use restraint to run the tests - ignored "AVC_ERROR=+no_avc_check" passed in rpm's testinfo.desc, and we found out it is indeed imperfection of restraint. As it's quite a common way of disabling AVC denials checks during runtime of the test, we'd appreciate the implementation of this feature.
Comment 2 Matt Tyson 🤬 2018-04-09 01:00:07 UTC 
If the same environment variable is defined in both the job XML and testinfo.desc, which has the higher priority?
Comment 3 Dan Callaghan 2018-04-09 01:19:12 UTC 
It should be: a task parameter in the job XML overrides a testinfo.desc Environment setting.

You could dig through beah's implementation to verify that this is true for beah (we would want restraint to follow beah's behaviour in this regard).