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

[ERROR] ReleaseError: No asset found for target: x86_64-unknown-linux-gnu #52

Open
tjyang opened this issue Jun 13, 2020 · 6 comments
Open

Comments

@tjyang
Copy link

tjyang commented Jun 13, 2020

Hi

I am pretty new to rust, trying to learn more. This error smell like "nightly" component issue, right ?

[x220@ipa01 rustgb_self_update]$ cat /etc/redhat-release && cargo --version
Fedora release 32 (Thirty Two)
cargo 1.40.0 (bc8e4c8be 2019-11-22)
[x220@ipa01 rustgb_self_update]$
  • steps to re-produce issue.
[x220@ipa01 rustgb_self_update]$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
     Running `target/debug/ghupdate01`
found releases:
[
    Release {
        name: "0.1",
        version: "0.1",
        date: "2020-06-13T16:53:28Z",
        body: Some(
            "Starting from 0.1",
        ),
        assets: [],
    },
]

Checking target-arch... x86_64-unknown-linux-gnu
Checking current version... v0.1.0
Looking for tag: 0.1
[ERROR] ReleaseError: No asset found for target: `x86_64-unknown-linux-gnu`
[x220@ipa01 rustgb_self_update]$ pwd
/home/x220/rustgb_self_update
[x220@ipa01 rustgb_self_update]$ cat src/gh-selfupdate.rs
/*!
Example updating an executable to the latest version released via GitHub
*/

// For the `cargo_crate_version!` macro
#[macro_use]
extern crate self_update;

fn run() -> Result<(), Box<dyn ::std::error::Error>> {
    let releases = self_update::backends::github::ReleaseList::configure()
        .repo_owner("tjyang")
        .repo_name("rustgb_self_update")
        .build()?
        .fetch()?;
    println!("found releases:");
    println!("{:#?}\n", releases);

    let status = self_update::backends::github::Update::configure()
        .repo_owner("tjyang")
        .repo_name("rustgb_self_update")
        .bin_name("ghupdate01")
        .show_download_progress(true)
        //.target_version_tag("v9.9.9")
        .target_version_tag("0.1")
        //.show_output(false)
        //.no_confirm(true)
        //
        // For private repos, you will need to provide a GitHub auth token
        // **Make sure not to bake the token into your app**; it is recommended
        // you obtain it via another mechanism, such as environment variables
        // or prompting the user for input
        //.auth_token(env!("DOWNLOAD_AUTH_TOKEN"))
        .current_version(cargo_crate_version!())
        .build()?
        .update()?;
    println!("Update status: `{}`!", status.version());
    Ok(())
}

pub fn main() {
    if let Err(e) = run() {
        println!("[ERROR] {}", e);
        ::std::process::exit(1);
    }
}
[x220@ipa01 rustgb_self_update]$

@mainrs
Copy link
Contributor

mainrs commented Jul 24, 2020

This might be due to the fact that your tag is not newer than the version you hav ein your cargo file. They are the same (from semver’s POV).

Change the version inside your cargo toml to 0.0.1 for example. That way the version on github release is newer than the one you run

@tjyang
Copy link
Author

tjyang commented Jul 24, 2020

@sirwindfield , Thanks for the pointer. Quick 30 minutes test still not successful. But I will keep trying. Need to learn more about git tagging also.

@jaemk
Copy link
Owner

jaemk commented Jul 25, 2020

@tjyang I think the issue is that your github releases (https://github.com/tjyang/rustgb_self_update/releases) are missing the expected assets. The example releases here (https://github.com/jaemk/self_update/releases) have assets named by the arch they are intended for. The self_update github logic is looking for an asset with x86_64-unknown-linux-gnu in the name, but there are no assets other than the default source code

@mainrs
Copy link
Contributor

mainrs commented Jul 25, 2020

haha I didn't even see that yesterday. Maybe I'm turning blind at this point...

@CPerezz
Copy link

CPerezz commented Aug 22, 2020

I had exactly the same problem.
Probably if there's no release that matches with the current target, it should just take the released package directly and try to build it.

@mainrs
Copy link
Contributor

mainrs commented Aug 22, 2020

The thing is the target machine might not have the whole toolchain installed. Maybe this could be a yes/no question.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants