Navigation

    Inedo Community Forums

    Forums

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    1. Home
    2. caterina
    C
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    caterina

    @caterina

    2
    Reputation
    64
    Posts
    2
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online

    caterina Follow

    Best posts made by caterina

    • RE: pgscan: lockfileVersion 3 for npm dependencies not supported

      Hi @atripp

      I think packages has to be iterated instead. I haven't seen dependencies beneath packages.
      Further, the "empty" Key has to be ignored as it stands for the root project:
      f22cf0f2-b7e6-4bc6-98cd-3c19e983f635-image.png

      Maybe a little bit parsing would be necessary.
      In lockfileVersion 2 a dependency was listed like this:
      dae966e2-b003-4624-a25e-2b0e06d24b77-image.png
      In lockfileVersion 3 it looks like this:
      5302a66c-d015-4f87-afb6-2ed097e30f52-image.png

      If desired, we can also upload package-lock.json files for testing via MyInedo.

      posted in Support
      C
      caterina
    • pgutil: Projects in .slnx are not found

      Hi all,

      we tested the .slnx support of pgutil and noticed that pgutil can only detect projects that are a direct child of the root element.
      If the .slnx structure is more complex, projects are not found.

      E.g:
      Both projects are detected by pgutil:
      0f2927c0-6de2-46a3-bc55-013c39489a7e-image.png

      No projects are being found:
      76eb97ea-f5c7-41bc-a3ff-42e24f7d49d1-image.png

      Since it was a quick fix, we created a pull request for it:
      https://github.com/Inedo/pgutil/pull/25

      Please have a look at it and let us know if you can confirm the behavior.

      Thanks
      Caterina

      posted in Support
      C
      caterina

    Latest posts made by caterina

    • pgutil: Projects in .slnx are not found

      Hi all,

      we tested the .slnx support of pgutil and noticed that pgutil can only detect projects that are a direct child of the root element.
      If the .slnx structure is more complex, projects are not found.

      E.g:
      Both projects are detected by pgutil:
      0f2927c0-6de2-46a3-bc55-013c39489a7e-image.png

      No projects are being found:
      76eb97ea-f5c7-41bc-a3ff-42e24f7d49d1-image.png

      Since it was a quick fix, we created a pull request for it:
      https://github.com/Inedo/pgutil/pull/25

      Please have a look at it and let us know if you can confirm the behavior.

      Thanks
      Caterina

      posted in Support
      C
      caterina
    • RE: pgutil: Can not find ConsoleMan

      Hi @stevedennis,

      thank you.
      It looks like you guys created a seperate repo for ConsoleMan:
      https://github.com/Inedo/ConsoleMan

      I guess this one creates the NuGetPackage?

      Thanks,
      Caterina

      posted in Support
      C
      caterina
    • pgutil: Can not find ConsoleMan

      Hi all,

      I got the latest source code of pgutil and wanted to compile it.
      Unfortunately, I get the error that the package 'ConsoleMan' can not be found.
      I know that there was the project 'ConsoleMan' in previous versions but it seems like it has been removed.

      Is there something special I have to do to build the solution? Maybe I am missing something.

      Thanks
      Caterina

      posted in Support
      C
      caterina
    • RE: ProGet: NPM-Package-Promotion loses Tags

      Hi @atripp,

      so as far as I understood it, one should not tag packages with the latest Tag themself, npm handels that tag.
      If no specific tag is given, "npm publish" gives the latest tag to the last uploaded version. And if a new version is uploaded without a specific tag, this version gets the latest tag and it is being removed from the former package.

      But we would also lose the tags if we manually tag them. Maybe we want to separate between testversions and productionversions with tags. Just a thought. We also lose this tag during promotion.

      So maybe you can not only promote the latest tag but all tags? To lose information about a package is always bad I guess.

      Tanks,
      Caterina

      posted in Support
      C
      caterina
    • ProGet: NPM-Package-Promotion loses Tags

      Hi all,

      we noticed that some of our npm packages are missing its tags.
      Having a closer look at that issue we noticed that the tags are lost during promotion.
      Usually, we upload our packages with the tag "latest" to a testfeed. After testing we promote the package to our live feed. In the testfeed we can see the tag, in the live feed the tag is missing.

      Testfeed:
      a1600515-6298-483b-9e5d-3dd1b21ff717-image.png
      LiveFeed:
      c5f2412a-a4dc-480c-a340-8f1f06e35a98-image.png

      We usually promote packages using the api but it also happens when we manually promote packages.

      We also noticed that manually adding a npm package is not saving the tag. In the upload window you already suggest the tag "latest" so we just leave it:
      a2ee048d-ca24-4548-a3d9-67c56116c9d7-image.png
      But the tags are empty after the upload:
      3ea76682-1afe-4796-ad32-3044f19c9f5c-image.png

      We noticed this behavior because we are using "npm outdated" to check if there are newer versions of installed npm packages. This command scans registries for the package with the tag "latest" but we never got any suggestions for our packages.

      Can you verify this behavior?

      Thanks,
      Caterina

      posted in Support
      C
      caterina
    • RE: ProGet: License Policies - General questions

      Hi @rhessinger,

      thank you for pointing out the feed features. License detection was not enabled in the feed I used for testing. After activating the feature the package is being reanalyzed correctly and the global policy is being used.

      Thanks
      Caterina

      posted in Support
      C
      caterina
    • RE: ProGet: License Policies - General questions

      Hi Steve,

      thanks for clarifying things.
      I was just wondering: If I create a feed policy the UI looks like that:
      598cd474-3f53-454d-9f76-8822157f73ab-image.png
      I set "PolyForm-Noncommercial-1.0.0" as compliant for the feed but it is noncompliant in the global policy. The noncomliant part of my global policy is crossed out completely. Does that mean it is ignored? Or is that a UI issue because only "PolyForm-Noncommercial-1.0.0" should be crossed out?

      I also tried to use the Reanalyze Task with the following result (The package has the license "PolyForm-Noncommercial-1.0.0"):
      In the feed "NuGet" (the original feed of the package) I see this log:
      74330f69-f720-4115-8ca1-1d2da1ae4c27-image.png
      If I reupload/promote this package to another feed and reanalyze it I see this log:
      f780452b-4c06-4aee-ac41-3144ac960b80-image.png
      It looks like the global policy is not being considered? A policy is being found but it does not seem to be applied?

      Maybe you can tell me more about that behavior.

      Thanks
      Caterina

      posted in Support
      C
      caterina
    • ProGet: License Policies - General questions

      Hi all,

      we tried to work on global and feed policies and we do have some questions regarding this topic. We are currently working on Version 2024.38.

      If a feed policy is active, will the global policy also be evaluated when analyzing the packages in this feed? Or will the global policy completely be ignored?

      Let's work with an example for our next question:
      I have a feed called "NuGet". This feed contains the package "EPPlus 6.0.6" which has the license "PolyForm-Noncommercial-1.0.0".
      In my NuGet policy i set this license as "Compliant" and in my Global policy i set this license to "Noncompliant".
      Is it correct to assume that the package will by Compliant in the feed "NuGet" but should be Noncompliant in any other feed?
      Because if I upload the package to another feed (which has no specific feed poilcy) the package is listed as compliant:
      4cd86bea-20c8-4b60-9c05-1b3582fe56d9-image.png
      If I remove the feed policy, this package is shown as Noncompliant in this specific feed. But if I reupload or promote it to another feed it is shown as Compliant. So maybe this has nothing to do with the policies, but not sure.

      In general we are just curious about how the policies interact with each other.

      Thanks
      Caterina

      posted in Support
      C
      caterina
    • SBOM: Project-type is missing

      Hi all,

      we are still evaluating if we should move from ProGet 2023 to ProGet 2024 and we noticed some missing information:
      We are currently using pgscan to upload the SBOMs for our projects. We also provide the project-type (usually "application" or "library"). We provide this information because we are actively working with it. The SBOM on ProGet 2023 looks like this:
      3aea1561-fa50-498b-95dc-3e7894b805b3-image.png

      The SBOM of the same project after migrating to ProGet 2024 looks like this:
      0bcb3fba-3edd-40ca-afe5-61a76582224e-image.png

      We lost the information about the project type which is not acceptable for us.

      I thought that it might be a problem of the migration, so I explicitly used pgscan to upload an SBOM directly to ProGet 2024. Same problem. the project-type is Null. Then I thought, ok maybe it is a problem with pgscan in combination with ProGet 2024 so I used pgutil to upload an SBOM. Same problem. We lose the information about the project type.

      Also the timestamp behaves different. The timestamp on ProGet 2023 is the timestamp of the creation of the SBOM and is always the same. The timestamp on ProGet 2024 is the timestamp of the download of the SBOM and is different each time I download the same SBOM.

      Can you confirm this behavior? Or am I doing something wrong maybe?
      Unfortunately, losing this information will definitly block our migration.

      Thanks,
      Caterina

      posted in Support
      C
      caterina
    • ProGet 2024: SCA & Build Restrictions

      Hi,

      I have a question regarding the SCA & Build Restrictions of ProGet 2024 in the Basic edition.
      We are still using ProGet 2023 because of the limitation for 1000 active builds.
      Is this limitation only for the Package Analyzer?
      Or will there be an error once i have 1000 active builds and try to create one more?
      Or am I able to upload sboms for more than 1000 builds and have the information about used components but am not able to scan for issues?

      Where exactly would this limit hit us? Because we do have more than 1000 active builds and there are new ones each day.
      Would an upgrade be possible? Or is the limitation for 1000 active builds a hard limit?

      Thanks,
      Caterina

      posted in Support
      C
      caterina