Hi @506576828_9736 , We don't have any templates or wizards for Vue project, but you can follow the guidance on Creating a Build Script from Scratch, which would involve the following steps: Get Source Compile Project (I think this involves running npm?) Record Dependencies [optional] Run Tests [optional] Capture Artifacts Once you capture the artifact, you can use or customize the Deploy Artifacts to File Share Script Template Please share your experience, as it'll help future users searching for this as well :) Thanks, Steve

Hi @parthu-reddy, This is usually an indication of an outside process accessing this file. To verify this, if you restart ProGet, access to that file will be restored. If it is still locked, then something external to ProGet is accessing it. The most likely culprit is an antivirus scanning that file when ProGet attempts to access it. Can you restart ProGet and see if there is still a file-locking issue? If the file is still locked, can you verify that you do not have an antivirus solution that is constantly scanning that file and locking it? Thanks, Dan

Ha, It was a goofy issue. I wasn't paying attention and had the Body defined as a string in my proxy function. This is working nicely now! [image: 1719601545785-a8371438-7b61-4e65-b44f-002635d12fb5-image.png]

Hi @cstekelenburg_4169 , If you created a connector with the proper URL, username, and password, then you've set it up correctly. Please note, you will not be able to list or search remote packages in the ProGet UI. This is a limitation, since ADO is rudimentary and does not support listing/searching. Instead, you will need to use the NuGet API (Visual Studio, Nuget.exe) to pull packages. Once package has been pulled through ProGet, you will "see it" in the UI since it's been cached. I'm not trying to be pedantic with terminology, but please note it's not a "sync" -- it's more of a "proxy" or "pass through". When you make a request via the NuGet API, that API request is forwarded to your connector (I.e. Azure DevOps). -- Dean

Many thanks for that proposal, Steve! The warning label in conjunction with dumping of the package cache sounds like it is worth exploring. I shall discuss it with my security and governance collaborators :-)

Hi @scott-wright_8356 , Once connector caching is enabled, the error pattern is not used, so we only have this warning. I added a small change via PG-2726 which will add the connector name. This will appear in the next maintenance release (2024.9), scheduled for this week. Removing connector caching should reveal the connector name, so maybe that helps you identify it until then Thanks, Steve

Hi @sonali-prasad17_0018, Are you able to see the packages from the mirror in your Debian feed within ProGet? Also, do you get any errors when trying to update your source in Ubuntu? Thanks, Dan

@jw thanks for clarifying! The pipelines in ProGet are not really meant to track status. The main reason for the build stages is to control automatic archival, issue creation, and notifications. For example, your stable releases might stay in a "Released" stage indefinitely. We also had (in the preview feature) threre build statues: Active, Archived, Released. We don't use Released currently, but definitely something we may bring back. You don't want to delete a Released build, but you would probably want to delete an Archived build. Anyway, I'd check out the pgutil builds promote command - that way you can keep your "archival rules" in ProGet.

Thanks, Dean. This new build does indeed resolve the issue: [image: 1718977649685-f146af02-09f1-4a91-839d-7f82d863c478-image.png] Have a good weekend.

Hi @stevedennis, Seeing the PG-2716 solution included in the last release 24.0.8, we upgraded. In 2024.8 version the creation of new Debian feed works perfect, but the feedGroup property doesn't seem to do it. Could you double check if feedGroup is the right name, and if it's included on current version?

Great! I don't believe that there is any public reporting of VISX package vulnerabilities, so this is not data that would be available in ProGet either

Hi @daniels, This is technically possible, but it's not something that we support out-of-the-box I'm afraid. The closest way to accomplish something like this would be: Use the Otter API to create a server entry with the appropriate roles (similar to what you'd do in the UI) Install/run the agent on the computer which will connect to Otter Use the Otter API to trigger a job/ remediation Optionally, remove the server from Otter and Stop/uninstall the Agent So it's not easy from the user perspective. However. if Otter and this approach looks like it will work for you, then it's something we can definitely explore together as a user/customer, and build out a use case / case study / etc. That'd be best to start a conversation w/ someone in our customer / sales team on that. Otherwise, there really hasn't been enough demand for this particular use case, and it's hard enough to market Otter's other use cases, let alone develop build new ones ;) FYI - note that you can also run the Inedo Agent in outgoing mode: https://docs.inedo.com/docs/inedoagent-overview#communication-modes Thanks, Steve

Turns out the errors I encountered were entirely related to the "new" SQL Server driver that ProGet 2024 was using. Although this was in beta for well over a year, it was "only" in production for a few months by the time we incorporated it into ProGet. This driver issue impacts anyone who uses .NET on Linux. As I mention, I think it's pretty clear that Microsoft has effectively abandoned SQL Server. It's one thing to release something this low-quality and untested... and another to have it linger with issues like this in production for months. We will be moving to Postgres, which do not have these endemic problems. In the meantime, I have instituted the "one year rule" for Microsoft products - meaning, unless it's been shipped in their general release channel for a year, we will not even consider using it.

Hi @matt-wood_5559, Our solution for Maven builds is to leverage CycloneDX to generate the SBOM, and then upload that SBOM to ProGet: https://docs.inedo.com/docs/proget-sca-java We had considered reproducing the functionality, but the only way to get dependency information from a Maven project is to create a Maven plugin and "watch" the build as it happens --- and that's already what CycloneDX does very effectively. If you can think of ways to make it easier to work with pgutil we're very open to that :) Thanks, Alana

Hi @matt-wood_5559, I think I understand what you're asking - basically you'd like to create a feed when some users see one set of packages, but other users see a different set? This is definitely not possible, and it's simply not something ProGet does from a design standpoint: i.e. "file-system type" granular permissions. While it might seem convenient or nice to give users "just a single URL" to access, it ends up makes things much more complicated to configure/use/maintain. Basically some users will get random "package not found" errors while others will build fine. It'd be very confusing and big headache. Instead, it's best to educate on different feeds/repositories, and help them use and request access as needed. Hope that helps, Alana

Ok that makes sense thanks, I can see the option to add addition files now.

Hi @matt-wood_5559, I might need a little more information / screenshots with what you're looking at here.... There could be a bug/oversight, etc. Perhps you could walk through steps / show screenshots of what you're seeing? If it's on maven central, we can then repro and take a look Thanks, Alana

Hi @matt-wood_5559, A Maven package's license is determined by the license field in the POM: https://maven.apache.org/pom.html#Licenses There are unfortunately no real standards here, and the author can put in anything from a SPDX Code (which is recommended, by the way) to a string like "Apache license" (which probably means apache 2.0, but who knows?). We would rather not guess what the author might have intended, so ProGet only detects licenses with SPDX codes and then lets you decide how assign which codes to other license types as you come across packages that don't follow SPDX. However, once you start associating those strings with licenses, it will work for future packages. Thanks, Alana

@forbzie22_0253 setting the proxy programmatically is not something we currently support or document at this time, but if you're dedicated you could use native API to the newly-developer settings API: https://github.com/Inedo/pgutil/blob/thousand/pgutil/Settings/ListCommand.cs It's configured via values in the Configuration table.