This allows for `DO_COVERAGE=1 make check` with local tests (where
`CI=true` is not given).
It uses the new environment variables to configure the default theme,
instead of creating a temporary config/theme.
- checkout previous commit, so the coverage upload uses the current
code
- do not run coverage reports when testing previous commits
- improve failure message: display subject/author/name for each commit
The build files do not get updated on source changes currently anyway
(as a dependency of these targets), and this seems to be a leftover from
when `lua.in` files were used / pre-processing was required?!
- Execute the tests without compiling, and don't mess with the source
files when coverage is enabled.
This ensures that the coverage report lines are correct.
This disables the doc tests, as their results would be unused.
Hack: it still expands macros on util.lua, because of
`util.get_themes_dir()` and `util.get_awesome_icon_dir()`, which might
be moved later. Ref:
https://github.com/awesomeWM/awesome/pull/1239#discussion_r93828178.
- ensure that BUILD_APIDOC and DO_COVERAGE are not used together
- awesomeConfig.cmake: add DO_COVERAGE as an option
- Travis: only install codecov with DO_COVERAGE=codecov
- Travis: do not use set -v; use set -x with DO_COVERAGE
- do not use trailing slashes with dirs in tests/examples/CMakeLists.txt / .luacov
- Use latest luacov (0.12.0-1) again
This reverts parts of 4cc6a815.
I think it is better to fix any failure that 4cc6a815 tried to work around.
- Travis: simplify/fix require('luacov') for functionaltests
- tests/examples/CMakeLists.txt: resolve ../.. in SOURCE_DIR
- tests/examples/CMakeLists.txt: add DO_COVERAGE to env
- Cleanup/simplify .luacov: work with SOURCE_DIRECTORY alone
- tests/run.sh: pass through / set SOURCE_DIRECTORY when running awesome
- tests/run.sh: resolve source_dir
- use DO_COVERAGE from env only
These warnings might help catching some problems in the future. These
could be asserts, but printing a warning is a lot nicer than dying.
Signed-off-by: Uli Schlachter <psychon@znc.in>
X11 does not allow to resize a window to size 0x0. Also, there are some
possibilities of integer overflows in our case. We tried to handle this
already, but there was a loop-hole: If the too-small-value is only
produced after applying size hints, then this was not caught.
Fix this by applying size hints before checking if the resulting size is
valid. However, this means some check needs to be duplicated to handle
the possibility of integer underflows while applying size hints.
Helps-with: https://github.com/awesomeWM/awesome/issues/1340
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a new argument to the test client spawning function that will
make the test client window set a resize increment property.
The API here is starting to a bit ugly, but since this is not any user
facing API, that should not be a problem.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Otherwise commented lines look like ---- My comment
instead of -- -- My comment. This wasn't a problem before the
intentation fix commit, but it is now.
Commit a944636c02 "bashified" tests/run.sh for some reason.
Afterwards, commit 4abd820051 fixed some of the fall-out.
However, there is still a problem left.
We have "set -e" in this script. Thus, whenever some command exits with
status 0, the script abort. When the variable errors is zero/unset, the
command "((errors++))" has exit status zero. Thus, this instruction
caused the shell script to abort. This was not intended.
Fix this by using "((++errors))" instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, the test runner used a timer which fired every 0.1 seconds
to "do its thing". Many of these waits seem unnecessary.
This commit makes the test runner wait 0 seconds for the first call of a
step function. Only following calls will have a timeout of 0.1 seconds
applied.
A full run of the test suite (tests/run.sh without further arguments)
took about 100 seconds before this change. After this change, we are
down to 60 seconds. This is almost factor two faster! (Well, five thirds
is the exact number, so factor 1.66)
(The numbers are best out of three runs. The "before" number is rounded
down while the "after" number is rounded up.)
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function should only be necessary for the test suite. It makes sure
that the X11 server received and handled all previous requests that
awesome sent. This will be needed, for example, in tests that use
root.fake_input().
After a call to awesome.sync(), we are sure that "faking input" has been
done and the next main loop iteration will handle the input event.
Without the sync, it could happen that the X11 server did not yet fake
the input in the next iteration.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When menubar.refresh() is called, it tries to update the menubar widget.
The call chain looks like this: menulist_update -> common.list_update ->
get_current_page. get_current_page then tries to query information about
the size of the menubar.
Since there is not much point in this, just skip the whole callback in
this case.
Side note: What is the point of menubar.get()? It seems quite useless to
me.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously we got the following unhelpful error message:
tests/_client.lua:98: bad argument #2 to 'assert' (string expected, got
userdata)
Signed-off-by: Uli Schlachter <psychon@znc.in>
When the child process in tests/_client.lua breaks and exits (for
example: Remove the call to Gtk.main), we get a broken pipe. When trying
to write to the pipe that connects awesome to the child process, we get
a SIGPIPE signal that causes awesome to exit without any good error
message.
Fix this by ignoring SIGPIPE. We do not want to be killed by it anyway.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Daniel Hahler
Uli Schlachter
Emmanuel Lepage Vallee
rob
Ingo Bürk
Daniel Hahler
Uli Schlachter