-
Notifications
You must be signed in to change notification settings - Fork 90
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
Target Orchard Core 1.8 in packages (OCC-252) #449
Comments
I've tried to push a prerelease package and the publish-nuget failed failed with "Forbidden" API response |
Since it was updated a year ago, almost certainly that's the case. Since I (and Benedek too) am a co-admin of the Orchard org, I could add the LombiqBot user as a collaborator, and create an API key under it just for pushing OCC packages. Updated, now it should work. We'll also keep this up-to-date from now on. BTW for prereleases we have Cloudsmith, no? |
Not a year ago, just two months. We had a NuGet release (2.0.0) in March. It worked fine then. Cloudsmith is only configured for automatic releases, iirc I can't manually create one there. I need to verify that the dependencies are on the correct version in the NuGet publish before making the 2.1.0 release. |
I mean, the NuGet key (its GitHub secret) was updated a year ago. Cloudsmith publishes also run on preview tags: https://github.com/OrchardCMS/OrchardCore.Commerce/blob/main/.github/workflows/publish-cloudsmith.yml#L8 |
Okay, I've checked the resulting nuspec file from the cloudsmith publish and they indeed use OC 1.8.0 so this is good. |
I still can't publish to NuGet, now trying to push tag
|
Hehh, I misconfigured the key so it matched all OCC packages except for BTW there's also this error:
|
I think that's only because |
Yeah, most possibly. |
Is your feature request related to a problem? Please describe
Consumer projects of OCC are currently forced to target OC 1.8.3 at least, since that's what the packages depend on. Better would be to target the .0 minor version of the latest version; i.e., 1.8.0 currently, so people can use them regardless of the consumer projects being on 1.8.0, 1.8.1, 1.8.2, or 1.8.3. We started this discussion here: #435 (comment).
This won't work though without us disabling or changing .NET consolidation verification in the build workflow.
Describe the solution you'd like
Describe alternatives you've considered
Disabling .NET consolidation verification, but that opens up another can of worms.
Jira issue
The text was updated successfully, but these errors were encountered: