Connecting Github actions to a fly deploy

We’ve started automagically labelling your images when we detect that a GH Action ran a deploy. This allows us to connect a deploy with the Github Action and SHA associated with it to provide greater visibility into app deploys. You can now see this detail in the UI under the activity tab.

We hope that this provides better insight into the origin of your deploys. This is just the start of us getting better at integrating your apps with the CI tools that run them. Let us know what you think and how we can better integrate fly into your workflows! :smiley:

13 Likes

:100: :100: :100: :100: :100: :100:

1 Like

Should this happen with any deploy run inside a GH Action, or just ones where the build is done using flyctl inside a GH Action?

I’m not seeing it appear; we build our image separately, push it to the Fly registry, and then run the deploy command:

Is this feature related to Labelling images with metadata? (Thinking there might be some label set if building using flyctl inside an Action.)

@thewilkybarkid It should happen when the build is accomplished via flyctl in a GH Action. It’s pretty naïve in that regard, if flyctl is run by the GH Action, we read the env var that GH exposes and label images accordingly.

In your case, you could probably grab the env var from GH and pass it to the deploy command via the label flag. This feature is related to the label flag since we added some logic to write metadata to image as labels, but not directly since it doesn’t get that metadata via the label flag.

Hope that’s helpful!

1 Like

Thanks @shortdiv; can see the relevant labels in:

Will try adding them at some point. The SHA is the one of interest, but I guess they all need to be present.

1 Like

How can I opt out of this? I don’t want these labels added.

@pmbanugo Hey, you can’t opt out at the moment. We are currently only adding 4 labels, so it doesn’t clutter an image too much. Is there a reason why the label is problematic for your use case?

I have a client where I use a single repo to co-ordinate the deployment for multiple repo/apps. With this feature, it means some apps will have incorrect labels because they’ll be using the label of the repo the GH Action Workflow was executed in.

In general, it’ll be better if some of these new features to the CLI are not auto opt-in, or at least allow people disable them. For example, extensions are added by default and one has to opt-out using --no-extensions. I’d prefer if they weren’t the default and I can optionally add selected extensions.

Upgrading flyctl version in CI/CD pipelines becomes tricky because I now have to read every release note so I don’t introduce unintended changes, even if it’s just a minor or patch version update. Maybe the CLI doesn’t follow semver release though