packets_creation: add the icub packet creation via gh action

[Nicogene]

This PR adds the creation of the icub packet via gh action

See https://github.com/Nicogene/icub-main/actions/runs/463171210 for reference and here the deb uploaded

[pattacini]

Nice addition @Nicogene 👍🏻

I've got a few points to address.

[pattacini]

Another problem I can see is that we tend to modify the release tag a few times before carving it on the stone to fix some last minutes mistakes. Therefore, I'd avoid triggering the action upon the creation of just the tag.

Instead, I'd go for one of the following options:

1. Trigger upon manual creation of the release.
2. Make the job manual using the workflow_dispatch event.

cc @traversaro @Nicogene

[traversaro]

Another problem I can see is that we tend to modify the release tag a few times before carving it on the stone to fix some last minutes mistakes.

No directly related to this PR, but I guess this is an residual related to when releases were "expensive". If the release process is completely automated, there is nothing particularly problematic in quickly releasing small patch releases that fix small bugs or problems.

Instead, I'd go for one of the following options:

1. Trigger upon manual creation of the release.

2. Make the job manual using the `workflow_dispatch` event.

cc @traversaro @Nicogene

The problem of using workflow_dispatch is that then you are executing the code on a given branch, that may be different from the code that was tagged in the release. The release event offers a lot of activity types (see https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#release) that I think can be used in this case.

[traversaro]

I think it is still necessary for:

• Do not generate non-relocatable files in yarp_configure_plugins_installation yarp#2445
• Add CMake option to force installation of path.d-related files in yarp_configure_external_installation yarp#2444

[pattacini]

No directly related to this PR, but I guess this is an residual related to when releases were "expensive". If the release process is completely automated, there is nothing particularly problematic in quickly releasing small patch releases that fix small bugs or problems.

I didn't explain exactly what I meant. In the recent past, @Nicogene can confirm, we tagged the master and then craft the releases a few days afterward. In the time between, it (rarely) happened that the same tag was deleted and updated before announcing the "real" (corresponding) release. That's the point why I'm not really confident in triggering this workflow upon the creation of the tag but rather upon the creation of the actual release (and I'm pretty sure we can do that).

Generally speaking, I concur with you @traversaro that once we release a piece of software we can then easily fix possible bugs with subsequent patches, especially when the process is almost fully automatized.

That said, option 1 (triggering upon releases rather than tag) is obviously preferable over option 2 - which by the way I meant to be using at the very same time when the release is ready, although it's certainly not an atomic operation.

[Nicogene]

Update

@pattacini now the action is triggered by the creation of a new release 👍🏻
@traversaro the action uses now only docker, the yml is more slim 👍🏻

See https://github.com/Nicogene/icub-main/actions/runs/469222425 for reference and the relative release https://github.com/Nicogene/icub-main/releases/tag/v1.0.57