Commit Graph

12 Commits

Author SHA1 Message Date
Erik Skultety
4096a59e6e ci: jobs.sh: Define and create SCRATCH_DIR for local executions
Running outside of GitLab will likely not have the variable set and
hence the execution would fail. To make sure we always start with a
clean scratch dir (which may or may not be the best thing), create it
with 'mktemp'. The main reason for a temporary directory is to ensure a
clean environment for the job every time run_integration function is
run. For repeated interactive use case, it is imperative that the
developer takes care of their environment.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-19 13:35:59 +02:00
Erik Skultety
a2c3a3e038 ci: jobs.sh: run_integration: Print DAEMONS variable for debugging
One advantage that GitLab's YAML has with Shell commands is that every
single line is printed out as is, including control structures. In
order to see whether the logic did the same thing and the tests are
going to operate on the right set of daemons (monolithic vs modular),
lets print the DAEMONS variable that we set depending on the distro we
execute the tests on.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-19 13:35:59 +02:00
Erik Skultety
0c9603c858 ci: jobs.sh: integration: Execute commands via 'run_cmd[_quiet]' helpers
Unfortunately, once we go down the line of running our own scripts as
part of GitLab CI jobs rather than open coding Shell in YAML, we lose
the benefit of seeing each line the script executes. The downside of
the default YAML however is that we have to maintain the same piece of
code on 2 places in that case. Let's adopt what we use with other
container jobs and prefix each shell command with 'run_cmd' or
'run_cmd_quiet' which will dump it in the logs before executing.
Flow control expressions and structures are a problem though in this
regard, so let's just print some important values for debugging
purposes.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-19 13:35:59 +02:00
Erik Skultety
e004458616 ci: jobs.sh: Introduce a quiet version of run_cmd
We've started using the run_cmd helper function to log what kind of
command is being executed as well as actually executing the command.
The problem however is doing I/O redirections for commands which we
don't wish to see any output for whatever reason. Now, if the
redirection is applied at parameter passing to run_cmd it's going to be
applied to the debug print as well. Let's introduce another helper,
run_cmd_quiet which takes care of the I/O redirection and executes the
command completely silently.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-19 13:35:59 +02:00
Erik Skultety
a91e6f69f4 ci: jobs.sh: run_integration: Make POSIX-compliant
Neither '&>' nor 'source' are defined in POSIX.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-19 13:35:59 +02:00
Erik Skultety
a6b85e03d4 ci: jobs.sh: run_integration: Add/Rewrite/Reformat commentaries
Because of the nature of writing inline shell commands to YAML, most of
the commentaries where inlined with the command not to hinder YAML
readability any further. Since we moved the logic to a standalone
script, we can now do whatever formatting & readability adjustments we
want.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-19 13:35:59 +02:00
Erik Skultety
5c9dfa2091 ci: jobs.sh: integration: Use --quiet with virsh
We've not been interested in any extra output from the command at all
since we always redirected both stdout and stderr to /dev/null. Future
patch will change that slightly, so --quiet will start making sense.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-19 13:35:59 +02:00
Erik Skultety
9847d3eda4 ci: jobs.sh: Drop comment about the need for Avocado 98.0
We needed v98.0 in commit c9a65eb8 due to a bug in Avocado in the past
and have been installing the latest Avocado for a while since commit
91774931, yet we kept the comment by a mistake.

Besides, looks like v98.0 ignores the avocado.config file in the TCK
repo instructing it to run the test suite sequentially leading to test
stability issues, so abandoning the v98.0 in commit 91774931 was a good
thing in the end.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-19 13:35:58 +02:00
Erik Skultety
82f4bfc34c ci: integration: Adjust the check for CentOS Stream version
All supported versions of Fedora and CentOS Stream 9 default to modular
setup, it's probably better if we cosmetically adjust the CentOS Stream
version check to make it explicit that monolithic daemon services ought
to be started only on Stream 8.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-19 13:35:58 +02:00
Erik Skultety
6e9bd600d7 ci: integration: Extract the integration CI main recipe to jobs.sh
Follow what's been done to other jobs in .gitlab-ci.yml and extract the
shell logic from YAML to a function in ci/jobs.sh

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-19 13:35:58 +02:00
Erik Skultety
1f85f0967b ci: jobs.sh: Add back '--no-suite syntax-check --print-errorlogs'
Commit f688a53a converted .gitlab-ci.yml to the usage of ci/jobs.sh
functions, but in doing that our test options
    '--no-suite syntax-check --print-errorlogs'
got lost in the process and since commit 8e660c52 didn't introduce them
in the first place, it caused a behavioral regression. This patch adds
them back.

Fixes: 8e660c5286

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-13 14:17:26 +02:00
Erik Skultety
ed7aa04de4 ci: Rename build.sh -> jobs.sh
After the recent changes, this script no longer executes any logic
anymore, it merely defines the jobs run in the GitLab environment. In
order to use it, one has to source the file in the environment and then
run one of the job "functions". For that, the 'build.sh' name is no
longer descriptive enough and 'jobs.sh' feels more suitable and less
misleading.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2023-09-12 11:36:03 +02:00