Posts made by rhessinger

Hi @guyk,

It looks like jetstack is not requiring Helm packages to use SemVer 2 for their package versions. We have a flag to bypass packages with an invalid version or metadata, but it looks like it was hidden in ProGet v2023. I have added it back as part of ticket PG-2376, and it is set to release in ProGet 2023.7 this Friday. I can push out a pre-release version of ProGet to get the fix faster if you would like.

Thanks,
Rich

Hi @philippe-camelio_3885,

Looking at the code for v2022.10, there is nothing apparent that sticks out to why this wouldn't work. Just to verify, you do not have any other credentials (or legacy credentials) with the same name do you? The only thing that I see in the code would be due to how things are returned and sorted by the function, if there would happen to be two credentials with the same name, it may return the wrong credential which would have the wrong value set.

Thanks,
Rich

Hi @MF-60085,

It looks like there is a bug in the migration process when you select a specific feed. If you re-run it with no feeds selected, it will rerun it for all feeds that need to be migrated and that message should go away. We will fix the per-feed retry migration in ProGet 2023.6 which is due out this Friday.

Thanks,
Rich

Hi @MF-60085,

Can you please try upgrading to ProGet v2023.5? We have fixed multiple migration issues since ProGet 2023.0, including the MERGE statement error when handling NuGet packages.

Thanks,
Rich

Hi @k-gosciniak_5741,

Can you please try downgrading to a previous version of v2023 and then upgrading to the latest version again? Also, can you please verify that web site in IIS is pointing to C:\Program Files\ProGet\Service?

Thanks,
Rich

Hi @MF-60085,

