Adding a build and attach to release workflow (upon release publish).

[blckmn]

Simple workflow to attach the assets once a release is published.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[github-actions]

Do you want to test this code? Here you have an automated build:
Betaflight-Configurator-Android
Betaflight-Configurator-Linux
Betaflight-Configurator-macOS
Betaflight-Configurator-Windows
WARNING: It may be unstable and result in corrupted configurations or data loss. Use only for testing!

[McGiverGim]

Hi! I only wanted to know how different is your publish workflow, because I don't see too much difference with the other one workflow we have.
I don't see too much difference between creating an empty publication, and wait to the action to publish the artifacts, or throw the workflow that creates the artifacts and creates an empty publication.
Maybe is there some other step that I'm not taking into account?

[blckmn]

The issue is creating artefacts and attaching when a release is in draft is that commits can be added to 'master' (before publishing), invalidating the artefacts. The artefacts potentially need replacing once published.

[McGiverGim]

Ok, understood. I prefer to have the builds before publishing and not after, but you make the release, so how you prefer and is easy to you. Only two comments.

[McGiverGim]

If we continue with the automatic execution, maybe we can, to be sure that we download what we want, specify the tag to be sure that the checkout is the correct one?

I've seen that this action has a version 3. Maybe is good too start to use the latest version. It seems the version 3 is in develop, not released, so ignore this...

[blckmn]

Is it not automatically the commit that triggered the run of the job?

EDIT: Confirmed it is the commit that was tagged to trigger the run.

[McGiverGim]

Only a question, maybe is better to add a manual workflow to attach the build artifacts before the publishing? The difference is not too big, but now, the user subscribed receives the notification of a new version, and the artifacts are not available. Is not too much time, 5 minutes more or less if the build goes well (there is a possibility that it has some kind of problem).
And the Android version must be generated (and attached I suppose) out of this flow, so the user will see the Android version but nothing more.
Not a big problem, only wanted to notice it.

[blckmn]

AUTOMERGE: (FAIL)

• github identifies PR as mergeable -> FAIL
• assigned to a milestone -> PASS
• cooling off period lapsed -> PASS
• commit count less or equal to three -> PASS
• Don't merge label NOT found -> PASS
• at least one RN: label found -> PASS
• Tested label found -> PASS
• assigned to an approver -> PASS
• approver count at least three -> FAIL

[McGiverGim]

Ok. If this is the way you like to work, is ok to me.

Another question: if we launch the "earlier" release flow manually, is this flow released too? If true, then maybe remove the earlier one, it has no sense that the manual one create the artifacts, and this other replace them (or worst, duplicate them).

[blckmn]

Ok. If this is the way you like to work, is ok to me.

Another question: if we launch the "earlier" release flow manually, is this flow released too? If true, then maybe remove the earlier one, it has no sense that the manual one create the artifacts, and this other replace them (or worst, duplicate them).

Good question. I would hope that it would replace them - or error. I will test that at some point and let you know.