Posts made by NanciCalo

Hey @pmsensi ,

Just to jump in here... it sounds like there are two issues.

I think the first issue is that properties like owners, verified, etc. are not returned for local packages.

Those properties are not "package metadata" properties (i.e. stored inside the package), but they're "server metadata" properties (i.e. stored outside the package, on the server). Other server metadata properties are downloadCount and listed.

ProGet does not support all of the server metadata properties that nuget.org does; but even if it did, the properties would not be copied from a connector when a package is added to the feed. This is why downloadCount turns to 0 when cache a package.

However, server metadata properties are "passed through" remote packages.

The "package metadata" properties are contained in the .nuspec manifest file:

<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    <id>Microsoft.Playwright.NUnit</id>
    <version>1.35.0</version>
    <title>Microsoft.Playwright.NUnit</title>
    <authors>Microsoft</authors>
    <license type="expression">MIT</license>
    <licenseUrl>https://licenses.nuget.org/MIT</licenseUrl>
    <icon>icon.png</icon>
    <projectUrl>https://github.com/microsoft/playwright-dotnet</projectUrl>
    <description>Playwright enables reliable end-to-end testing for modern web apps. This package brings in additional helpers and fixtures to enable using it within NUnit.</description>
    <copyright>© Microsoft Corporation. All rights reserved.</copyright>
    <tags>headless,chrome,firefox,webkit,playwright</tags>
    <repository type="git" url="https://github.com/microsoft/playwright-dotnet.git" commit="ca7b02ac910e573666f48d502bfabb1c17639e68"/>
    <dependencies>
      <group targetFramework=".NETStandard2.0">
        <dependency id="Microsoft.Playwright.TestAdapter" version="1.35.0" exclude="Build,Analyzers"/>
        <dependency id="Microsoft.Playwright" version="1.35.0" exclude="Build,Analyzers"/>
        <dependency id="Microsoft.NET.Test.Sdk" version="16.11.0" exclude="Build,Analyzers"/>
        <dependency id="NUnit" version="3.13.2" exclude="Build,Analyzers"/>
        <dependency id="NUnit3TestAdapter" version="4.0.0" exclude="Build,Analyzers"/>
      </group>
    </dependencies>
  </metadata>
</package>

The second issue, I think, is that the versions property is not aggregated. This isn't really feasible/possible to do as a result of the "paged searching" that Dean mentioned.

For example, if you search search a feed for q=foo,take=2, then ProGet will work as follows:

1. Search local packages for foo
2. Return up to 2 search results; if not enough results, then ...
3. Forward search to first connector
4. Return search results; if not enough, then...
5. Forward search to second connector
6. Etc...

To get the behavior that you'd like, ProGet would need to:

1. Search local packages for foo
2. For each search result, query each connector for a list of all package versions (registrations)
3. Aggregate those results into the version property
4. Return up to 2 search results; if not enough result then...

So this is why it's not really possible to get search API to behave like you'd expect.

Hope that helps,
Nanci

Hi @mihajlo_7906 ,

It looks like you're using legacy functionality (i.e. from BuildMaster v4 and earlier) within a legacy version (v5) of BuildMaster.

Re-execute from last failed action button is re-executing the whole pipeline stage (from the beginning) instead of the current action of which the deployment failed.

The "Re-execute from Last Failed Action" is only displayed on some Legacy Plan executions, and it can't work on all plans. I'm not sure why it doesn't work in your case, but we no longer have such functionality on for non-legacy (OtterScript) executions, so I can't guess why it doesn't work.

An unhandled exception occurred while executing this action: System.IO.FileNotFoundException: Could not load file or assembly 'Windows' or one of its dependencies. The system cannot find the file specified.

This error is saying that the "Windows" extension file (Windows.upack or Windows.bmx, depending on the configuration) didn't load.

This is why why deployments fail. The most common reason for this is file locking (anti virus, etc.), but you can use tools like Procmon to see what's going on. Loading an extension involves unzipping it and loading the enclosed .dll from disk.

Cheers,
Alana

Hello @itpurchasing_0730 ,

The simplest way to handle this is with some some SQL Commands (i.e. the Native API), after the ProGet database is installed/updated.

You can execute commands like this:

docker exec -it inedo-sql /opt/mssql-tools/bin/sqlcmd \
  -S localhost -U SA -P '«YourStrong!Passw0rd»' \
  -Q '«sql command here»'

