-
-
Notifications
You must be signed in to change notification settings - Fork 34
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
base: main
Are you sure you want to change the base?
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 |
.github/workflows/manifest_sync.yml
Outdated
workflow_call: | ||
push: | ||
branches: | ||
- main |
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.
I would not prefer to do this on every push. An unreleased code may contain broken changes.
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.
I changed it to run on release (pre-release/draft should be ignored)
|
||
cd "$(dirname "$0")" | ||
|
||
schema_version="$(grep 'version = "0.*.0"' ./manifest-schema/Cargo.toml | cut -d '.' -f 2)" |
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.
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.
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.
I replaced this with cargo-metadata
and jq
, I believe that's the most robust one without having to install third-party tool.
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.
Thanks.
without having to install third-party tool.
(Just in case: cargo locate-project
is not a third-party tool.)
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.
Thanks, TIL
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:
|
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? |
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 taiki-e-install-action-manifest-schema so that it could be publish it to crates-io
Signed-off-by: Jiahao XU <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
Set username and user email before committing. Signed-off-by: Jiahao XU <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
Co-authored-by: Taiki Endo <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
Co-authored-by: Taiki Endo <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
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). |
Signed-off-by: Jiahao XU <[email protected]>
Signed-off-by: Jiahao XU <[email protected]>
I have fixed the |
cc @taiki-e can you please review this PR? The CI is green now |
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 [email protected]
Co-authored-by: Taiki Endo [email protected]