I'VE DONE IT!!! What a wild ride. I ended up using the Stored Procedures for things. Going that route did the trick nicely. Though I did have to spend the weekend learning SQL to understand exactly what the hell is going on inside of Stored Procedures haha.

But, I've now got the code I need to go from 0 to a deployed ProGet instance programmatically. Still a bit of polishing left to do, and a whole heck of a lot of testing but I am super excited about this! Thank you very much for the Stored Procedure hint!!! I very much appreciate it.

@atripp said in Manipulate users using pgutil:

tech/marketing partnership

That is above my pay grade as well to iron out he specifics but it is in my wheelhouse to push for it internally :)

@jipianu_mihnea_1277 said in Creating Users with Native API:

ant to use the Native API to create users and groups, but I do not know how to generate the password because I am unaware of th

Thanks for the shout-out @atripp! Yes, you can do Set-ProGetUserPassword -Credential (Get-Credential) and supply the username of the account you with to set the password, as well as the new password.

The New-ProGetUser function will do this internally for you when you pass in the credential object that function expects.

If you run into trouble, please do file an issue so I can try to fix it!

Thanks! I've gone ahead and made it public at https://github.com/steviecoaster/InedoOps. Still have a while before I put it on the Gallery, but I like developing in the open when I can!

I'm laboring on a new PowerShell module I'm tentatively calling InedoOps, which enables an administrator to administer an Inedo ProGet instance via PowerShell. It is shaping up quite nicely, though I've got quite a bit more to do before I would consider it "ready".

Would there be objections to my publishing this to the PowerShell Gallery once I'm done? Right now the code is private on my Github. If any Inedoers want to have a sneak peek, leave your Github username and I'll invite as a contributor, or if you are OK with it being flipped over to public, I can do that and share the link.

I'd really rather like a set of eyes on it from your side so you can see my approach to things and get your blessing on it. Particularly around my use of stored procedures for some things! I'm.....unsure how "stable" those are in terms of them changing in future versions, etc.

I'VE DONE IT!!! What a wild ride. I ended up using the Stored Procedures for things. Going that route did the trick nicely. Though I did have to spend the weekend learning SQL to understand exactly what the hell is going on inside of Stored Procedures haha.

But, I've now got the code I need to go from 0 to a deployed ProGet instance programmatically. Still a bit of polishing left to do, and a whole heck of a lot of testing but I am super excited about this! Thank you very much for the Stored Procedure hint!!! I very much appreciate it.

@atripp said in Manipulate users using pgutil:

tech/marketing partnership

That is above my pay grade as well to iron out he specifics but it is in my wheelhouse to push for it internally :)

My end goal is to either replace Sonatype Nexus with Inedo ProGet or at least allow the choice of repository solution included with one of our canned Environments that we offer customers here at Chocolatey.

Right now we are able to fully provision a Sonatype Nexus server via the API so that the server has

1. The necessary repositories created
2. The necessary scripts/packages stored
3. Security configured on the repositories.

Today I can get ~80% of the way there with Inedo, but until I can lock it down I can't start the work of baking it into our stuff. ProGet is the only repository in our testing that plays very very well with Chocolatey (thanks for that, btw), but without being able to natively do the security bits I'm afraid I can't move forward.

I hear you with the AD thing, but I can't guarantee AD will be available in all the environments we deploy too.

Our goal is to give them a turn-key "thing" they can be up and running with in under an hour and if they need to change things after the fact, they can work with our Support team to make those adjustments. Has worked out fairly well so far!

Are there plans to include the ability to work with user accounts via pgutil? For my use case I would like to be able to programmatically create a user account and assign it a read-only role to a specific feed such that I can configure and consume packages from the restricted feed on an endpoint. Currently there is not a way programmatically (at least that I can get to work) to do this sort of thing programmatically via PowerShell.

I've another thread on the forums which I was pulling on the HTTP api thread, but that led to a dead end as I can't craft appropriate JSON that the endpoint accepts, not for lack of trying haha.

We do have Chocolatey-AU (Automatic Updater) which will keep a version of a package up to date. Once I have everything setup it will look at whatever upstream I point at and keep the package updated for me automatically.

If you wanted to own the automation that's fine with me, but I have no problem with shoving the package source in my Chocolatey package's repository and using a Github Action to keep it updated (this is what I do today with other packages I maintain).

You've got my email, we can take this off the forums and hash out details of things privately if you prefer :)

Thanks, Alex! I have confirmed the request and have added one more person from my team as well so we have double coverage on this package.

As for the delisted packages, they won't show up for others on the community repository or via Chocolatey CLI once they are unlisted, but since you are the owner of those packages, they will continue to display on your profile. So all is right with the world there :)

If you're cool with it I may pick up packaging pgutil as well.

I've reached out via the contact maintainers link on https://community.chocolatey.org/packages/proget but figured I'd post here as well for more visibility. I'd like to publish ProGet as a Chocolatey package. I've got the automation and packaging code working how I expect it should, but I can't publish it as there is already a package available.

While I could publish it under another package id....that seems icky to me so I'd rather be added as a maintainer and then setup a pipeline to keep it updated as you folks release new versions.

Let me know if you have any questions/comments/concerns!