The commands to run (note you'll need to escape the single-quotes):

• EXEC Configuration_SetValue 'Licensing.Key', '«your key»'
• EXEC Users_SetPassword 'Admin', «password-bytes», «salt-bytes»

«password-bytes» and «salt-bytes» will be hex strings, like 0x0000, and you can find those values by querying the Users table after you've set the admin password to be what you want.

Hope that helps!

Cheers,
Nanci

Thanks for report @jim-borden_4965

We just reviewed the Version Order Specifications, which are a bit ambiguous... but if that's what the version class does, then we may as well follow.

I've fixed this as PG-2226 by comparing integer version qualifiers numerically, and it will be in the next maintenance release.

@mistique88885_0973 thanks for letting us know! I didn't realize that was wrong.

I just corrected the text , and it will be fixed via PG-2225 in the next maintenance release

Hi @jim-borden_4965 ,

The Maven API doesn't support artifact deletion, and we haven't had any requests for that to date. I suppose, usually because it's pretty rare to need to delete a package :)

In general, users configure automatic retention rules to delete older things.

From a UI-perspective, there is the "bulk package deletion" that's available in ProGet 2022 and later, and so that might save a bunch of clicks.

Cheers,
Nanci

Hi @grant-drake_7379 ,

Here are some steps for how to switch to IIS:
https://docs.inedo.com/docs/various-iis-switching-to-iis

Also note that when uninstalling ProGet, your database/packages are not deleted :)

Cheers,
Nanci

Hi @afd-compras_2365 ,

This is the second request for the feature - but I'll bring this up at our engineering meeting.

@benjamin-soddy_9591 is there something more you can add to the conversation ?

Cheers
Nanci

hi @ab-korneev_0401 ,

By "debugging", we mean running the ProGet code inside of Visual Studio's "debug mode". That will show the errors let us see quickly how to fix them. I'm afraid it's not easy to identify the problem without it, since it's very likely a bug in the third-party repository you're using.

Since it's not possible to provide that information, can you...

1. create a server on AWS LightSail (or similar cloud service)
2. Install the same type of third-party repository software and configure it in same manner
3. upload one or two packages that reproduce the problem
4. verify the problem in ProGet

Then, send us the information of the server, and we can look at it through the debug mode

That's really weird - the default category is Support for me to, but it pops up only after a second or so, and some Javascript. Maybe it's a browser thing, or a strange setting on your account? It's hard to say, I'm not an Admin myself on the forums.

My Homepage is also "Custom" too. Maybe that's a default?

Hopefully it's not too much a hassle - we will probably upgrade this software (NodeBB) at some point again, this version seems stable -- but there's always bugs here and there :)

@Stephen-Schaff thanks so much Stephen, that's great! It's not so hard for us to add this api key back, but your code works just the same mostly i think! let us know...

Anyway I've updated the documentation :)

Hello;

Does your server have Internet access? That is an ancient version of the Inedo Hub...

I would uninstall the Inedo Hub, and then download it again. Hopefully the error will be resolved then.

Cheers,
Nanci

Hi @csmith1_6177 ,

This is related to the the same issue you submitted in a separate ticket (EDO-8182). This is a bug related to an API change and a specific package that specifies an icon in a certain way.

The best way to fix this is to upgrade; this was fixed long ago via PG-1617

As a work-around, you can set the BaseUrl property under Admin.

Cheers,
Nanci

@Stephen-Schaff thanks! We are planning to rebuild all the users/groups/permissions pages in the coming weeks, so I'll also this as something for us to consider getting in

Hi @Stephen-Schaff,

One thing you could do is go to Admin > Service > Restart Web Application. There's really no downtime with that.

Otherwise, we are planning to rebuild all the users/groups/permissions pages in the coming weeks, so I'll add an "Invalidate Cache button" as something for us to try to get in :)

Cheers,
Nanci

Hi @Stephen-Schaff,

This checkbox will do the latter, i.e. "keep the newest 100 versions in each chart (up to 2,000 charts in total)" :)

