@apxltd At the moment we only have five I think. The adoption rate of it has been slow due to the SCA feature being very interesting but lacking the presentation of some valuable information, such as what this thread addresses. Once the adoption grows with increased information connectivity (builds with the associated packages for instance and this license component) we would likely have more than 300 or 400 build projects.
Posts made by davidroberts63
-
RE: License Usage Overview - Non-compliant Licenses in Use
-
RE: License Usage Overview - Non-compliant Licenses in Use
I would like to add my support for that UI for viewing the Active Builds Using "[license]" and Packages Using "[license]". The recommendation of allowing to sort by the package or the project name would be very helpful. I was looking for this exact view in Proget (2024.12) for the past few days as we have a similar situation.
Also, on the builds page, I'd recommend having a sort and/or filter ability for the Stage. We may want to review production stages as a priority and then the rest as a secondary effort. Filtering or at least sorting would greatly assist in focusing our efforts.
Does there happen to be a PG tracking number that we could follow to be aware when it gets released?
-
RE: ProGet product version api
@stevedennis This is perfect. I greatly appreciate this, Steve.
-
ProGet product version api
Is there an api call that would return the current version of ProGet I'm running? And is there an api call against indeo.com that would return the available versions and their release date?
I'm looking to build a self-updating dashboard of our pipeline tools. To help us stay on track with what version is in live use and staging, versus the lastest available and how old each are.
-
RE: Assets folder upload being denied
Haha, I missed it by one minor verison. :-D
Sounds good. Thanks for the quick response. Means I get to test my scripted upgrade process. :-D
Have a good one.
-
Assets folder upload being denied
We have an assets folder with an LDAP group assigned 'NuGet Uploaders' permissions. The users can create directories but get the following exception message immediately when clicking 'Add Assets':
Inedo.ProGet.WebApplication.SecuredTaskDeniedException: [USERNAME-HERE] is not permitted to perform the Feeds_AddPackage task for the current scope.
I've also tried granting the users all permissions except administrator as well as assigning the individual them-self as opposed to a group. But neither approach seem to allow the user to upload a file. I, as the proget administrator, can successfully upload a file to the asset directory. I've checked the tasks given the various permissions I've tried. 'Add Packages' is part of the permissions involved.
Are there any recomendations on how to get the user the ability to upload a file to the asset directory?
Product: ProGet
Version: 4.8.2 -
RE: Windows Authentication but not on Feeds
Somewhat similar to the post you've read already, but I've provided an answer to this kind of problem before:
https://inedo.com/support/questions/7990
Basically it's setting up two IIS sites, one with Windows auth the other with Basic Auth (or anonymous if you want). One instance of ProGet, but two ways to get to it.
We've been successfully using ProGet with both Windows Auth (for .NET nugets) and Basic Auth (for npm and docker) for about a year now, with the configuration described in the post I referenced.
David
-
RE: Proget feed access for anonymous not working
Jon I've run into the same issue before dealing with the npm feeds. I ended up hosting the proget site twice in IIS under different hostnames.
In IIS we have two websites:
- Windows Auth enabled
- Forms Auth disabled
- Anonymous Auth disabled
formsauth-proget.mycompany.com
- Anonymous Auth enabled
Both sites use the same physical path of your proget installation. The host name in the binding must be different though. That is so IIS knows which way to go, the website with Windows auth or the site with the anonymous auth.
We've been using this for several months with no problems. I hope it helps in your situation.
Please note, I do not work for ProGet, I'm a fellow customer offering assistance.
-
RE: Trying to switch to Active Directory fails
Gordon,
Have you made any changes to the web.config in the Proget website? Also, can you go through some of the IIS settings as well? Version of IIS, authentication modes that are enabled. Also, take a look at the providers for 'Windows Authentication' and what does that list look like?
I did a little digging and found a somewhat similar situation on a completely different product (SiteFinity). In that forum discussion there is talk about changes in the web.config causing the issue. Thus why I'm asking about what your proget installation web.config looks like.
Please note, I do not work for ProGet, I'm a fellow customer offering assistance.
-
RE: ProGet Support of NuGet V3 Feed
I'm not sure if you can use the V3 url in a ProGet connector. I believe I've tried and it wouldn't' work. I defer to ProGet employee's to confirm that.
However, that won't affect your developers using VS 2017. They can connect to ProGet with the url that you provided earlier and they will see the same results. I have about 80 developers across VS 2013, VS 2015 and VS 2017 all using the same ProGet url, and all are working fine with the nuget.org connector in ProGet.
Please note, I do not work for ProGet. I'm a fellow customer offering assistance.
-
RE: Uploading packages from jenkins to ProGet
As an alternative choice you can use Powershell for this. Add a 'Windows Powershell' step (be sure to install that Jenkins plugin first):
DIR -Recurse -File -Filter "*.nupkg" | @{
& nuget.exe push $_.FullName -Source https://urltoyourproget/nuget/feedname
}You will also need to ensure you have the nuget.exe command line executable available to the Jenkins node running.
Please note, I do not work for ProGet, I'm a fellow customer offering assistance.
-
RE: Permission for 'Assign License' in tasks
You are correct, the 'NuGet Uploaders' task is a custom one I made, it's been a while since I did that and did not immediately recall it as such.
That said, our use case is that the one administrating ProGet (myself and a few others) define what licenses are allowed in a separate feed. We have a set of developer architects that are responsible for reviewing which packages get put into the feed. Some of the packages they appropriately want to upload to the feed have an 'unknown' license. The dev arch then looks into the package and sees the url pointing to what reads as a particular license (likely a file in the project github repo). They would assign it correctly.
We would watch the new url license assignments and verify (trust but verify) ourselves outside of that process to allow them to move forward. Below is a workflow of what we have setup:
Arch upload -> import-nuget-feed -> assign license -> arch promote -> approved-nuget-feed
- Arch has upload access to the import-nuget-feed
- Arch only has promote access to approved-nuget-feed
- approved-nuget-feed has license restrictions on it
- Arch would assign license of the package while in the import-nuget-feed
- Devs use approved-nuget-feed for development
The archs would not need proget administrative rights, because they are not administrating the running and operations of Proget, just the content within it.
I hope that makes sense. I appreciate your time in this.
-
Permission for 'Assign License' in tasks
What permissions are required for a group/user to be able to 'Assign License' to a package that has an 'Unknown' license in the nuget/node package in a specific feed?
I am logged in as an Administrator and see the 'Assign License'. However when I give someone the 'NuGet Uploaders' task they don't see the 'Assign License' button. I also added the 'Manage Feed' permission to the 'NuGet Uploaders' task to see if that would work but it did not provide that button to the user.
Product: ProGet
Version: 4.8.2 -
RE: Where did the security 'scope' go?
Wonderful!
Worked just as you said it would. Thank you very much Alana.
-
RE: Where did the security 'scope' go?
I can understand what you are saying regarding 'system level' tasks. However, I'm not trying to scope a system level task.
In my original question you may note I'm trying to scope 'Download & View'. Which upon looking into the 'Cusomize Tasks' as you mention (thank you for pointing that out to me, very handy), the 'Download & View' has 'Download Feed' and 'View Feed' only. And both of those have the 'F' marker denoting that it can be scoped to a feed. Yet, my display shows 'n/a' still.
Am I doing something else wrong?
-
RE: How do I exclude pre-release nugets in the connectors?
I will definitely look into the extension documentation. Thank you for mentioning it.
But, you're saying this won't work?
https://www.nuget.org/api/v2/Packages()?$filter=IsPrerelease%20eq%20true&$top=10
I imagine I'm misunderstanding something you said, or there maybe something else I'm not aware of when querying nuget.org.
-
Where did the security 'scope' go?
Upgraded from 3.8.1 to 4.8.2.
Now in 'Tasks' I see 'Scope' set to 'n/a' on most of our assignments. We have the same groups granted permissions to multiple (but not all) feeds. How can I now see the details of these permissions?
Example of how it looks:
Task :: Scope :: Users & Groups Download & View :: n/a :: AllDevelopers, AllDevelopers, Vendors, LicenseRequired, LicenseRequired
Example of how I'm expecting it to look:
Task :: Scope :: Users & Groups Download & View :: ApprovedNugets :: AllDevelopers, Vendors, LicenseRequired Download & View :: LicensedNugets :: LicenseRequired
This is so that I can confirm that the settings are correct. The way the UI is now, I have no way to know if the settings are correct and which ones to remove if need be. Note, the security is correctly applied (those that should have access do, those that should not have access are correctly denied), it's that I cannot see the settings as I did before.
Product: ProGet
Version: 4.8.2 -
How do I exclude pre-release nugets in the connectors?
Recently went from 3.8.1 to 4.8.2 and now have better connector functionality, thank you. However, we are seeing the pre-release packages show up in feeds with a nuget v2 connector. How can we filter those out? Specifically when we view a package with dependencies if the dependency has a prerelease package, that's the one we end up seeing and linking to in the web UI.
An example:
Serilog.Sinks.File v3.2.0 requires Serilog (>= 2.3.0)
Serilog's latest published version is 2.5.1-dev-00890 (which we don't want to see in ProGet).
Serilog's latest non pre-release/stable version is 2.5.0 (which IS the one we want to see in ProGet).An alternative behavior would be that the pre-release ones show up but everything would default to using stable/non-pre-release packages unless specifically called out to include them by the user. Same as on nuget.org.
Product: ProGet
Version: 4.8.2 -
RE: Proget Don't retry after timeout on a connector
I'm still seeing that caching problem that you mentioned.
v3.8.1(build10) IIS hosted- Edit feed that has no connector
- Add connector "http://localhost" (for testing, others can do the same as long as it errors on first try)
- View the feed, see the delayed 'loading' and then the 'error with a connector' at top
- Edit feed again. Remove that connector (just the red x)
- View the feed, see the delayed 'loading' and then the 'error with a connector' at top
- Edit feed again, change description (or something to trigger a save).
- View the feed, see the delayed 'loading' and then the 'error with a connector' at top
- Recycle app pool
- View the feed. Problem gone.
I repeated the above process three times to make sure. I also waited about five minutes between step 4 and step 5 to see if that would do anything.