Branch based workflows (staging, feature, etc).

1

Hey there,

What’s the recommended way to deploy feature branch versions of an app using github actions? I noticed there was another thread on this (What's the workflow for staging, feature branches, etc?), where @kurt mentioned he was going to try to dig something up, but I haven’t seen a follow up. Since that thread seems to have veered in a slightly different direction (re: billing), I figured I’d start up a new one.

Thanks!

2

I’ve got that poor-man’s version @mrkurt mentioned with a single staging app regex_help/ci.yml at main · maciejgryka/regex_help · GitHub

What it does:

  • there’s a fly.qa.toml which is similar to fly.toml, but for a separate fly app
  • a GH action scales it up and deploys to it, does some testing etc. before deploying to master

This is fine as long as you’ve only got a single feature branch you’re working on at a time. If you want to dynamically create fly apps per feature branch, I think you’ll need to use the GraphQL API; I don’t think there’s an out-of-the-box way for now.

2 Likes
3

I just run a staging & prod environment. I keep the app name out of my fly.toml file and set the FLY_APP environment variable in my github actions depending on the environment I’m deploying to.

You could probably do it for feature branches by using --nowrite with fly init and setting up new fly apps dynamically if they don’t exist. It’s not ideal, but should do the trick.

3 Likes
4

Heads up: fly init is now deprecated in favor of fly apps create appname, which will create an app without any ceremony. fly launch replaces fly init. It will try to detect the current app and generate configuration files for it.

2 Likes
5

Thank you, @maciejgryka and @bekit for the suggestions! I’ll see if I can use these examples to rig something up.

And thanks for the heads up, @jsierles, I’ll keep that in mind.

6

I’m trying to do the same thing but the github action doesn’t seem to pick up the FLY_APP env var. Did you do something custom in your config?

7

Ahh, sorry about that. I would think FLY_APP would work, but I actually use the --app flag in my arguments when doing the deploy. Here’s an example of the build step I use for deploying to a staging environment:

      # Deploy to staging
      - name: Deploy to fly.io staging
        uses: superfly/flyctl-actions@1.1
        env:
          FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}
        with:
          args: "deploy --app myapp-staging --image ${{ needs.build-push.outputs.docker-tag }}"