Note that you can also run retention policies in "dry mode" (it's a setting under Advanced Settings), to see how they would perform.

Cheers,
Nanci

@mcascone thanks for checking, looks like this is missing on the display end. And just to confirm, what version of ProGet is this? v5.3 or v6?

Hi @mcascone ,

I'm not super-familiar with the Jenkins plugin, but it's possible we're just not displaying those fields in the ProGet UI. It sounds like at least some are in the "old" UI.

Are these fields showing up in the manifest upack.json metadata file?

Thanks,
Nanci

Hi @ashah_4271 ,

We could definitely improve our documentation in this area, but let me explain a few things...

$ApplicationName are $PipelineName contain the name of the application and pipeline in context. What this means is that, if an OtterScript is running within a build deployment, then it will be the name of the application, and the pipeline that the build is being deployed in.

Your custom build trigger OtterScript is running within an application, which means $ApplicationName will be whatever the name of the current application is. However, it's not running within a pipeline, so $PipelineName will be empty.

Long story short, you should only need to change $PipelineName to be the name of the pipeline you wish to use.

All that said, I don't know why Pipeline is required, when there is a default release template. So this can be an area of improvement in that operation as well :)

Please let me know if this is helpful, and then I will try to log an issue to fix/improve on our ends

Cheers,
Nanci

Hi @mjc_4927 ,

This was a regression in the Free Edition of v7 due to some internal library upgrades, but is now fixed as BM-3734 - it'll be in the next maintenance release :)

If you're interested in a patch/pre-release version, let me know and I can share it.

Cheers,

Nanci

Hi @csi_lund

We recently updated our documentation, can you take a read at Symbol and Source Server in ProGet?

Hopefully it helps explain things, but a couple things that are jumping out

• the /symbols/<feed-name> end point is intended for Visual Studio; you can't push packages to it, and will need to push to /nuget/<feed-name>
• if you want to use a single feed, then you need to make a single package by setting the DebugType property on your project file to embedded

Please let me know if I can clarify, so then we can improve our docs as well :)

Nanci

Hi @paul-reeves_6112 ,

That might be a bit more effort that it's worth (i.e. to proxy those external icons through BuildMaster), but something we can consider depending. Usually the client browser is not behind a restrictive proxy like that.

But most importantly... you can definitely point to your own template gallery. Once you do, you'll be able to publish your own templates under Application Settings.

You can also delete the Templates package source. It'll just give a warning on that page that it's not there, and give you a button to recreate it.

Cheers,
Nanci

Hi @Stephen-Schaff,

The renewal contact at your organization should have been receiving emails about 60 days ago, and then someone was supposed to be manually following up... but something clearly fell through the cracks. I already escalated it internally.

But not to worry! In a case like this, please just go to my.inedo.com, and request a 30-day trial license key. It has all the functionality of ProGet Basic, so your service won't be interrupted at all.

Changing the expiration warning in the software to 30 days is really good idea to prevent problems like this, so I'll request that as a feature internally :)

Cheers,

Nanci

Thanks @harald-somnes-hanssen_2204 !

This seems like a low-risk way to handle this going forward. We'll track this via PG-1924; note it's currently planned for the next maintenance release, so hopefully it'll be there soon!

In the meantime, if you've got a ton of vulnerabilities, we could help construct a database query to help with a one-off purge. But it might be easier to just click away, too

Thanks for reporting this regression! It appears to be related to some kind of refactoring.

I've logged it as OT-411 and we are targeting fixing it in the next release.

@pete_4689 you can configure Security and Access Controls to restrict which users have the Overwrite Package, Delete Package, and other privileges

@brett-polivka thanks

So, this may have been a regression due to a recent change to the Azure extension. Can you rollback to Azure 1.9.0 by manually installing it?

@Stephen-Schaff

I think cc/ @rhessinger can correct me if I'm wrong, but you should be able to just rollback only the the InedoCore extension to 1.7, where we used the older version of the AD libraries.

You can do this by downloading and manualy installing from here: https://proget.inedo.com/feeds/Extensions/inedox/InedoCore/1.7.12

@brett-polivka I know that there were some recent changes to these extensions; what version are you using of ProGet and the Azure extension (Admin > Extensins)?

Hi @kunal-bhujbal_8395 ,

You can ignore these messages.

.js.map files are used by Chrome's debugging tools, and may be requested by browsers that have debugging/development mode enabled.

ProGet does ship with .js.map files, and thus makes an error (404) if these files (or any others that ProGet does not have) are requested.

In a future version of ProGet, we will not log error messages when .js.map files are requested

Thanks,
Nanci

hey @jerome-jolidon_1453

Thanks for confirming about the versions. There was a change in ProGet 5.3.9 that might have fixed this:

• PG-1789 - FIX: Connector filter rules not working on NuGet feeds

But if it's not working on 5.3.17, then it must not have helped. So from here, we'll try to reproduce this and let you know the results.

Please stay tuned!

Cheers,
Nanci

Hello,

We're definitely keen on improving the documentation!

What version of ProGet are you using? In ProGet 5.3, it should involve...

1. navigate to the "Manage Feed" page.
2. select the "Connectors & Replication" tab.
3. select the desired connector name.
4. click "Add Filter," enter @microsoft/ and select "Block."

note this requires a paid Proget license.

Cheers,
Nanci