Since last year luacheck change, trailing spaces are no longer
allowed. This caused all documentaiton examples that used them
as a way to mark newlines to look plain wrong.
This commit add an explicit flag to make longer examples more
readable.
* Add a FOLLOW_SYMLINKS so Awesome 3rd party module can share the
awesome test infrastructure by adding themselves as symlinks in
`lib/`, `tests/` and `tests/examples` and otherwise use AwesomeWM
Travis config.
* Add an option to add examples to the C documentation. Previously only
Lua functions could be documented using this framework.
This allows to figure out if a test will generate an image without
having to run it. The long term plan for this is to run the tests during
compiling ("make") and not during configuring ("cmake"). Since the list
of files to e.g. install needs to be known during configuring, this
commit is a necessary step in that direction.
Signed-off-by: Uli Schlachter <psychon@znc.in>
No currently existing test produces a PNG image, so why do we even check
for such an output file?
I did 'rm -rf build && make -j9 && cp -r build /tmp', then applied this
patch, and then did another 'rm -rf build && make -j9'. According to
diff, the resulting directories are basically the same (except for lots
of timestamps and some non-determinism in CMake).
Signed-off-by: Uli Schlachter <psychon@znc.in>
This allows to e.g. easily run awesome from source (for an hour) via
TEST_TIMEOUT=42d tests/run.sh /dev/null.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is not really a test. It just starts xeyes and sees if anything
explodes.
However, the reason for this test is to stabilise code coverage.
Apparently, Gtk(?) sometimes creates shaped windows. This had the effect
that codecov always reports random changes to code coverage, depending
on if this specific test run saw any shaped client windows or not.
Thus, by explicitly adding a test that runs a shaped client, hopefully
these random fluctuations disappear.
Hopefully-fixes: https://github.com/awesomeWM/awesome/issues/1975
Signed-off-by: Uli Schlachter <psychon@znc.in>
This should help with covering the methods for detection/fallback during
tests.
Ref: https://github.com/awesomeWM/awesome/pull/2109#issuecomment-346224956
Uses xrdb -q to check for X server being available.
Ignores the following warning:
> W: awesome: beautiful: can't get colorscheme from xrdb (using fallback).
- install luacov.runner in tests/_runner.lua.
- use Lua's `dofile` to execute the test files, which will give us
coverage for them.
- CMakeLists.txt: revert DO_COVERAGE env injection
- revert cd: make f absolute if not in source_dir
If a tag is specified by name, but no such tags exist, awful.rules would
cause an error (attempt to index a nil value). Fix this and add a test
for this case.
Fixes: https://github.com/awesomeWM/awesome/issues/2087
Signed-off-by: Uli Schlachter <psychon@znc.in>
LUA_COV_RUNNER is used with `add_custom_command` for the command to
generate the images, and AWESOME_THEMES_PATH should be set there.
Since LUA_COV_RUNNER is used also with `execute_process` there is no
need for `set(ENV …)` anymore.
During build svg images of the calendar widget are generated, which
differ based on the current date.
By honouring the environment variable SOURCE_DATE_EPOCH, which is
set by distributions during build, a deterministic date can be used
at build time while keeping the normal behaviour during runtime.
See also: https://reproducible-builds.org/specs/source-date-epoch/
This still runs all the tests in the configure phase, since the tests
report back what output file (png/svg/none) will be generated.. :/
This could be improved by having this table in CMakeLists directly, or
by having a callback into the tests that only reports back that
information. The latter would still execute all the tests (via a Lua
process).
Adds an explicit check-examples target.
mergify[bot]
Emmanuel Lepage Vallee
Uli Schlachter
Yauhen Kirylau
Uli Schlachter
Rastislav Barlik
Daniel Hahler
Daniel Hahler
Reiner Herrmann