-
Notifications
You must be signed in to change notification settings - Fork 728
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
Move dev packages from myget to github packages #4440
Comments
FYI, I just migrated Quartz.NET to feedz.io, which supports anonymous feeds and has Open Source billing plan (5GB storage instead of free plans 2GB). The management portal supports organizations and repositories under then, also team members with different permissions. |
There's a link in the README that we should update with the new location for these: https://github.com/nunit/nunit/blob/master/README.md?plain=1#L19 |
We use github packages for work: Push as:
Use as (nuget.config):
I don't know if user needs a password for a public repository.
Where the GLOBAL_READ_PACKAGES_SECRET is set by our enterprise admins. The github documentation suggests it is not needed. I guess I can create a build that pushes the package to github and then I can check if I can use it from home. |
@OsirisTerje Do we want to push every successful master build as a nuget package or manually on a tag? |
GitHub packages always requires API key, even for consumption. This is why I chose feedz.io to get friendlier usage experience (public feed not requiring auth). |
This has been the way we have been doing it, so for the DEV builds, I think we should continue this practice. However, we should get GitVersion in at some time, @CharliePoole use it on the console/engine project, and I have been using it a lot in work. When we have that, we can use tags to push to nuget.org for alpha, beta and prod versions. |
About the needed authentication for consuming github packages that @lahma mentions, I agree that is not so user friendly. It seems to be confirmed by the github docs too. (Cool @manfred-brands if you actually test it) I think we either way still should push to github packages, but we could also push to something else, like feedz.io or any other alternative feed that is in fashion at the given time. And myget seems to be up again, but we could either move completely off it, or using that also as an alternative feed could be ok. But this deployment action should run when the master is updated but not block any PRs. |
I set up a separate manual workflow ( This way I can merge my features to main and have clean release labels on main but only publish at my discretion. Version number is maintained in the csproj file. Just another option. |
@manfred-brands @lahma @stevenaw Since myget is up again, should we just postpone this ? |
Yes. There were permission issues. |
We turned off publishing to myget from appveyor in https://github.com/nunit/nunit/pull/4441/files I think this means we don't currently publish dev packages from CI. Should we add myget to the current pipeline until the GitHub side gets sorted? |
I believe the appveyor build was killed (and should stay so imho). But, we could just create a separate action for publishing to myget, which only trigger on master/main. |
We have a new action flow to push to myget, and we have a draft PR to push to github package repo, so closing this. |
Ref the outage yesterday. Myget seems to be gone:
https://www.reddit.com/r/dotnet/comments/159yigd/is_myget_gone_for_good/
MyGet/MyGetDocs#143
The text was updated successfully, but these errors were encountered: