[FR] `--no-parallel` flag

[skeggse]

Problem to solve

I'm testing AWS Lambda functions in container images, and using testcontainers and the AWS Lambda Runtime Emulator to do that.

Lambda functions are single-threaded and single-concurrency. They don't accept multiple concurrent requests, so the behavior of --test running in parallel is unhelpful in this case.

Proposal

--no-parallel to explicitly disable parallelism even if --test provided.

Alternatively, if --jobs is 0, disable parallelism that way.

[jcamiel]

Hi @skeggse
You can use --jobs 1 to disable parallel run. I'm changing the label of this issue to "documentation" because it's not clear in the doc and in the man page,

[skeggse]

Oh interesting. I'm clearly not understanding the code, then. Where does that determination happen?

hurl/packages/hurl/src/main.rs

Lines 84 to 96 in cfa3068

	let runs = if opts.parallel {
	let available = unwrap_or_exit(
	thread::available_parallelism(),
	EXIT_ERROR_UNDEFINED,
	&base_logger,
	);
	let workers_count = opts.jobs.unwrap_or(available.get());
	base_logger.debug(&format!("Parallel run using {workers_count} workers"));
	run::run_par(&opts.input_files, current_dir, &opts, workers_count)
	} else {
	run::run_seq(&opts.input_files, current_dir, &opts)
	};

[jcamiel]

You can see the code here

hurl/packages/hurl/src/parallel/runner.rs

Lines 32 to 45 in cfa3068

	/// A parallel runner manages a list of `Worker`. Each worker is either idle or is running a
	/// [`Job`]. To run jobs, the [`ParallelRunner::run`] method much be executed on the main thread.
	/// Each worker has its own thread that it uses to run a Hurl file, and communicates with the main
	/// thread. Standard multi-producer single-producer channels are used between the main runner and
	/// the workers to send job request and receive job result.
	///
	/// The parallel runner is responsible to manage the state of the workers, and to display standard
	/// output and standard error, in the main thread. Each worker reports its progression to the
	/// parallel runner, which updates the workers states and displays a progress bar.
	/// Inside each worker, logs (messages on standard error) and HTTP response (output on
	/// standard output) are buffered and send to the runner to be eventually displayed.
	///
	/// By design, the workers state is read and modified on the main thread.
	pub struct ParallelRunner {

There is a slight implementation difference between:

• hurl *.hurl
• hurl --test --jobs 1 *.hurl

The first one uses a sequential runner (single thread, the thread of execution is the main thread). The second one uses a parallel runner (multi-threaded), bound by only one thread (the thread of execution is the single spawned thread, not the main thread). In this case, each files is being run one after one, on this spawned thread. That's why it's more a --jobs 1 than a --no-parallel option if that makes sense. The other difference is the output (stdout and stderr). We've made the decision to always write output on the main thread. So in case of --jobs 1, logs are buffered and outputted at the end of each run. In the sequential runner, as there is only the main thread, logs are outputted immediately, non buffered.

There is also a design implementation doc here https://github.com/Orange-OpenSource/hurl/blob/master/docs/spec/runner/parallel.md

[skeggse]

Yeah, I'd specifically like a way to disable the secondary thread when using --test, since --jobs 1 has a different behavior.

[jcamiel]

To do this, the easiest way is to not use --test: the run will be single threaded, the only thing missing is the final report (x Sucess, x Failed) etc... but you can still use various report if you need (TAP report with --report-tap, JUnit, HTML etc...). Even without ˋ--test` assertions are checked and exit code is different from 0 in presence of errors.