Bump dev version

Author: vkarak

docs/manpage.rst

@@ -1515,6 +1515,13 @@ Whenever an environment variable is associated with a configuration option, its
       ================================== ==================
 
 
+.. envvar:: RFM_INSTALL_PREFIX
+
+   The framework's installation prefix.
+   Users cannot set this variable.
+   ReFrame will set it always upon startup.
+
+
 .. envvar:: RFM_KEEP_STAGE_FILES
 
    Keep test stage directories even for tests that finish successfully.
@@ -1867,28 +1874,15 @@ Whenever an environment variable is associated with a configuration option, its
 Configuration File
 ------------------
 
-The configuration file of ReFrame defines the systems and environments to test as well as parameters controlling its behavior.
-Upon start up ReFrame checks for configuration files in the following locations in that order:
-
-1. ``$HOME/.reframe/settings.{py,json}``
-2. ``$RFM_INSTALL_PREFIX/settings.{py,json}``
-3. ``/etc/reframe.d/settings.{py,json}``
-
-ReFrame accepts configuration files either in Python or JSON syntax.
-If both are found in the same location, the Python file will be preferred.
-
-The ``RFM_INSTALL_PREFIX`` environment variable refers to the installation directory of ReFrame.
-Users have no control over this variable.
-It is always set by the framework upon startup.
+The configuration file of ReFrame defines the systems and environments to test as well as parameters controlling the framework's behavior.
 
-If no configuration file can be found in any of the predefined locations, ReFrame will fall back to a generic configuration that allows it to run on any system.
-This configuration file is located in |reframe/core/settings.py|_.
-Users may *not* modify this file.
+ReFrame loads multiple configuration files to determine its final configuration.
+First, it loads unconditionally its builtin configuration which is located in ``${RFM_INSTALL_PREFIX}/reframe/core/settings.py``.
+If the :envvar:`RFM_CONFIG_PATH` environment variable is defined, ReFrame will look for configuration files named either ``settings.py`` or ``settings.json`` (in that order) in every location in the path and will load them.
+Finally, the :option:`--config-file` option is processed and any configuration files specified will also be loaded.
 
-For a complete reference of the configuration, please refer to :doc:`reframe.settings(8) <config_reference>` man page.
+For a complete reference of the available configuration options, please refer to the :doc:`reframe.settings(8) <config_reference>` man page.
 
-.. |reframe/core/settings.py| replace:: ``reframe/core/settings.py``
-.. _reframe/core/settings.py: https://github.com/reframe-hpc/reframe/blob/master/reframe/core/settings.py
 
 Reporting Bugs
 --------------

docs/regression_test_api.rst

@@ -290,6 +290,7 @@ Modules Systems
    :show-inheritance:
 
 .. _build-systems:
+
 -------------
 Build Systems
 -------------

docs/tutorial.rst

