search

fuzzball-muck / fuzzball

Ongoing development of the Fuzzball MUCK server software and associated functionality.
Other
47 stars 27 forks source link

Consolidate CI #611

Open tanabi opened 3 years ago

tanabi commented 3 years ago

Potentially using Github Actions. We are using a bunch of different builders and tools, it seems like we could probably consolidate and improve our CI/CD pipeline.

Also, the docker build should automatically happen and push to dockerhub when we do a merge to master.

wyld-sw commented 3 years ago

+10000 for this :)

digitalcircuit commented 3 years ago

I'd be in favor of this.

For what it's worth, GitHub Actions is the direction Quassel IRC went (where I got my initial inspiration for the Travis CI and AppVeyor contributions to Fuzzball). There aren't many good options for free macOS builds.

There is one unfortunate caveat with GitHub Actions: you can't download the build artifacts (e.g. Windows executable) unless you're signed into GitHub with an account (any account, doesn't have to be related to Fuzzball MUCK) without using a third-party service, e.g. nightly.link.

nightly.link seems fine to me, open source so you can host your own version if there's concerns about interception of downloads, but it's unofficial and GitHub could break it in the future. Granted, AppVeyor CI and others could discontinue public/anonymous artifact downloads, too. As an example, Quassel switched over to nightly.link for public build access here.

I haven't looked into the specifics, but as long as GitHub's Windows environment provides PowerShell, which it should, Windows builds should in theory translate over, though it'll require switching environment variables and various packaging commands, as one might expect.

There are arguments to be made about AppVeyor and other CI services supporting non-GitHub sources in case Fuzzball wants to migrate in the future, but by the same token, as long as it's not overly Actions-specific then Fuzzball could migrate away again in the future.