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

Publishing crates to custom registry are "not eligible for publishing" #18

Open
MarijnS95 opened this issue May 1, 2024 · 4 comments · May be fixed by #19
Open

Publishing crates to custom registry are "not eligible for publishing" #18

MarijnS95 opened this issue May 1, 2024 · 4 comments · May be fixed by #19

Comments

@MarijnS95
Copy link

Hi! I've got a workspace setup where we use the [package] publish field to limit which registries that crate can be published to (an array of just one item).

Unfortunately when running cargo smart-release --dry-run-cargo-publish or even cargo smart-release --registry that-registry --dry-run-cargo-publish, the following error shows up:

Error: No provided crate is actually eligible for publishing. Use --verbose to see the release plan nonetheless.

Is cargo-smart-release not understanding that publish attribute? Let me know how I can continue to debug this :)

@MarijnS95
Copy link
Author

For completeness, I just tried without the commit that adds the publish field to all our crates. In detached head mode, it's not happy:

$ cargo smart-release --registry that-registry --dry-run-cargo-publish
[WARN ] Consider running with --update-crates-index to assure bumping on demand uses the latest information
thread 'main' panicked at /home/marijn/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cargo-smart-release-0.21.3/src/git/history.rs:40:40:
internal error: entered unreachable code: handled above
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Checking out a branch to circumvent that error, the dry-run logs show up but unfortunately without any hint whether --registry is picked up correctly and pushing to the right place.

@MarijnS95
Copy link
Author

MarijnS95 commented May 1, 2024

Found what's happening: for some reason PublishDisabledInManifest isn't printed nicely in the logs. But following the code trail:

mode: if package_may_be_published(package) {
dependency::Mode::ToBePublished {
adjustment: VersionAdjustment::Changed {
change: user_package_change,
bump: version::bump_package(package, ctx, bump_when_needed)?,
},
}
} else {
dependency::Mode::NotForPublishing {
reason: dependency::NoPublishReason::PublishDisabledInManifest,
adjustment: None,
}
},

fn package_may_be_published(p: &Package) -> bool {
p.publish.is_none()
}

This should check if the selected registry is set.

@Byron
Copy link
Owner

Byron commented May 1, 2024

Custom registries aren't what I had in mind when writing this program, hence it's very unsupported.

New features can be added by the community, but as can be followed-up on in this PR the process for getting them merged is so special that it might be easier to look for other tools or combinations of tools.

@MarijnS95
Copy link
Author

@Byron thanks! I've already written up a patch but have yet to test it, was about to send you a pull request to get the ball rolling. Looks like we'll have to write some tests which is good, after first discussing what the right thing to do is. Let's leave that for the PR context.

Perhaps this --registry cmdline argument isn't really playing ball with publish = ["specific-registry"] and/or [registry] default = "..." in .cargo/config.toml, but cargo publish has it as well so we can figure something out.

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

Successfully merging a pull request may close this issue.

2 participants