Project

General

Profile

Actions

Bug #22506

open

Fix run-tests.sh to accept WORKSPACE=... on command line

Added by Tom Clegg 3 days ago. Updated 1 day ago.

Status:
In Progress
Priority:
Normal
Assigned To:
Category:
Tests
Target version:
Story points:
0.5

Description

In #22428 we accidentally lost the (advertised) ability to run run-tests.sh like this

./build/run-tests.sh WORKSPACE="$(pwd)" --interactive

Instead of doing the expected thing, it gives lots of hints that's working but then can't run any tests because $gostuff and $testfuncargs aren't set properly.

What next? test lib/controller/localdb
./build/run-tests.sh: line 467: skip: bad array subscript
./build/run-tests.sh: line 467: skip: bad array subscript
Starting API, controller, keepproxy, keep-web, ws, and nginx ssl proxy...
api pid 2287217 ok
...
======= test
./build/run-tests.sh: line 578: test_: command not found
=======  tests -- FAILED
======= test  -- 0s
Pass: sdk/python install (1s)
Failures (1):
Fail:  tests (0s)
What next? 

Subtasks 1 (1 open0 closed)

Task #22507: Review 22506-workspace-argIn Progress01/30/2025Actions
Actions #1

Updated by Tom Clegg 3 days ago

  • Subject changed from Fix run-test.sh to accept WORKSPACE=... on command line to Fix run-tests.sh to accept WORKSPACE=... on command line
Actions #2

Updated by Tom Clegg 3 days ago

  • Subtask #22507 added
Actions #3

Updated by Brett Smith 2 days ago

I'm not disputing this is a regression, but: you can already do this as long as you write WORKSPACE (and any other variables) before the start of the command proper, e.g.,

WORKSPACE="$PWD" build/run-tests.sh ...

Do we really need code to reimplement a feature the shell already has? Could we just make this the documented way?

Actions #4

Updated by Tom Clegg 1 day ago

Sure. I guess if anyone else uses this to set WORKSPACE they will figure out easily enough how to fix it.

I've updated Running tests, since setting WORKSPACE the normal way already worked.

In this version I've made envvar=val an error, and updated the help text. I retained the ability to set ARVADOS_* vars via command line, because (I suppose) we still want the "scrub ARVADOS_*" bit that isolates the tests from any [real] arvados env vars that happen to be set.

22506-workspace-arg @ 9ae1dc73ecc5fc2aa30594c5d66216bcfde8a0db -- developer-run-tests: #4636

Actions

Also available in: Atom PDF