workflow: Add make release workflow

[balaji-srin]

When a release is created this new workflow calls the other build
and test workflows and uploads the tested artifacts into github
release.
The existing workflows were modified to make them callable from other
workflows.
Build workflow now uploads the artifacts so that they can be added to
the release. The build workflow uploads the hex, bin and the .config
file. The names of the files will have the sha if built from main and
the tag name if built from a tag.

The release will look like this with the assets (tested on private fork)

The workflow run will look similar to this.

Fixes: #139

[coderbyheart]

Can you add a https://github.com/actions/upload-artifact step so the files get attached to each build?

[coderbyheart]

Then the release task doesn't have to build them again.

[coderbyheart]

Ah, I understand now. This builds artifacts when a release is manually created.

[coderbyheart]

It seems that the version string is not compiled into the firmware.

[coderbyheart]

Build should set release firmware version.

[balaji-srin]

Build should set release firmware version.

Yes I was also thinking about that. The only reason why I did it this way was that that the on_target job (which does the upload of the built binary) runs every night on main. Then the artifact will have the name main in it instead of a Sha and that would lead to non-unique artifacts for runs on main branch. I believe that's acceptable. Will fix

[coderbyheart]

You can include the current checksum of main.

[coderbyheart]

Can you also publish the .config file as an artifact?

[gregersrygg]

Shouldn't the firmware be built with the app version and report it to cloud? This is perhaps a new task since it isn't implemented yet. So it's fine to just add as a task and do it later.

Did a quick check with @simensrostad now, and the schema includes appVersion: https://github.com/nRFCloud/application-protocols/blob/v1/schemas/deviceToCloud/device/device-example.json
Is this what you use @coderbyheart ?

The modem_info library seems to read out this info from a APP_VERSION cmake variable. So in theory I think we could just read out the environment variable from github and define APP_VERSION in our CMakeLists.txt for the app:

if(DEFINED ENV{GITHUB_REF_NAME})
  set(APP_VERSION $ENV{GITHUB_REF_NAME})
endif()

However, the APP_VERSION defined in app context is not visible to the library. Probably because they're in different variable scopes. So it doesn't work.

[coderbyheart]

Yes, as reported in #104, the appVersion property is not sent.

[balaji-srin]

Build should set release firmware version.

This is now fixed.

[balaji-srin]

Can you also publish the .config file as an artifact?

This is done. Now it shows up like this in the release

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[coderbyheart]

The released firmware does not have the release version configured, but this will be handled in a separate PR.