Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a packaging workflow #664

Closed
wbqpk3 opened this issue Nov 6, 2023 · 5 comments
Closed

Add a packaging workflow #664

wbqpk3 opened this issue Nov 6, 2023 · 5 comments
Labels
Status: Duplicate 👥 Target: Developer environment Developer environment issues consist of CodeCompass or 3rd-party build tooling, configuration or CI.

Comments

@wbqpk3
Copy link
Collaborator

wbqpk3 commented Nov 6, 2023

See the OpenSSF security test (#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."
      }
    }
@mcserep mcserep added the Target: Developer environment Developer environment issues consist of CodeCompass or 3rd-party build tooling, configuration or CI. label Nov 8, 2023
@mcserep
Copy link
Collaborator

mcserep commented Nov 8, 2023

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.

@wbqpk3
Copy link
Collaborator Author

wbqpk3 commented Nov 10, 2023

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: #478

@mcserep
Copy link
Collaborator

mcserep commented Nov 10, 2023

@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.

@wbqpk3
Copy link
Collaborator Author

wbqpk3 commented Nov 10, 2023

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.

@mcserep
Copy link
Collaborator

mcserep commented Mar 8, 2024

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

@mcserep mcserep closed this as not planned Won't fix, can't repro, duplicate, stale Mar 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Duplicate 👥 Target: Developer environment Developer environment issues consist of CodeCompass or 3rd-party build tooling, configuration or CI.
Projects
None yet
Development

No branches or pull requests

2 participants