- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 35
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
Extract install-action-manifest-schema and publish to crates-io #657
Conversation
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. |
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
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. |
cc @taiki-e would that work for you? |
@taiki-e Friendly ping on this PR for it has been stale for days. |
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:
Thoughts? P.S.
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.
|
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. |
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.
Agreed. |
f9fda5b
to
97512de
Compare
Added a new GHA workflow for the synchronisation, and added a new constant to the manifest-schema crate for the branch name. |
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 |
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 |
Oh i get it now, last time I looked at it I was confused |
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
|
cc @taiki-e needs some help with this error, since I didn't touch Tried putting exclude into the new crate I created but doesn't help. |
As I said above (#657 (comment)), that is spurious. It is still a marge blocker, but it is not your fault. |
cc @taiki-e how shall we proceed from here? Maybe you can force merge it, if only the merge commit for this PR will fail and others will continue to work? |
d38bc38
to
c270e26
Compare
Rebased and resolved merge conflicts |
I don't think there is any other way than to adjust the tidy script (tools/tidy.sh). |
I have fixed the |
cc @taiki-e can you please review this PR? The CI is green now |
Use branch name `manifest-schema-<major>.<minor>` until manifest-schema crate become 1.x
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for working on this @NobodyXu!
|
The workflow was not triggered after all (probably because an event triggered using GITHUB_TOKEN (“release” in this case) cannot trigger an action), so I removed it and changed it to run as part of the |
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
Also:
Signed-off-by: Jiahao XU Jiahao_XU@outlook.com
Co-authored-by: Taiki Endo te316e89@gmail.com