Add a packaging workflow #664

Closed wbqpk3 closed 3 months ago

See the OpenSSF security test (https://github.com/Ericsson/CodeCompass/issues/659).

{
      "details": [
        "Warn: no GitHub/GitLab publishing workflow detected"
      ],
      "score": -1,
      "reason": "no published package detected",
      "name": "Packaging",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/main/docs/checks.md#packaging",
        "short": "Determines if the project is published as a package that others can easily download, install, easily update, and uninstall."
      }
    }

This seems to be a false positive detection, as we have packaging workflow to DockerHub, the OpenSSF tool is simply not capable to recognize it, as mentioned in its description.

Refactoring the workflow to use e.g. the docker/build-push-action instead of the native Docker CLI commands could help OpenSSF to recognize it, if we would like to do that.

We can also support other packaging formats, for example building a .deb package which is simple to install. I might look into this in the future. It's also related to an older issue: https://github.com/Ericsson/CodeCompass/issues/478

@wbqpk3 Yes, the conclusion there was to either support Snap and / or AppImage. Snap is widely used and even preinstalled in many Linux distributions. AppImage does not require sudo permissions on the other hand.

I would still suggest to go this way, as with these tools we could reach much greater OS distribution coverage compared to creating a DEB package.

Yes, Snaps can cover many more distributions. What I'm not sure about is their speed and efficiency compared to DEB packages built for a specific platform (e.g. Ubuntu). Anyway, I will also consider Snaps as well. If we can support more formats, the better.

I will close this as a duplicate, as for binary release packaging, we already had an issue (#478).

Ericsson / CodeCompass

Add a packaging workflow #664