Platform feature-parity
macOS and Windows binaries are new and considered alpha-quality. Some functionality may be missing, some may be broken. (Enhancements and bug-reports welcome, please see #551)
To clearly signal that, goss emits a log message on every invocation saying so, linking here, then exits with a clear error.
To try out the alpha functionality, you must do one of:
- pass
--use-alpha=1
to the root command (e.g.goss --use-alpha=1 validate
). - set an environment variable
GOSS_USE_ALPHA=1
.
The macOS and Windows support is community driven; there is no commitment to adding features / fixing bugs for those platforms. See thread.
This matrix attempts to track parity across platforms.
Legend
Symbol | Meaning |
---|---|
Fully supported/tested | |
Full working/tested, community support | |
Works but without automated tests | |
Works partially / partially tested | |
Not implemented / needs implementation | |
Not applicable for this platform | |
Not yet tried, no data |
About partial support
This is ambiguous. Where you see this, check into the test coverage within integration-tests/goss/{darwin|windows}/{test}.goss.yaml
for more detail.
It might be that not all features work as on linux
, it might be that not all features are covered by automated tests.
Tests/assertions support matrix
Test | Option | Linux | macOS | Windows |
---|---|---|---|---|
addr | ||||
reachable | ||||
local-address | ||||
timeout | ||||
command | ||||
exit-status | ||||
stdout | ||||
stderr | ||||
timeout | ||||
dns | ||||
resolvable | ||||
addrs | ||||
server | ||||
timeout | ||||
file | ||||
exists | ||||
mode | ||||
size | ||||
owner | ||||
group | ||||
filetype | ||||
contains | ||||
md5 | ||||
sha256 | ||||
linked-to | ||||
gossfile | ||||
group | ||||
exists | ||||
gid | ||||
http | ||||
status | ||||
allow-insecure | ||||
no-follow-redirects | ||||
timeout | ||||
request-headers | ||||
headers | ||||
body | ||||
username | ||||
password | ||||
interface | ||||
exists | ||||
addrs | ||||
mtu | ||||
kernel-param | ||||
value | ||||
mount | ||||
exists | ||||
opts | ||||
source | ||||
filesystem | ||||
usage | ||||
matching | ||||
package | ||||
installed | ||||
versions | ||||
port | ||||
listening | ||||
ip | ||||
process | ||||
running | ||||
service | ||||
enabled | ||||
running | ||||
user | ||||
exists | ||||
uid | ||||
gid | ||||
groups | ||||
home | ||||
shell |
Commands support matrix
Test | Linux | macOS | Windows |
---|---|---|---|
add |
|||
autoadd |
|||
help |
|||
render |
|||
serve |
|||
validate |
command
testing notes
Run all of the darwin
/windows
integration tests:
The script finds all goss spec files within integration-tests
then filters to just ones matching the passed OS-name,
then runs validate
against them.
Command: serve
This is a special-case test since it requires a persistent process, then to make the http request, then to tear down the process.
macOS serve
Windows serve
Contributing
The current integration test approach is only appropriate for validating linux
binaries against linux
OS/arch combinations.
Validating macOS
and Windows
binaries requires adding coverage that runs on those platforms within Travis,
but since Travis does not support containerised builds for either platform,
assertions are limited to assert against the state of the CI hosts, where we're relying on that to predictable.
You can find goss-files that are used to populate this matrix within integration-tests/goss/{darwin|windows}/{test}.goss.yaml
.
Where a feature does note work the same as linux, it is commented.
The intent is to end up with a set of running-and-passing tests.