@@ -264,13 +264,14 @@ Here is an example for our STREAM benchmark:
     class stream_test(rfm.RunOnlyRegressionTest):
         ...
         reference = {
-            'myhost:baseline': {
+            'generic:default': {
                 'copy_bw': (23_890, -0.10, 0.30, 'MB/s'),
                 'triad_bw': (17_064, -0.05, 0.50, 'MB/s'),
             }
         }
 
-The :attr:`reference` test variable is a multi-level dictionary that defines the expected performance for each of the test's performance variables on all supported systems.
+The :attr:`reference` test variable is a multi-level dictionary that defines the expected performance for each of the test's performance variables on all supported systems (here, ``generic``) and partitions (here, ``default``).
+We explain more about this pre-defined system later in :ref:`systems-and-environments`.
 It is not necessary that all performance variables and all systems have a reference.
 If a reference value is not found, then the obtained performance will be logged, but no performance validation will be performed.
 The reference value is essentially a three or four element tuple of the form: ``(target_perf, lower_thres, upper_thres, unit)``. The ``unit`` is optional as it is already defined in the :func:`@performance_function <reframe.core.builtins.performance_function>` definitions.
@@ -310,6 +311,8 @@ Note that the ``RUN`` message is replaced by ``DRY`` in the dry-run mode.
 You can also check the generated test script in ``stage/generic/default/builtin/stream_test/rfm_job.sh``.
 
 
+.. _systems-and-environments:
+
 Systems and environments
 ========================
 
@@ -338,7 +341,7 @@ We could do that simply by setting the :attr:`valid_prog_environs` as follows:
 
    self.valid_prog_environs = ['+stream']
 
-This tells ReFrame that this test is valid only for environments that define the ``stream`` feature.
+This tells ReFrame that this test is valid only for environments that define the ``stream`` feature (the ``+`` prefix requests a feature; we will explain the syntax later in this section).
 If we try to run the test now, nothing will be run:
 
 .. code-block:: bash
@@ -355,7 +358,7 @@ If we try to run the test now, nothing will be run:
 This happens because ReFrame by default defines a generic system and environment.
 You may have noticed in our first run the ``@generic:default+builtin`` notation printed after test name.
 This is the system partition name (``generic:default``) and the environment name (``builtin``) where the test is being run in.
-The ``generic`` system and the ``builtin`` partition come as predefined in ReFrame.
+The ``generic`` system and the ``builtin`` environment come as predefined in ReFrame.
 They make the minimum possible assumptions:
 
 - The ``generic`` system defines a single partition, named ``default`` which launches test jobs locally.
@@ -387,6 +390,19 @@ Let's look at some key elements of the configuration:
   Their definitions are resolved in the :attr:`~config.environments` section.
 * Every partition and environment can define a set of arbitrary features or key/value pairs in the :attr:`~config.environments.features` and :attr:`~config.environments.extras` options respectively.
   ReFrame will try to match system partitions and environments to a test based on the test's specification in :attr:`valid_systems` and :attr:`valid_prog_environs`.
+  More specifically, a feature is requested with the ``+feat`` and excluded with ``-feat``, whereas an extra is requested with ``%key=val``.
+  Multiple features or extras can be ANDed if specified in the same :attr:`valid_systems` or :attr:`valid_prog_environs` elements or otherwise ORed if specified in different elements:
+
+  .. code-block:: python
+
+     # Valid only for system partitions that define `feat0` and `key0=val` but not `feat1`
+     valid_systems = [r'+feat0 -feat1 %key0=val']
+
+     # Valid only for environments with either feature `A` or `B`
+     valid_prog_environs = ['+A', '+B']
+
+  Finally, a system or system partition name can be specified in :attr:`valid_systems` and similarly an environment name in :attr:`valid_prog_environs`, in which case the test is bound to those specific system partitions and/or environments.
+
 
 There are many options that we can be define for systems, partitions and environments.
 We will cover several of them as we go through the tutorial, but for the complete reference you should refer to :doc:`config_reference`.

reframe/__init__.py

@@ -6,7 +6,7 @@
 import os
 import sys
 
-VERSION = '4.7.0-dev.2'
+VERSION = '4.7.0-dev.3'
 INSTALL_PREFIX = os.path.normpath(
     os.path.abspath(os.path.join(os.path.dirname(__file__), '..'))
 )

reframe/core/logging.py

@@ -420,6 +420,10 @@ def _create_file_handler(site_config, config_prefix):
     timestamp = site_config.get(f'{config_prefix}/timestamp')
     if timestamp:
         basename, ext = os.path.splitext(filename)
+        if not isinstance(timestamp, str):
+            # Use the default value from `datefmt`
+            timestamp = site_config.get(f'{config_prefix}/datefmt')
+
         filename = f'{basename}_{time.strftime(timestamp)}{ext}'
 
     append = site_config.get(f'{config_prefix}/append')

reframe/schemas/runreport.json

@@ -84,7 +84,7 @@
                 "prefix": {"type": "string"},
                 "result": {
                     "type": "string",
-                    "enum": ["success", "failure", "aborted"]
+                    "enum": ["success", "failure", "aborted", "skipped"]
                 },
                 "scheduler": {"type": ["string", "null"]},
                 "stagedir": {"type": ["string", "null"]},