Migration to Github Actions and multiarch builds

LucasRoesler commented 3 years ago

Description

Create makefile for locally building and testing
Create github workflows
Use buildx to create multiarch builds
Remove travisci

Motivation and Context

[x] I have raised an issue to propose this change (required)

Relates to openfaas/faas#1585

How Has This Been Tested?

Testing in my fork

Built images https://github.com/LucasRoesler?tab=packages&repo_name=of-watchdog
Release with binaries https://github.com/LucasRoesler/of-watchdog/releases/tag/v0.0.5

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I've read the CONTRIBUTION guide
[x] I have signed-off my commits with git commit -s
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

alexellis commented 3 years ago

Hi @LucasRoesler, this came up on my radar again. How does this PR now compare to the approach we took in the classic watchdog?

https://github.com/openfaas/classic-watchdog/tree/master/.github/workflows

alexellis commented 3 years ago

To avoid any release tags being released which have no binaries attached due to failed builds, can you take a moment to test this with your own account and to confirm it worked as expected? The suggestion you made to template the owner makes sense.

If you need somewhere to copy/paste from see - https://github.com/alexellis/faasd-example/blob/master/.github/workflows/build.yml#L27

LucasRoesler commented 3 years ago

To avoid any release tags being released which have no binaries attached due to failed builds, can you take a moment to test this with your own account and to confirm it worked as expected? The suggestion you made to template the owner makes sense.

If you need somewhere to copy/paste from see - https://github.com/alexellis/faasd-example/blob/master/.github/workflows/build.yml#L27

I don't know how to accurately test this in my own fork. Per the comment https://github.com/openfaas/of-watchdog/pull/114#discussion_r575110205 I can't really test this in my own fork because the repos are hard coded to openfaas

LucasRoesler commented 3 years ago

If I update with your copy and paste are you going to update classic-watchdog as well?

alexellis commented 3 years ago

I am not sure what you mean by "with your copy/paste"?

The idea is to have two both watchdogs build and published in a consistent way. The classic watchdog could benefit from having a generated owner name, just like you suggested.

It would be worth having both the same, but I don't know whether that's something I am going to pick up or another contributor. Whoever does it, needs to test that the change works on their fork before it gets merged - it looks bad when we have tags with no binaries attached because a build can't pass.

alexellis commented 3 years ago

For tracking - https://github.com/openfaas/classic-watchdog/issues/3

alexellis commented 3 years ago

Actions are enabled now, so if you can force a push, it should run.

LucasRoesler commented 3 years ago

@alexellis here is the link to the test tag image https://github.com/users/LucasRoesler/packages/container/package/of-watchdog and the release with assets https://github.com/LucasRoesler/of-watchdog/releases/tag/v0.0.6

LucasRoesler commented 3 years ago

I am not sure what you mean by "with your copy/paste"?

The idea is to have two both watchdogs build and published in a consistent way. The classic watchdog could benefit from having a generated owner name, just like you suggested.

It would be worth having both the same, but I don't know whether that's something I am going to pick up or another contributor. Whoever does it, needs to test that the change works on their fork before it gets merged - it looks bad when we have tags with no binaries attached because a build can't pass.

I mean that the classic-watchdog workflow will need to be updated to allow the repo owner to be dynamic or else these two projects will have divergent GHA workflows

alexellis commented 3 years ago

FYI @techknowlogick has now updated the classic watchdog -> https://github.com/openfaas/classic-watchdog/commit/681b86125047a57349ffe1b7bfdccd567f1b4c64

alexellis commented 3 years ago

Thanks for all the work you put into this @LucasRoesler - sorry that it took so long to get to it, and that we changed the approach a couple of times in the interim.

alexellis commented 3 years ago

This is the tag created with the latest changes, please check it and see if it looks as expected:

https://github.com/openfaas/of-watchdog/releases/tag/0.8.3

I may need to make the matching Docker image public once it's available.

openfaas / of-watchdog