search

guysoft / OctoKlipperPi

OctoPi klipper using the CustoPiZer distro builder
GNU General Public License v3.0
89 stars 15 forks source link

Fix GitHub Action workflow #2

Closed foosel closed 3 years ago

foosel commented 3 years ago

Can be triggered automatically through repository dispatch & manually through workflow dispatch, allowing to specify the OctoPi version to build against.

Also triggers on pushes to any branch.

Runs a build and for pushes uploads the resulting output image as build artifact. In case of dispatch creates a new release and publishes the artifacts and an rpi-imager.json snippet that way.

For an example result (with the rpi-imager.json snippet pointing to the wrong download URL however, as that's already tailored towards your repo here) see https://github.com/foosel/OctoPi-Klipper-CustoPiZer/releases/tag/0.18.0.klipper.20211026092122

foosel commented 3 years ago

In case you've so far never used workflow_dispatch:

image

And this is how repository_dispatch works: https://docs.github.com/en/rest/reference/repos#create-a-repository-dispatch-event. Can be part of another workflow for example, I now use it to trigger the OctoPi-UpToDate build from OctoPrint's release workflow.

guysoft commented 3 years ago

@foosel Ok, the fact that it creates the rpi-imager.json is cool - can we get that to upload to the OctoPi rpi-imager tool?

foosel commented 3 years ago

It only creates a snippet of one. That needs to be incorporated into a full imager file then and published somewhere. For stock OctoPi I currently do this here based on the OctoPi-UpToDate releases: https://github.com/OctoPrint/octoprint.org/blob/4b33f785461bcf6d69a5152a26799a5c3798cbd4/.github/workflows/publish-to-github-pages.yml#L18-L26. And that's also live:

https://octopi.octoprint.org/rpi-imager.json

image

We could probable extend that to also fetch the latest release of a Klipper-including build, but for that I'd prefer we first make sure the build pipeline is fully set up (e.g. automatic build triggered on new OctoPrint & OctoPi release, and also some reasonable way to determine a stable Klipper release is built in and not just whatever's floating around the repository at build time - a similar mechanism to OctoPrint version determiniation could be used for that, but I'm not familiar enough with the Klipper project to know whether the tags can be relied upon to be kept up to date or not) and the build to have seen more testing.