Have you tried our new MyGet Credential Provider for Visual Studio 2017 yet? http://docs.myget.org/docs/reference/credential-provider-for-visual-studio
We are working on improving that very experience, so we’re very eager to hear your feedback on this.
Interesting. In essence, are you suggesting MyGet Enterprise administrators should have the ability to restrict token creation to certain specific users, and disable by default for any other user (including those who still need to create their account on your tenant)? Those users essentially become read-only users in that case.
We are thinking of making API keys “scoped”, so that you can create an API key that, for example, can only consome and/or push to a given feed. Would that work?
Keeping this issue open for further improvements.
In that case an Enterprise admin can take ownership of the feed. Or you can create a separate user for it and have that user own the feed instead (not linked to a person).
Currently you an assign more than one API key to a user. The Octopus Deploy server could use a user's username and a secondary API key as the password. Would that work?
We want to support this but we're a bit in doubt as to whether this should be a separate user or an existing one with different credentials.
Would you want live output, or do the colored logs we currently have suffice?
This is on our roadmap. Would this be something you’d like to see for Enterprise plan only or all plans (like Starter and Pro?)
Currently supported in MyGet Enterprise (federated identity)
Definitely on our radar, thanks for the suggestion!
We’re working on this continuously :-)
Thanks David! It's always great to hear this :-)
Not yet, we definitely want to add this but priority-wise there are more urgent things to tackle.
@James please get in touch with support, we may be able to help out
It's on our radar. We're currently doing a lot of back-end changes to support building an API. No ETA yet but it's high on our list :-)
We’re currently awaiting a RC for vNext so we can run builds of this type. Ideally, would you like us to run kpm pack? Or just make available kpm so you can run a build.bat which does npm, grunt and kpm pack in the end? Trying to figure out the most enjoyable workflow that makes it both generic enough for 90% of builds to always succeed by convention.
We have a clear idea of where we want to go with this. With a custom build script / SAKE builds, KPM builds fine. Once released we want to add a convention-based build for KPM.
We're currently awaiting a RC for vNext so we can run builds of this type. Ideally, would you like us to run kpm pack? Or just make available kpm so you can run a build.bat which does npm, grunt and kpm pack in the end? Trying to figure out the most enjoyable workflow that makes it both generic enough for 90% of builds to always succeed by convention.
This would only work within one feed. Since we have no way of knowing other package sources "out there", this is a difficult metric. If "within one feed" is good enough, this should not be too hard for us to add :-)
Do you have any specific requests you would like to see added?
Would it make sense to make this a MyGet system user instead? The reason is some users may not have permission to add packages to a feed and it would be confusing to see they actually added a package this way.
That sounds really good
An API is in the works, planned for early 2014. This would make the senario you are desribing possible. Stay tuned!