Skip to content

Discussion: Multi-OS support #551

@aelsabbahy

Description

@aelsabbahy

Those who have followed the project know that I'm very hesitant to add support for other OSs in goss. This ticket is to discuss some of the challenges that need to be solved prior to dedicating time/resources to this endeavor:

  1. Locally testing and reproducing bugs - Currently any goss feature/test can be reproduced on a Linux, OSX, and windows machine through docker. What would be the path to locally test/reproduce features locally for Windows and OSX?

  2. Similar to 1 above. Currently, due to docker providing a reproducible test environment, it is very easy to implement CI for goss in travis or other CI engines so long as they support docker. What would be the path to provide isolated/reproducible tests Windows and OSX?

  3. Some concepts in goss don't translate well for windows/OSX. For example, package managers. Goss assumes one package manager per distribution. Windows and OSX are a bit different when it comes to this. For example, windows has packages that can be queried through powershell, but also has a bunch of 3rd party package managers (eg. chocholaty, scoop, appget.). OSX has appstore (not sure how to query this on the CLI or if it's even worthwhile), but then there's macports/brew/nix. What will be the criteria that determines what will be supported by goss and what won't be? Regardless of choice, Allow users to overwrite default driver/type #539 would have to be completed first.

  4. Given that I currently do not have an interest in maintaining Windows and OSX support, how will this effort continue to be maintained? If maintainers will step up and own parts of the code, what happens when they inevitably move on? Would windows/OSX just be unsupported versions of goss?

  5. ROI... I assume Goss on Linux will naturally attract both greater interest as well as support from the open-source community. Is Goss useful for OSX given that it's not a common server platform? For windows, how likely are windows sysadmins to use Goss. Does the concept of a YAML-based, CLI system testing tool make sense inside of a Microsoft ecosystem?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions