@joshuagilman_1054 this is currently planned for 5.3.27 as PG-1934 (April 17) - we'll let you know if plans change!
stevedennis
@stevedennis
Best posts made by stevedennis
-
RE: How to set content type of asset with API?
-
RE: Proget: delete all versions of a package via API
Hi @mcascone ,
We don't have a single API method that can be used to delete all package versions from the API, but the
foreach
loop will do the trick!I should add that I am doing this as the first stab at an attempt to automatically delete packages from a development feed, when the corresponding branch in github is deleted
I don't know the specifics/details of your use-case, but based on what I read, I'd recommend these guidelines:
- assuming: one GitHub repository, one project, one package you want to release
- use the same package name/group for all packages you create for this project, regardless of branch or development status
- create your "dev" packages using a prerelease version number, that has a sort of
-ci.##
version (assuming you use CI to build packages) - embed the commit id and branch in your upack metadata file, for traceability
- if you want to see which branch the packages was created from using the version number alone, add a
+branch
metadata label to the version number for branches (don't do this formaster
) - use repackaging and promotion to take your
-ci
packages to-rc
to stable (and the desired feed) - let retention policies automatically cleanup up the
-ci
packages
-
RE: No option for NuGet package path under Advanced Settings
Hi @kichikawa_2913 ,
I think it's this way for "historic reasons" - mostly all the other feed types came later, and it seems no one ever changes these paths or noticed.
Easy enough to make it configurable, but can you share your use case? Why do you want to use something other than a single root path with all of your packages?
Anyway I added a feature for this, and we should be able to get it in the next maintenance release PG-2006
Cheers,
Steve
-
RE: Marking packages as deprecated
No problem "resurrecting" topics! We definitely want to hear from users about feedback/feature requests.
We still haven't had anyone else ask for deprecation since this request, but I wonder if there's a better solution to solving your challenges than this feature. It sounds like you want to increase governance of your NuGet Packages, potentially with some sort of compliance in mind.
The
dotnet list package --vulnerable
is probably not what you want for your organization; NuGet's Built-in Vulnerability Scanning is really limited, in part because it only reports on a fraction of known package vulnerabilities (164 as of today). It also won't block packages that you deem problematic, unlike ProGet's feature.The same is true with
dotnet list package --outdated
-- it's probably not what you want, because it relies on developers to have to know (1) to run the command, and (2) know what to do if there's an outdated dependency.There are better ways to manage third-party packages (see How to Create a Package Approval Workflow for NuGet), and you'd better served knowing who's consuming outdated packages (see Use Package Consumers to Track Dependencies
Just some thoughts; like I said, we haven't had any demand for this feature, but these are proven solutions for improving governance of packages as organizations grow/expand their NuGet usage like you are.
Cheers,
Steve -
RE: Permissions only work when set for specific user, not a group (LDAP)
Hi @kichikawa_2913 ,
The NuGet client's behavior is based on NuGet.org, where no authentication is ever required to view/download packages. As such, it doesn't pass the API key when doing those queries; instead, you can use a username of
api
and the password of your api key.Based on the issue though, it sounds like ProGet is unable resolve the groups; I would use the "test privileges" function on the Tasks page to verify this. Thatw ill show you if the username can download packages or not.
The most common reason that groups aren't resolving is that the member is not directly in the group (i.e. they're in a group which is a member of the group), and you don't have recursive groups enabled; do note that this is really slow on some domains.
Cheers,
Steve -
RE: upack repack doesn't use complete version string from CLI
Hi @mcascone ,
Just looking at the code real quick, I suspect we have a bug where it writes out the wrong files name for the new package:
https://github.com/Inedo/upack/blob/master/src/upack/Repack.cs#L120That's probably an easy fix, which we can do as part of this Q&A item. I'll wait to hear back about this one.
As for the error, "The underlying connection was closed: An unexpected error occurred on a send.", that sounds like it's HTTPS related. Could you attach Fiddler, or something like that, to find out what's happening under the hood? We may be able to error message to better report it if so.
Cheers,
Steve -
RE: Mixing ProGet Instances
Hi @cimen-eray1_6870 ,
Great questions; there's no problem having a second instance with ProGet Free Edition.
The relevant restriction is that you can't use a Connector in ProGet Free Edition to connect to another instance of ProGet (either another Free Edition or your paid edition).
Hopefully you can use your Maven feed as a proof of concept for implementing it in the main instance. Good luck!
Cheers,
Steve -
RE: Proget - Can't use the native API even with an API Key with Native API access
Hi @m-webster_0049 ,
The first thing I would try is to troubleshoot this is to switch to a very basic API key like
hello
. That just eliminates any typos, spacing, etc.Next, I would try specifying the API Key via
X-ApiKey
header (see docs) - just to see if you get a different error. It's possible there is a regression somewhere.Best,
Steve
Latest posts made by stevedennis
-
RE: ProGet: Exception when NuGet README links to image that is not contained in the package
@jw we'll definitely keep this in mind, it doesn't look trivial based on our usage of that marked library
Personally, I always try to keep the Diagnostic Center clean and empty, so when new issues show up I can easily spot and address them. Sifting through messages that are basically spam, without being able to filter or ignore them costs me more of my time that I would like to invest for monitoring.
We do not recommend using the Diagnostic Center for proactive monitoring. It's only intended as a tool for troubleshooting things like connector or 500 errors that you / end-users encounter.
There are a lot of non-problem errors and warnings logged that aren't worth time even looking at.
-
RE: ProGet: Exception when NuGet README links to image that is not contained in the package
Thanks for clarifying @jw !
I understand how this can be annoying, but I don't think we want to change the
404
not logging error for this issue in particular. Open to ideas if you have them.As an FYI..
- I think we use the marked library to turn text into Markdown, like this:
el.innerHTML = marked(el.textContent);
- some users definitely use absolute urls within readmes to navigate and show content/images within ProGet
- some users may use relative urls for links, but I can't imagine that ever working for images
If there's a way to supress relative urls in the marked library somehow, we could probably add it if you know how!
- I think we use the marked library to turn text into Markdown, like this:
-
RE: ProGet SCA: Add license type issue
@jw thanks for the bug report! This will be fixed via PG-2650 in the next maintenance release. It should say "License Id" instead - and it will then redirect to the Edit page after, which is almost as convenient as using the same dialog but won't require rewriting the page ;)
-
RE: ProGet: Exception when NuGet README links to image that is not contained in the package
Hi @jw,
This is expected behavior, as 404 errors are logged for non-API requests, and that's a relative URL. Is
README.assets
a kind of documented standard? It might just intended for GitHub?Thanks,
Steve -
RE: Package Vulnerabilities - API
Hey @rick-edwards_9161 ,
Yes - this would be easiest to do with the
pgutil vulns audit
command, which we're still working on documenting.Description: List vulnerabilities associated with a package or project file Usage: pgutil vulns audit [options] Options: --input=<input> Project to audit for vulnerable packages --package=<package> Name of package to audit for vulnerabilities --type=<type> Type of package to audit for vulnerabilities Valid values: apk, deb, maven, nuget, conda, cran, helm, npm, pypi, rpm, gem --version=<version> Version of package to audit for vulnerabilities -?, --help Show help and usage information
See Getting started with pgutil to learn more.
-
RE: ProGet 2023 - IIS App pool stopping
Hi @rick-kramer_9238 ,
I wouldn't recommend upgrading to ProGet 2024 solely for that reason, as it's a major release and if there were issues, it'd be easier to isolate Integrated Web Server vs Regression.
Here are the upgrade notes:
https://docs.inedo.com/docs/proget-upgrade-2024That said, if you need to rollback to ProGet 2023, you can do so without restoring the database by simply using the Inedo Hub. While there are database schema changes, they are all backwards-compatible with ProGet 2023, which means you can safely rollback your ProGet installation if there's a showstopper bug, and then upgrade later.
However, you should backup your database as an extra precaution anyway.
Thank you,
Steve -
RE: Custom endpoint URL
Hi @rmusick_7875,
I'm afraid API endpoints are not customizable and we do not support doing "reverse proxy" or otherwise rewriting the URLs. Hopefully this will be a good chance to make the endpoint-url more easy to configure/change - this will be important, as you may wish to move to multiple feeds, etc.
Good luck,
Steve -
RE: ProGet: Chocolately unable to connect
Hi @greg-swiderski_0221 ,
It looks like there is an "Object reference not set to an instance of an object" error that's occurring while trying to connect:
2024-04-30 09:52:41,341 8256 [WARN ] - Unable to connect to source 'http://localhost:8624/nuget/approved-choco/': Object reference not set to an instance of an object.
That error is presumably occurring from the Chocolatey client (
choco
), and unfortunately there's no way to know what it means. Most likely, it's an "error reporting an error" message, but it's hard to say.You could use some HTTP monitoring software (Fiddler Classic, Wireshark), and see if ProGet is returning an error of some kind.... but even if so, choco should report that error.
I would check with the chocolatey team on this one.
Thanks,
Steve -
RE: [BM / OT] Renaming "user/password" or "private key" credentials breaks Linux config
@philippe-camelio_3885 I just cloned the issue for Otter (OT-509), so should be an easy fix. Maybe this will hlep w/ data sync issues as well!
-
RE: NuGet no longer works after upgrading to 2024
Hi @jw ,
Thanks - we modified the script and tested it against your database backup:
https://gist.github.com/apxltd/351d328023c1c32852c30c335952fabbThat said, your duplicate data should not cause any problems. The only feed packages this seems to modify in your database are
Microsoft.NetCore.App.Runtime.win-x86-8.0.0
andMicrosoft.NetCore.App.Runtime.win-x64-8.0.0
. Both are cached.That said, given that it had a bug, we probably won't put this script in 2024.2; we'd much rather "share the script on a case-by-case" basis to fix problems, until we're confident they will be resolved. Then decide how to have users repair the data.
Thank you,
Steve