You can attempt to run the migration again (it won't hurt any existing data for rollback), it may resolve the issue. What version of ProGet did you upgrade to?

Also, it may be helpful to email us the migration log to review in more detail. You can send it to support@inedo.com,use the subject [QA-1121] Migration Log, and let us know you sent it so we can keep an eye out.

Thanks,
Rich

Hi @ForgotMyUsername,

Sorry about that. Looks like the article was changed but not published. I published the updated.

Thanks,
Rich

Hi @markus-karthaus_8928,

The validity check of a certificate ion ProGet is primarily to verify the certificate itself is valid, not if it is valid for ProGet. Any self-signed or internal domain certificate will be invalid by default unless the certificate or certificate authority exists in the trusted root on your server. If it is a purchased certificate, I would check that your certificate's chain is properly installed on your server. If your certificate is a valid certificate but requires a custom certificate chain (many do), that chain will need to be installed on the server for ProGet to validate that properly. A .pfx certificate does not store the certificate chain internally in the file. The browser handles the validation slightly differently, so that is most likely why it seems to work in the browser.

When it comes to the .pem file. There are many ways to generate it, but I'm guessing the certificate chain was stored internally in the pem file, which then does not require the certificate chain to be installed on the server.

I'm speculating on the certificate chain in these cases because seeing why your certificate is not valid requires more than the screenshots you provided. I would actually need to see your certificate itself to truly validate this.

Lastly, when it comes to using a .pem file, .NET tends to be very picky about it's format. It is not as forgiving as other frameworks. If you look in the "HTTPS Binding to a Port (Advanced) (Experimental)" of our HTTPS Support on Windows documentation, we have instructions on how to create a .pem file from a .pfx. I'm not sure if that is what you followed, but that is the simplest way we have found to generate a .pem file that works with .NET.

Hope this helps!

Thanks,
Rich

Hi @h-morgenthaler_3015,

Alana was correct, the change was not merged into the 2023 release. The fix, PG-2350, will be released on Friday in ProGet 2023.4. If you need it earlier than Friday, I can push a pre-release version of ProGet 2023.4 for you. Please let me know!

Thanks,
Rich

Hi @jw,

Does this only happen with that one .snupkg or all of them? Also, could you please verify that the Symbol Server is still enabled on your feed for the "Standard (.snupkg format)" support?

Thanks,
Rich

Hi @markus-karthaus_8928,

The HTTP/S & Certificate Settings page will update the ProGet.config file that is commonly stored at C:\ProgramData\Inedo\SharedConfig\ProGet.config. As long as the inedoprogetwebsvc Window's service's account has write access to that file, it will be able to save. On fresh installs, this will typically work without requiring changes. My guess is something was changed with the executing user or the server permissions that is preventing write access to that configuration file.

You can also manually setup HTTPS by editing the ProGet.config file directly. See the "HTTPS Binding to a Port (Advanced) (Experimental)" section of our HTTPS Support on Windows documenation for the different options.

Thanks,
Rich

Hi @msimkin_1572,

Can you please navigate to your Manage Feed page and verify that JSON-LD (v3) is enabled under the Supported API?

Thanks,
Rich

Hi @msimkin_1572,

Can you please verify that you enabled the standard symbol server on your feed? Also can you please verify that the .snupkg file exists at the same location and name (minus the extension) before you run nuget push?

Thanks,
Rich

Hi @hashim-abu-gellban_3562,

Happy to hear the config fixed your issue on the clair container. In ProGet v2022 we moved the feed vulnerability source to the Reporting & SCA > Vulnerabilities > Configure Vulnerability Download Blocking page. You should be able to wire it up from there. I'll make sure to update our documentation with these changes as well.

Thanks,
Rich

Hi @hashim-abu-gellban_3562,

Can you please tell me which version of ProGet you are running? Are you able to edit your vulnerability source in ProGet?

Thanks,
Rich

Hi @informatique_1359,

Good catch! I updated the Docker-Compose docs to reflect that.

Thanks,
Rich

Hi @informatique_1359,

The error is definitely that the BuildMaster and Otter containers cannot find a server with the name of mssql. I'm surprised that ProGet works, but Docker can be confusing. This seems to be a pretty common docker issue. How I have solved this in the past is to add an alias to the network section on your SQL Server container. For example:

networks:
  databases:
    name: mssql

Because you are using the databases network on ProGet, BuildMaster, and Otter containers also, that will add a hostname of mssql to the docker network and make it accessible by name. I would also suggest adding an alias to your ProGet, BuildMaster, and Otter container configurations to prevent issues with these servers being able to communicate with each other as well.

For more information, see our Docker-Compose installation guide.

Thanks,
Rich

Hi @jwest_6990 ,

So I'm struggling to reproduce this error. For me, it just seems to work. I'm wondering if maybe a DLL got removed (possibly an antivirus false-positive) or conflict with something else installed on the host. Are you able to see a full stack trace? Do you have anything else installed on your Otter server?

Thanks,
Rich

Hi @pfeigl,

Thanks for letting us know. It looks like this is related to how HEAD requests were handled. I went and added that header to head requests also. This will be tracked in PG-2300 and will be released in ProGet 2022.25.

Thanks,
Rich

Hi @jwest_6990,

I'm sorry, somehow I missed that in your previous response. I'm going to attempt to recreate this in our test lab and see if I can get the same error. I'll let you know what I find.

Thanks,
Rich

Hi @OtterFanboy,

Good catch. I'll get the documentation updated shortly to reflect this. The older version of the Inedo Agent was only a 32-bit requirement, but we changed it to a 64-bit requirement in the newer agents. Unfortunately, I don't remember which version it changed in though.

Thanks,
Rich

Hi @jwest_6990,

Are you running Otter on Windows or on Linux (using Docker)?

Thanks,
Rich

Hi @testintergraph_2317,

It looks like there was a hiccup in the release of the updated InedoCore extension. You should now see the ability to upgrade to the InedoCore v2.2.1 version. That includes AD v4. Sorry about the confusion there.

Thanks,
Rich

Hi @arozanski_1087,

I just wanted to let you know that we just released a new version of pgscan, 1.4.2. Going forward it will automatically scan npm packages anytime it is scanning for NuGet packages using a .NET solution or project, there will not be any new parameter needed to enable the search.

We are still working on adding yarn support, but that one will take us a bit of time to add. We will update you when that one is ready to be used.

Thanks,
Rich

Hi @philipp-jenni_7195,

It looks like there was a regression applied to that fix. We have fixed it as part of PG-2288, due in a couple of weeks in ProGet v2022.22. If you would like, I can set up a CI release for you that you can install now using Inedo Hub.

Thanks,
Rich

Hi @pfeigl,

Always happy to help! The new release is scheduled to be available on Friday. After upgrading to it, please inform us if the issue you were experiencing has been resolved or not.

Thanks,
Rich

Hi @pfeigl,

I did some investigation and it does look to be related to our platform upgrade. We will have a fix ready to be released in ProGet v2022.20.

Thanks,
Rich

Hi @rosario-digiovanni_1930,

I was able to reproduce the issue. Please give me a bit of time to dig into this further to determine what is causing it.

Thanks,
Rich

Hi @philipp-jenni_7195,

Thank you very much for the steps to recreate this issue. I was finally able to recreate it and it looks to be easier to recreate on Linux than on Windows. We have created a ticket, PG-2274, to track the fix. We should be able to get this into today's release!

Thanks,
Rich

Hi @philipp-jenni_7195,

I'm sorry, but I'm really struggling to recreate this.

The test I setup was:

• Docker run ProGet 2022.18
  • I also tested on ProGet 2022.15, but this one was on Windows. Functionally they do not differ in upack feed code.
• Create a new upack feed
  • No connectors or other packages
• upack push database-schema-7.60.0.upack to the new feed
• upack push database-schema-7.61.0.upack to the new feed

That all worked. I then proceeded to do different combinations like push 7.61, then 7.60. The only time I was able to get the "Feeds_OverwritePackage" error was when the package already existed in the feed and I tried to push it again (which works as designed).

Do you have anything sitting in front of your Docker image (like a reverse proxy or HTTP request forwarder) that may attempt to resend a request if it takes too long? The only thing that makes sense to me would be the push request is being duplicated and the first succeeds and the second errors because the package already exists.

Thanks,
Rich

Hi @nselezneva_7646,

Am I correct that you had that exact issue with the example packages you sent over to us? Would you be able to send me just the upack,json files from the packages you are testing with?

Thanks,
Rich

Hi @philipp-jenni_7195,

I took a look at your example and I was able to push the packages to my feed without issue. If I tried to push the package a second time, I then I would get that Feeds_OverwritePackage" error, but that is expected.

Are you getting this error when you try to push it initially? Are there other packages in the feed? If there are other packages in the feed, are there any with the same name but a different group name?

Thanks,
Rich

Hi @philipp-jenni_7195,

I can confirm that we have received your email. Please give us a bit of time to review it and we will get back to you soon!

Thanks,
Rich

Hi @Justinvolved,

That message that says "currently contains 0 items" is just telling you that the folder that the artifact is deploying to contains 0 files. After that, it will deploy the artifact files. If you enable verbose logging (setting Verbose: true), you will see all the files transferred from the artifact to the working directory.

Thanks,
Rich

Hi @Justinvolved,

We can definitely improve the error message when trying to deploy a config file when an instance is not found. Would you be able to share your OtterScript with us for how you are deploying the config files? Also, how do you have your deployment target configured (single server, group, environment, etc...) on your stage?

Thanks,
Rich

Hi @justin_2990,

We are actually in the process of developing dedicated npm operations, but we do have anything ready as of yet. The easiest way to call npm commands is to use the Exec operation in OtterScript. Due to how the npm CLI writes it's output, you need to add ErrorOutputLogLevel: Warning to the Exec operation. Here is an example of the npm install and npm publish commands:

set $NpmPath = C:\Program Files\nodejs\npm.cmd;
set $NodePath = C:\Program Files\nodejs\node.exe;

# Install Dependencies
Exec
(
    FileName: $NpmPath,
    Arguments: install,
    WorkingDirectory: ~\Source,
    ErrorOutputLogLevel: Warning
);

# Publish Package
Exec
(
     FileName: $NpmPath,
      Arguments: publish Source,
      WorkingDirectory: ~\,
      ErrorOutputLogLevel: Warning
);

When it comes to ProGet::Scan, it should work with all npm packages. It just reads the package-lock.json and records the dependencies in ProGet. You can see our implementation on the pgscan GitHub repository. If that doesn't work, you can always use a tool like CycloneDX to generate an SBOM and upload it to ProGet via the SCA API which has an endpoint for importing an SBOM file directly.

One last thing, you mentioned that you are using ProGet. You can create an OtterScript module to register ProGet as your package source for npm. I do this with the following:

ConfigureNpmRegistry OtterScript Module

##AH:UseTextMode
module ConfigureNpmRegistry<$NpmPath, $ResourceName, $CredentialName>
{
    set $ProGetNpmRegistry = $SecureResourceProperty($ResourceName, ServerUrl);

    Exec
    (
        FileName: $NpmPath,
        Arguments: config set registry $ProGetNpmRegistry,
        WorkingDirectory: ~\,
        ErrorOutputLogLevel: Warning
    );

    set $AuthToken = $SecureCredentialProperty($CredentialName, Token);

    PSCall Base64Encode
    (
        Text: api:$AuthToken,
        EncodedText => $AuthKey
    );

    Exec
    (
        FileName: $NpmPath,
        Arguments: config set always-auth true,
        WorkingDirectory: ~\,
        ErrorOutputLogLevel: Warning
    );

    Exec
    (
        FileName: $NpmPath,
        Arguments: config set _auth $AuthKey,
        WorkingDirectory: ~\,
        ErrorOutputLogLevel: Warning,
        LogArguments: false
    );

    Exec
    (
        FileName: $NpmPath,
        Arguments: config set email support@inedo.com,
        WorkingDirectory: ~\,
        ErrorOutputLogLevel: Warning
    );
}

I also had to add a PowerShell script to handle the base64 encoding of the credentials:

<#
    .SYNOPSIS
    Base64 Encodes a string

    .PARAMETER Text
    Text to be encoded
    
    .PARAMETER EncodedText
    Encoded text string
#>

param(
    [Parameter(Mandatory=$true)]
    [string]$Text,
    [ref]$EncodedText
)

$Bytes = [System.Text.Encoding]::UTF8.GetBytes($Text)
$EncodedText =[Convert]::ToBase64String($Bytes)

I then call this using:

# Setup registry
    call ConfigureNpmRegistry
    (
        NpmPath: $NpmPath,
        ResourceName: global::ProGetNpmRepo,
        CredentialName: global::ProGetNpmCredentials
    );

These are all operations we plan to build into the npm extension, but these are currently the workaround until we get that extension up and running. I hope this helps! Please let me know if you have any questions.

Thanks,
Rich

Hi @philipp-jenni_7195,

Can you please try upgrading your upack CLI to the latest version and see if that resolves the problem for you?

Thanks,
Rich

Hi @philipp-jenni_7195,

Can you please tell me what version of the upack CLI you are using? You can find that by running the command upack version.

I tested by creating a new Universal Packages feed with a feed usage type of PrivateOnly and the upack CLI 3.0.1.3 and I was able to push without issue. Can you also please answer a couple of other things for me?

• What is the upack CLI command you are running to push your package?
• Are you using an API key? If so, what permissions do you have configured on the API key?

Thanks,
Rich

Hi @jimthomas1_7698,

Thanks for bringing this to our attention, we will get that updated!

Thanks,
Rich

Hi @22marat22_9029,

So turns out that we had a compatible library from our Conda implementation that I was able to use for zstd compression with Debian. I have created a ticket, PG-2242, to track the fix and it will be released in the next release of ProGet, 2022.14.

Thanks,
Rich

Hi @22marat22_9029,

Currently, we do not support the compression format of zstd (tar.zst) for the control or the data file. We only support .tar, .tar.gz, and .tar.xz fir the data and control files with the addition tar.bz2 and tar.lzma for the data file . This is currently a limitation of the third-party package we use to read tar files. Hopefully, this is something we can add support for in the future.

Thanks,
Rich

Hi @krampusdecorous_7076,

We have created a ticket, PG-2233, to fix this issue in ProGet. We are not exactly sure what is causing the issue as of yet, but we are able to recreate the issue and working on a fix. We are currently targeting Nov 18th for a release date on the fix.

Thanks,
Rich

Hi @jameswiseman76_4902,

I think you are looking for the npm search API. You would make a call to your npm feed using http://{proget-server}/npm/{feedName}/-/v1/search?text={Package}. It also looks like http://{proget-server}/npm/{feedName}/-/all will show you all local packages (it does not include remote packages from connectors) stored in ProGet. Please also note that the search API returns results in a paged fashion, you will need to use the from query string parameter to offset the results to get the following pages.

I hope this helps! Please let us know if you have any other questions.

Thanks,
Rich

Hi @andrewwickham_1641,

Thanks for giving us an update and letting us know that fixed your issue.

Thanks,
Rich

Hi @torgabor_4445 and @sdohle_3924,

I dug deeper into GitLab connectors and it looks like there are two ProGet issues here and a configuration issue.

1. PG-2210: GitLab does not return the "time" property when it returns package metadata. This causes ProGet to fail to return any packages.
2. PG-2211: There is a display issue when entering only a password with bearer authentication. The UI will show anonymous, even though it will use the token.
3. Configuration Issue: here is what you will need to configure a GitLab connector.
   • Connector URL: https://gitlab.com/api/v4/projects/12345/packages/npm/
   • User Name: leave blank
   • Password: Generate a personal access token with API access and set that value there.
   • Authentication: Bearer
   • Advanced Options: Check exact package match only. GitLab does not support partial searching and/or listing

I have added fixes for PG-2210 and PG-2211 and they will release tomorrow in ProGet 2022.9. Once you upgrade to 2022.9 and make the configuration updates, you should be able to pull GitLab packages via a connector.

Thanks,
Rich

Hi @torgabor_4445,

Can you please try something for me?

• Leave the username blank
• Put your token in for the password
• Use Bearer authentication
• Change your URL to https://gitlab.com/api/v4/projects/12345/packages/npm/:_authToken

If that does not fix it, I have another idea, but I will need to check a few more things offline.

Thanks,
Rich

Hi @marc-ledent_9164,

What version of BuildMaster do you have installed? Also what extensions are you trying to update that are currently giving you that error?

Thanks,
Rich

Hi @tkolb_7784,

If you are hosting on a windows machine, the easiest solution right now is to migrate your server to use IIS and then add an SSL binding to your site. If you do not want to purchase a new certificate and the self-signed certificate is too much work, you can use Let's Encrypt and configure it via winacme.

If you do not want to use IIS, then you will need to use a reverse proxy to handle SSL connections. Any reverse proxy can be used and a pretty simple one to configure is stunnel. Most reverse proxies can also be used with Let's Encrypt.

If you are hosting via Linux (Docker), then you will need to use a reverse proxy to handle SSL connections. We have a documentation page for different Linux-based reverse proxies including an example for setting up NGINX. These reverse proxies also support Let's Encrypt also.

Please let me know if you have any questions.

Thanks,
Rich

Hello,

This is related to a known issue that's been addressed in ProGet 6.0.19 and ProGet 2022.5. So, your best bet is to upgrade and the issue will become resolved :)

This is related to a few packages that have exceeded 2.2 billion downloads:

• Microsoft.NETCore.Platforms
• Microsoft.Extensions.Primitives
• Microsoft.Extensions.DependencyInjection.Abstractions

If the upgrade is impossible/difficult immediately, you can disable the connector as a workaround. Alternatively, you could block those packages with a connector filter and then upload them to your feed so that the counts won't come through the connector.

Thanks,
Rich

Hi @mike_2282,

Thank you for the feedback. I have made some changes to the documentation to address most of the issues you have brought up. Thanks again for the feedback!

Thanks,
Rich