Updating workflows.

[Juanito87]

Updating workflows to have:

• Build and test with binary upload
• Build and release with binary upload

Please let me know if other binaries need to be uploaded.

[DavidLazarescu]

Hey, thank you for the PR.

I got some questions since I have only basic knowledge about github actions. I have seen that you have added an "Upload artifact" step at the end of the test workflow. I have looked over the actions/upload-artifact repository and it seems like it's for sharing data between jobs and the data can be downloaded via the download artifact counterpart, but I can not see you using it anywhere. What exactly is that for?

Also, could we make the "Release" action depend on the test action and then use "download artifact" to avoid building the project twice (since it takes ~8 minutes per build).

Apart of that, do I understand it correctly that the "Publish release" step automatically detects all binary files, bundles them and then publishes them as a tar.gz?

[Juanito87]

So, to address you questions:

I have seen that you have added an "Upload artifact" step at the end of the test workflow. I have looked over the actions/upload-artifact repository and it seems like it's for sharing data between jobs and the data can be downloaded via the download artifact counterpart, but I can not see you using it anywhere. What exactly is that for?

So Upload artifact is in place to validate 2 things:

• Name/path don't change between builds
• Allowing individual testing on the binary, after the automation runs

Never used it to download from a different step, but I can investigate this and update accordingly.

Also, could we make the "Release" action depend on the test action and then use "download artifact" to avoid building the project twice (since it takes ~8 minutes per build).

Currently, the release action will only trigger on tags being pushed to the main branch, that match the previous regex (vx.x.x). So it will only trigger when you push a tag to a specific commit, it shouldn't trigger in other scenarios. I can investigate further the download artifact option for the release. You need to take into account that uploaded artifacts have a life time (in repo settings), so you should run the release task close to the test, but also not sure about which artifact will the action download, so you could end up with the wrong binaries in the release. This scenario requires further research on my part. Not sure if you wan't to also have an rc workflow.

Lastly:

Apart of that, do I understand it correctly that the "Publish release" step automatically detects all binary files, bundles them and then publishes them as a tar.gz?

The publish release is only uploading the librum binary, if there is a list of files that you wish to have compressed it's easy to add. You can also add binaries one by one as different downloads, that's up to you.

You should also take a look to branch protection in the repo settings, actions setting to define log and artifact retention (this will affect storage use in your account and additional workflows if there is a upload/download artifact dependency).
And finally, you should take a look at the billing setting to determine how much you want this things to go over the free budget. Runners can also be self-hosted, is a small change in the workflow, it will not consume minutes, but you'll need to manage that.

[DavidLazarescu]

Thanks for the quick response.

So Upload artifact is in place to validate 2 things:

• Name/path don't change between builds
• Allowing individual testing on the binary, after the automation runs

I am not sure if I understand this correctly, what exactly do you mean with "Name/path" and why would it change between builds? Also, ctest, which is invoked by the "test" workflow handles all of the testing, so I do not understand the need for individual testing on a binary.

You need to take into account that uploaded artifacts have a life time (in repo settings), so you should run the release task close to the test

The tag is always coming with the new release, so there should be pretty much no time in between them. The main branch usually gets updated when a new version on dev/develop is ready.

The publish release is only uploading the librum binary, if there is a list of files that you wish to have compressed it's easy to add. You can also add binaries one by one as different downloads, that's up to you.

This is a problem, since the executable file alone won't be of any use since it doesn't run without the needed shared libraries. I suppose I'll need to look into manually adding binaries to the "package" that will be published, right?

[Juanito87]

I am not sure if I understand this correctly, what exactly do you mean with "Name/path" and why would it change between builds? Also, ctest, which is invoked by the "test" workflow handles all of the testing, so I do not understand the need for individual testing on a binary.

Not sure what the coverage for a test is. But validating that name/path is the same, between updates is to validate that file keeps the name and the path were is compiled. It happened to me that some pipelines broke, because the upstream changed the name of the binary (you are the upstream so it shouldn't happen, but I rather be safe than sorry).
Besides that, having a binary at hand means that you can do manual testing of it. Not sure what's your test coverage, but having software compile, and actually fixing a bug or the new function doing what's expected may not be the same.

This is a problem, since the executable file alone won't be of any use since it doesn't run without the needed shared libraries. I suppose I'll need to look into manually adding binaries to the "package" that will be published, right?

If you give me a list of what needs to be packaged, it's easy to add a task that runs tar, and upload the tar file instead of the binary only.

[DavidLazarescu]

I'll be looking into making a list of files needed to run Librum on different Linux distributions.

Once I manage to manually create such package, I will make sure to send it to you so that you are able to see what needs to be released.

[Juanito87]

As a first approach we can do a tar file with all the files in the build-release folder.
You may need to take into account that this workflow is intended to work on ubuntu 22. It may not work on older versions or different distributions (needs to be tested).

[DavidLazarescu]

As a first approach we can do a tar file with all the files in the build-release folder. You may need to take into account that this workflow is intended to work on ubuntu 22. It may not work on older versions or different distributions (needs to be tested).

Working on this rn

[DavidLazarescu]

Just to give you an update, there seems to be a bug (probonopd/linuxdeployqt#592) in linuxdeployqt (the tool needed to create .tar.gzs for qt applications) which is holding me back right now

[Juanito87]

I may be missunderstanding you, but we can use a simple action to create the tar file as needed. Like:

 - name: Compress tools
        run: |
        tar -cvfz librum.tar.bz2 release-build/

And do the rename and upload of this.

[DavidLazarescu]

Sadly this doesn't work, we need to bundle the Qt libraries, plugins and qml stuff as well