publiccode-parser-action@v1 very reliant upon GitHub

[ericherman]

A pull request was opened on the Standard for Public Code repository to ci: add publiccode.yml validation workflow.

The overall idea of adding machine validation checking to the development process is good.

At the time of writing, the approach in the pull request does not focus on developers doing so on their machines before pushing, but rather depends upon using GitHub's infrastructure.

Further, when one looks into the implementation, we see it seems to fetch a script from the head of a branch rather than a specific hash, which invites additional uncertainty.

If the standard-for-public-code adds automatic publiccode.yml validation (which I think would be a good idea), I expect it would be along the lines of:

0. brief documentation about script dependencies in CONTRIBUTING or similar and instruction to run the script locally
1. the script which runs the check (after checking for dependencies in the $PATH)
2. a workflow which installs specific versions of dependencies and then runs that script

What do other publiccode.yml community members think about these things?

Is there a sense of how much these aspects contribute to lower adoption or slower adoption of the action in repositories?

And what is the guidance for local developers and communities using other git hosting platforms?

[bfabio]

Hi @ericherman

A pull request was opened on the Standard for Public Code repository to ci: add publiccode.yml validation workflow.

The overall idea of adding machine validation checking to the development process is good.

At the time of writing, the approach in the pull request does not focus on developers doing so on their machines before pushing, but rather depends upon using GitHub's infrastructure.

Yeah, makes sense. That PR is about using publiccode-parser-action in GitHub Actions, so it’s not meant to cover the local workflow before pushing. It's a GitHub Action, it naturally depends on GitHub's infrastructure.

It's also worth noting that it uses the official parser.

And if someone wants to run it locally or with different platforms, there are plenty of ways:

• directly via CLI (go install or prebuilt binaries)
• with Docker
• with GitLab https://github.com/italia/publiccode-parser-gitlab-ci
• or even integrated in git hooks

see the options here: https://github.com/italia/publiccode-parser-go. Of course they all depend on the maintainers' preference and/or the specific project policy.

Further, when one looks into the implementation, we see it seems to fetch a script from the head of a branch rather than a specific hash, which invites additional uncertainty.

Good catch, that would indeed be a nice improvement for the Action. Feel free to open an issue on the repo so we can track it.
Note: that bit is for reviewdog, which handles posting comments directly on the PR. It's not about the parser itself.

What do other publiccode.yml community members think about these things?

Is there a sense of how much these aspects contribute to lower adoption or slower adoption of the action in repositories?

And what is the guidance for local developers and communities using other git hosting platforms?

I'd suggest to use the CLI or the official Docker image. Both are easy to integrate into whatever pipeline they're running on their platform of choice. They can also release their own platform-specific integration built on top of those

[ericherman]

Further, when one looks into the implementation, we see it seems to fetch a script from the head of a branch rather than a specific hash, which invites additional uncertainty.

Good catch, that would indeed be a nice improvement for the Action. Feel free to open an issue on the repo so we can track it. Note: that bit is for reviewdog, which handles posting comments directly on the PR. It's not about the parser itself.

Done: italia/publiccode-parser-action#25