Extract manifest-schema and publish to crates-io

[NobodyXu]

Motivation:

In cargo-bins/cargo-binstall#1720, I'd like to speedup cargo-binstall, by using the template recorded in taiki-e/install-action while utilise the checksum to validate the artifacts.

I've extracted all manifests I need into a crate named install-action-manifest-schema so that it could be publish it to crates-io

[taiki-e]

Could you tell us how specifically you plan to embed this into binstall?

For example, if binstall refers to it by tag or rev, no problem, but otherwise maybe versioning or stabilizing our manifest format foever is needed.

[NobodyXu]

Could you tell us how specifically you plan to embed this into binstall?

I plan to issue a GET request, to get the raw JSON from the repository, since I don't want to create new release of cargo-bindtall too frequently

For example, if binstall refers to it by tag or rev, no problem, but otherwise maybe versioning or stabilizing our manifest format foever is needed.

Yeah having a branch for cargo-binstall would be great, but it'd be also fine without it.

I don't think the format will change very often, and I plan to use the manifest as a best-effort, though having it in a separate branch would be great.

[NobodyXu]

cc @taiki-e would that work for you?

[NobodyXu]

@taiki-e Friendly ping on this PR for it has been stale for days.

[taiki-e]

To be honest, I'm not much in favor of merging as is, as I expect that people will eventually require that checksum verification be done for supported tools reliably.

What I think is right here is to provide a versioned manifest from the beginning.

The idea I'm currently considering is as follows:

• Create branches for manifest-schema.
  • The format of the branch would be something like manifest-schema-<major_and_minor_version_of_install_action_manifest_schema_crate>.
• When a new version of install-action is released, the release script will also update the corresponding manifest-schema- branch based on the current install-action-manifest-schema crate version.
  • This means that the manifest-schema- branch will contain the latest released manifest that uses a compatible format.
  • Also, if there are breaking changes to manifest format, we must publish a new version of the crate first.
• install-action-manifest-schema crate provides a constant indicating the name of the corresponding manifest-schema- branch based on the current version of that crate.
  • Users (binstall) can use it like format!("https://.../{}/...", install_action_manifest_schema::BRANCH_NAME)

Thoughts?

---

P.S.

Friendly ping on this PR for it has been stale for days.

In general, I don't recommend pinging at intervals shorter than a week in OSS. I understand your feeling that you want the PRs to merge as soon as possible, but the maintainers have lives of their own and are not always able to be involved in OSS as often.

"a week" is what I have said in another place before, and also a guide to new contributors in LLVM recommends the same interval.

The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

[NobodyXu]

In general that looks pretty good to me.

I think that we only need the major version in the branch name, i.e. manifest-schema-1

The reason is that, older version of cargo-binstall might still uses older version of manifest-schema.

As long as it's compatible (adding new field), I think it's probably ok.

---

I'm sorry for the pinging, I would refrain from pinging afterwards unless it's longer than 8 days.

[taiki-e]

I think that we only need the major version in the branch name, i.e. manifest-schema-1

I said major_and_minor_version because I was speaking under the assumption that the major version of the install-action-manifest-schema crate would be 0 forever, but if the major version is 1 or higher, indeed the major version alone would be sufficient.

As long as it's compatible (adding new field), I think it's probably ok.

Agreed.

[NobodyXu]

Added a new GHA workflow for the synchronisation, and added a new constant to the manifest-schema crate for the branch name.

[NobodyXu]

cc @taiki-e pinging as this PR has been stale for 9 days

I've added the workflow required to sync the manifest to the manifest branch, triggered when pushed to main

[taiki-e]

I would not prefer to do this on every push. An unreleased code may contain broken changes.

[NobodyXu]

I changed it to run on release (pre-release/draft should be ignored)

[taiki-e]

This is very fragile. Any of the following cases break this script:

• manifest-schema has non-zero patch version
• dependency is <name> = { version = "..", .. } form
• dependency is [dependencies.<name>] form

The most robust way would be to use cargo-metadata and cargo-locate-project (tools/tidy.sh has code that does such a thing), but a simple approach such as to use a marker to identify the lines we want to reference (like this) would be fine.

[NobodyXu]

I replaced this with cargo-metadata and jq, I believe that's the most robust one without having to install third-party tool.

[taiki-e]

Thanks.

without having to install third-party tool.

(Just in case: cargo locate-project is not a third-party tool.)

[NobodyXu]

Thanks, TIL

[taiki-e]

tidy failures seem to be genuine except for file-permissions-check.

[NobodyXu]

tidy failures seem to be genuine except for file-permissions-check.

Hmmm how do I fix it?

I took a look at its err msg and didn't get how to fix it

[NobodyXu]

Oh i get it now, last time I looked at it I was confused

[NobodyXu]

I've managed to fix all other errors, but I don't know how to fix this one:

https://github.com/taiki-e/install-action/actions/runs/11346131368/job/31554551380?pr=657#step:10:42

info: checking public crates don't contain executables and binaries
Error: file-permissions-check failed: executables are only allowed to be present in directories that are excluded from crates.io
=======================================
main.sh
=======================================