Auto-deploy to FlowFuse Cloud on merge with main branch

[joepavitt]

Description

Blockers:

• [x] https://github.com/FlowFuse/helm/issues/295
• [x] #3683
• [ ] https://github.com/FlowFuse/CloudProject/issues/387

Nice to haves:

• [x] https://github.com/FlowFuse/flowfuse/issues/3668

Follow Ups

• [ ] Update website build to pull from main and not maintenance branch

[joepavitt]

Am I right in saying that we can (and do) now deploy MQTT brokers with the staging environments tagged deploy:pr?

[joepavitt]

With #3668 now merged, what configuration/button needs to be clicked to enable this?

[ppawlowski]

A Required review deployment protection rule within FlowFuse/helm repo needs to be unchecked.

[joepavitt]

We're also going to auto-add deploy:pr tag to all PRs going forward - as first iteration.

Future iteration:

• Don't add label for just docs changes
• Author of the PR may be a factor, i.e. only add the label automatically if a FF team member?

[hardillb]

Just a note about testing things like the dependbot PRs for SSO packages.

This will also require us to ensure that all dependbot PRs are tested on pre-staging envs.

Testing this in a pre-staging test environment will be tricky as it will require a lot of work to configure the pre-staging environment to work with e.g. Google SSO.

[joepavitt]

Testing this in a pre-staging test environment will be tricky as it will require a lot of work to configure the pre-staging environment to work with e.g. Google SSO.

In this case Ben - what's the proposed workflow, assuming we haven open PR, what would we need to do in order to test that in a staging environment, without the auto-deploy to production being triggered?

[hardillb]

@joepavitt to be honest that's probably a @knolleary question, I've never setup the SSO stuff (and it probably requires admin access to the g-suite tools or us hositng our own test keyclock instance)

[ppawlowski]

IMO acceptance tests executed against a staging environment should catch this kind of errors.

[ppawlowski]

https://github.com/FlowFuse/CloudProject/issues/387 contains some concerns about moving forward with this.

[joepavitt]

@ppawlowski whilst the concerns are valid, I don't want this blocking the merge on main.

I would like to move forward with production builds on merge with main

[ppawlowski]

@joepavitt flowfuse npm package, as well as the container image used for the deployment to both environments, are built on each push to the main branch.

[joepavitt]

Can you clarify what you mean by flowfuse npm package? We aren't updating version numbers, etc, so not releasing?

We just want to be updating production FF Cloud?

Also, is your message saying that's the case as of now, or that was already the case as of a few days ago?

[ppawlowski]

On each merge to main in the Flowfuse/flowfuse repo, the following things happen:

1. FlowFuse npm package is built and published to the npm registry with a nightly tag by this pipeline.
2. The same pipeline triggers another one, responsible for building a container image
3. Container image build pipeline uses flowfuse npm package created in step 1 (tagged as nightly) to build a fresh container image
4. The resulting image is used to perform deployment on both staging and production environments.

According to the git log, this approach was introduced ~7 months ago.

[joepavitt]

Thanks @ppawlowski - it's not documented anywhere in our handbook, so wasn't aware of the details. I'm happy to put them in, will add you as a reviewer

[joepavitt]

I can see the latest builds triggered by main here: https://www.npmjs.com/package/@flowfuse/flowfuse?activeTab=versions

I'm not then clear on what's triggering:

The resulting image is used to perform deployment on both staging and production environments.

Those builds were an hour ago, and production still hasn't reflected those changes.

[joepavitt]

@hardillb has pointed out we still have a manual approval step as per: https://github.com/FlowFuse/helm/actions/runs/8849960781

[joepavitt]

This is now live - closing