Migration to Github Actions and multiarch builds #114

LucasRoesler · 2020-11-22T20:55:11Z

Description

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

Motivation and Context

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)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

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

alexellis · 2020-11-25T17:17:10Z

.github/workflows/publish.yaml

+            GIT_COMMIT=${{ github.sha }}
+          load: true
+          push: false
+          tags: ghcr.io/openfaas/certifier:latest


(certifier typo)

alexellis · 2021-02-08T14:47:20Z

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

LucasRoesler · 2021-02-08T19:20:18Z

.github/workflows/publish.yaml

+      -
+        name: Docker meta
+        id: meta
+        uses: crazy-max/ghaction-docker-meta@v1


@alexellis to answer you question about how this differ from classic watchdogt is only here in how the docker metatdata is generated versus https://github.com/openfaas/classic-watchdog/blob/f5f0832493e8165695673fa6855039e08ef524a6/.github/workflows/publish.yaml#L25-L27

Do you see any issue in replicating the approach from the classic watchdog here, so that they are the same and easier to maintain?

I guess, originally this was my recommendation on what we should be doing. But this PR was ignored and the current pattern adopted without considering this one. I will update it to match

Thanks that would be appreciated. There is a rebase needed too, for the Dockerfile.

@alexellis after making the changes i remember the main benefit of this action for creating the tag, this step understands your forked repo and creates the tag accordingly. The workflow for classic-watchdog does not handle forks correctly and can not push to the forked ghcr because the repository is fixed to openfaas

if you are ok with not having it work in forks, then i guess we can remove this, but if you want forked image builds to actually be publishable automatically, we would either need to add more complexity to the workflow or use this action

a note about using this action, it is completely templated, so the exact same snippet can be used in all repos, versus the currently hard coded repo name that needs to be updated to match the repo you copy it to

Templates make sense to me, that is something both should have IMHO.

My real concern is having two divergent builds for the two watchdogs, which should both be doing the same thing

build go binary and upload it
build docker image and upload it

they both do the same flow now, I rebased and updated to copy all of the workflows and makefile changes from classic-watchdog

but I think that crazy-max/ghaction-docker-meta@v1 is probably a more robust way to construct the docker tags and labels

**What** - Create makefile for locally building and testing - Create github workflows - Use buildx to create multiarch builds - Remove travisci Signed-off-by: Lucas Roesler <[email protected]>

**What** - Replicate the build process from classic-watchdog. The makefile will now cross-compile the binary on the local host and the Dockerfile will simply copy the required binary instead of building it inside docker Signed-off-by: Lucas Roesler <[email protected]>

alexellis · 2021-02-12T10:33:36Z

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 · 2021-02-12T10:38:28Z

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 #114 (comment) I can't really test this in my own fork because the repos are hard coded to openfaas

LucasRoesler · 2021-02-12T10:39:04Z

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

alexellis · 2021-02-12T10:41:21Z

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 · 2021-02-12T10:44:01Z

For tracking - openfaas/classic-watchdog#3

alexellis · 2021-02-12T10:45:03Z

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

alexellis · 2021-02-12T10:46:49Z

.github/workflows/build.yaml

+  build:
+    strategy:
+      matrix:
+        go-version: [ 1.13.x ]


Can we use 1.15 like the Dockerfile has?

**What** - Calculate the repo owner from the repository owner, so that docker images can be pushed to forked GHCR Signed-off-by: Lucas Roesler <[email protected]>

LucasRoesler · 2021-02-12T11:21:09Z

@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

**What** - Fix copy-pasta error and use Go 1.15 for both the build and publish workflows Signed-off-by: Lucas Roesler <[email protected]>

LucasRoesler · 2021-02-12T11:23:20Z

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 · 2021-02-12T20:00:01Z

FYI @techknowlogick has now updated the classic watchdog -> openfaas/classic-watchdog@681b861

alexellis

Approved

alexellis · 2021-02-12T20:01:15Z

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 · 2021-02-12T20:02:32Z

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.

LucasRoesler mentioned this pull request Nov 22, 2020

GitHub Actions Migration - tracking issue openfaas/faas#1585

Closed

28 tasks

alexellis reviewed Nov 25, 2020

View reviewed changes

LucasRoesler force-pushed the migrate-to-github-actions-and-buildx branch from 4374bad to bacda06 Compare November 26, 2020 09:00

LucasRoesler commented Feb 8, 2021

View reviewed changes

Migration to Github Actions and multiarch builds

6ede08a

**What** - Create makefile for locally building and testing - Create github workflows - Use buildx to create multiarch builds - Remove travisci Signed-off-by: Lucas Roesler <[email protected]>

LucasRoesler force-pushed the migrate-to-github-actions-and-buildx branch from bacda06 to 6ede08a Compare February 12, 2021 09:49

alexellis reviewed Feb 12, 2021

View reviewed changes

Use dynamic repo owner for docker tags

e059b42

**What** - Calculate the repo owner from the repository owner, so that docker images can be pushed to forked GHCR Signed-off-by: Lucas Roesler <[email protected]>

LucasRoesler force-pushed the migrate-to-github-actions-and-buildx branch from 0855904 to e059b42 Compare February 12, 2021 10:52

Fix golang version during build flow

a4a4615

**What** - Fix copy-pasta error and use Go 1.15 for both the build and publish workflows Signed-off-by: Lucas Roesler <[email protected]>

LucasRoesler requested a review from alexellis February 12, 2021 11:47

alexellis approved these changes Feb 12, 2021

View reviewed changes

alexellis merged commit a49fcb4 into openfaas:master Feb 12, 2021

LucasRoesler deleted the migrate-to-github-actions-and-buildx branch February 13, 2021 09:22

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Migration to Github Actions and multiarch builds #114

Migration to Github Actions and multiarch builds #114

LucasRoesler commented Nov 22, 2020

alexellis Nov 25, 2020

LucasRoesler Nov 26, 2020

alexellis commented Feb 8, 2021

LucasRoesler Feb 8, 2021

alexellis Feb 9, 2021

LucasRoesler Feb 9, 2021

alexellis Feb 9, 2021

LucasRoesler Feb 12, 2021

LucasRoesler Feb 12, 2021

alexellis Feb 12, 2021

LucasRoesler Feb 12, 2021

alexellis commented Feb 12, 2021

LucasRoesler commented Feb 12, 2021

LucasRoesler commented Feb 12, 2021

alexellis commented Feb 12, 2021

alexellis commented Feb 12, 2021

alexellis commented Feb 12, 2021

alexellis Feb 12, 2021

LucasRoesler Feb 12, 2021

LucasRoesler commented Feb 12, 2021

LucasRoesler commented Feb 12, 2021

alexellis commented Feb 12, 2021

alexellis left a comment

alexellis commented Feb 12, 2021

alexellis commented Feb 12, 2021

Migration to Github Actions and multiarch builds #114

Migration to Github Actions and multiarch builds #114

Conversation

LucasRoesler commented Nov 22, 2020

Description

Motivation and Context

How Has This Been Tested?

Types of changes

Checklist:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexellis commented Feb 8, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexellis commented Feb 12, 2021

LucasRoesler commented Feb 12, 2021

LucasRoesler commented Feb 12, 2021

alexellis commented Feb 12, 2021

alexellis commented Feb 12, 2021

alexellis commented Feb 12, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LucasRoesler commented Feb 12, 2021

LucasRoesler commented Feb 12, 2021

alexellis commented Feb 12, 2021

alexellis left a comment

Choose a reason for hiding this comment

alexellis commented Feb 12, 2021

alexellis commented Feb 12, 2021