Describe the bug

When running "bi npm install" it does not capture the dependencies of a package.json file but instead reports an empty project.

During debugging I found there is a check (Line 67 of npm.go) to see if "collectBuildInfo" is set on the NPM-module.
This field is never set via the CLI and therefore no dependency information is gathered.

Reproduction steps

Run "bi npm install" in a directory with a package.json file.

Expected behavior

I would expect to either have an option to indicate that I want to include the dependencies or it should be enabled by default.

Operating system type and version

Windows 10

Describe the bug

In

             log.Warn("The following dependencies will not be included in the build-info, because they are missing in the npm cache: '" + strings.Join(otherMissingDeps, ",") + "'.\nHint: Try to delete 'node_models' and/or 'package-lock.json'.")

Current behavior

Warning logged "Hint: Try to delete 'node_models' and/or 'package-lock.json'"

Reproduction steps

No response

Expected behavior

No response

Operating system type and version

Linux

Is your feature request related to a problem? Please describe.
Following #59, it seems like the populateRequestedByField logic is duplicated, and can be found in the golang, NuGet, and python build-info creation.

Describe the solution you'd like to see
I suggest adding a utility that will be used by all the above modules to prevent code duplication.

Describe alternatives you've considered

Additional context

Describe the bug

Bi client cannot be launched on macos Monterey as we got this window screen

Current behavior

See screenshot

Reproduction steps

• Download bi on mac
• cp bi to /usr/local/bin
• chmod +x /usr/local/bin/bin
• launch bi

Expected behavior

It should be executed ;-)

Operating system type and version

macOS 12.6.3

Is your feature request related to a problem? Please describe.
It's impossible to test PRs for extractors without also building a custom CLI and using this. But then, what are you testing? Any issue during the CLI build to validate and test the extractor build makes it harder to do a proper job.

Take this case:
I found a (in my eyes) bug in the extractor implementation for Maven. It introduces a 'dummy' repository but this is causing numerous issues with Maven plugins that cannot take this kind of repository into account.

So I opened a PR in an attempt to resolve this: jfrog/build-info#683
But this introduced a bug and needed to be reverted.
This is not only annoying for me to have to revisit the PR again, but also other customers affected by the introduced bug.
It was easy to resolve and a new PR was opened to address the bug introduced jfrog/build-info#715

I'm confident that the bug would not have been introduced if it was easier to test the custom version of the extractor.

Describe the solution you'd like to see
I would like to be able to override the version of the extractor used during Maven builds so I can use or test a custom version of the extractor.

Currently you can provide a different remote server to download the extractor from, but the version is hardcoded at https://github.com/jfrog/build-info-go/blob/a6ed2e89a5bf16feff10be3333c5f69821b0b903/build/maven.go#LL21C29-L21C29
But it would be great if this version can be overridden by an environment variable just like the remote server can be overridden.

Describe alternatives you've considered
The only alternative is to also build a custom CLI version to test the custom extractor version, which is not really an alternative if you ask me.

Additional context
See also opened support ticket

Describe the bug

During the yarn build the error with memory appears.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xc3332e]

Current behavior

There should be any error.

Reproduction steps

`Starting: JFrog YARN install

Task : JFrog CLI V2
Description : Run your own JFrog CLI command.
Version : 1.6.1
Author : JFrog
Help : More Information

Found tool in cache: jf 2.37.1 x64
Running jfrog-cli from /opt/hostedtoolcache/jf/2.37.1/x64/jf
JFrog CLI version: 2.37.1
Executing JFrog CLI Command:
/opt/hostedtoolcache/jf/2.37.1/x64/jf c add "Marvin3.VBtOModule.Client.JFrog.Yaml_20230518.2_jfrog_cli_cmd_1684404202880" --url="https://artifactory.skoda.vwgroup.com/" --interactive=false --access-token-stdin
Executing JFrog CLI Command:
/opt/hostedtoolcache/jf/2.37.1/x64/jf c use "Marvin3.VBtOModule.Client.JFrog.Yaml_20230518.2_jfrog_cli_cmd_1684404202880"
12:03:22 [Info] Using server ID 'Marvin3.VBtOModule.Client.JFrog.Yaml_20230518.2_jfrog_cli_cmd_1684404202880' (https://artifactory.skoda.vwgroup.com/)
Executing JFrog CLI Command:
/opt/hostedtoolcache/jf/2.37.1/x64/jf yarn-config --repo-resolve=front-npm-virtual
12:03:22 [Info] yarn build config successfully created.
Executing JFrog CLI Command:
/opt/hostedtoolcache/jf/2.37.1/x64/jf yarn install --no-immutable --build-name=marvin-external-app --build-number=20230518.2
12:03:23 [Info] Running Yarn...
12:03:24 [Info] Preparing for dependencies information collection... For the first run of the build, the dependencies collection may take a few minutes. Subsequent runs should be faster.
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0000: └ Completed
➤ YN0000: Done in 0s 80ms
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xc3332e]

goroutine 1 [running]:
github.com/jfrog/build-info-go/build.(*YarnModule).appendDependencyRecursively(0xc0005240d8?, 0xc00033f410?, {0x1af2b70?, 0xc0005240d8?, 0xc00065ae70?}, 0x7fcf1c3b79b8?, 0xc00031d590?)
/root/go/pkg/mod/github.com/jfrog/[email protected]/build/yarn.go:97 +0x2e
github.com/jfrog/build-info-go/build.(*YarnModule).getDependenciesMap(0xc000335340)
/root/go/pkg/mod/github.com/jfrog/[email protected]/build/yarn.go:91 +0x93
github.com/jfrog/build-info-go/build.(*YarnModule).Build(0xc000335340)
/root/go/pkg/mod/github.com/jfrog/[email protected]/build/yarn.go:72 +0x85
github.com/jfrog/jfrog-cli-core/v2/artifactory/commands/yarn.(*YarnCommand).Run(0xc0003646e0)
/root/go/pkg/mod/github.com/jfrog/jfrog-cli-core/[email protected]/artifactory/commands/yarn/yarn.go:108 +0x365
github.com/jfrog/jfrog-cli-core/v2/common/commands.Exec({0x125f8b0?, 0xc0003646e0})`

Expected behavior

build the yarn.

Operating system type and version

JFrog CLI version: 2.37.1

In the JSON schema, in Line 99, the properties object is closed while modules and issues are omitted.

Is this correct?

When use this schema in a code generator, the code is generated without modules and issues types and properties.

If I apply the following patch

98d97
<     }
209c208,211
<         "required": ["name", "version"],
---
>           "required": [
>             "name",
>             "version"
>           ],
235a238
>               }

then code will generated including modules and issues.

Is this intentional or a bug?

Describe the bug

NuGet 3.4 introduced a change whereby leading zeroes are removed from version numbers when restoring/packing (Normalized version numbers).
When this project searches for package in cache it should also search for it without these leading zeros.

Current behavior

The exact version listed in the .csproj file is expected and not found, which produced the following warning:

[🟠Warn] The following NuGet package <package> with version <version> was not found in the NuGet cache <path to cache>. Skipping adding this dependency to the build info. This might be because the package already exists in a different NuGet cache, possibly the SDK's NuGetFallbackFolder cache. Removing the package from this cache may resolve the issue.

Reproduction steps

Restore a project that has such a version while collecting build info, the warning should be logged.

Operating system type and version

NuGet Version: 6.8.0.131

Describe the bug
bi gradle report back conflicts with the task invocation ‘’artifactoryPublish’.’ I suggest not invoking the Task ‘aP’ instead use the full qualified name.

To Reproduce
https://github.com/jreleaser/jreleaser.git
gradle build
bi gradle build

Expected behavior
gradle successfully builds the project

➜  jreleaser git:(main) ✗ git remote -v 
origin	https://github.com/jreleaser/jreleaser.git (fetch) 
origin	https://github.com/jreleaser/jreleaser.git (push) 
➜  jreleaser git:(main) ✗ gm build 
Using gradle at '/Users/ixchelruiz/Projects/oss/jreleaser/jreleaser/gradlew' to run buildFile '/Users/ixchelruiz/Projects/oss/jreleaser/jreleaser/build.gradle': 
Starting a Gradle Daemon (subsequent builds will be faster) 
[versioning] WARNING - the working copy has unstaged or uncommitted changes. 
[build-enforcer] Invalid bytecodeVersion for jackson-core-2.13.1.jar (com.fasterxml.jackson.core:jackson-core:2.13.1) : META-INF/versions/11/module-info.class: expected 55, but was 53 
[build-enforcer] Invalid bytecodeVersion for jackson-databind-2.13.1.jar (com.fasterxml.jackson.core:jackson-databind:2.13.1) : META-INF/versions/11/module-info.class: expected 55, but was 53 
[build-enforcer] Invalid bytecodeVersion for jackson-dataformat-cbor-2.13.1.jar (com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:2.13.1) : META-INF/versions/11/module-info.class: expected 55, but was 53 
[build-enforcer] Invalid bytecodeVersion for jackson-dataformat-toml-2.13.1.jar (com.fasterxml.jackson.dataformat:jackson-dataformat-toml:2.13.1) : META-INF/versions/11/module-info.class: expected 55, but was 53 
[build-enforcer] Invalid bytecodeVersion for jackson-dataformat-yaml-2.13.1.jar (com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.13.1) : META-INF/versions/11/module-info.class: expected 55, but was 53 
 
> Task :jreleaser-templates:test 
✔ Test org.jreleaser.templates.VersionDecoratingWriterTest [Tests: 2/2/0/0] [Time: 0,391 s] 
✔ Test Gradle Test Run :jreleaser-templates:test [Tests: 2/2/0/0] 
 
> Task :mail-java-sdk:test 
✔ Test org.jreleaser.sdk.mail.MessageMailCommandTest [Tests: 1/1/0/0] [Time: 1,582 s] 
✔ Test Gradle Test Run :mail-java-sdk:test [Tests: 1/1/0/0] 
 
> Task :twitter-java-sdk:test 
✔ Test org.jreleaser.sdk.twitter.UpdateStatusTwitterCommandTest [Tests: 2/2/0/0] [Time: 9,486 s] 
✔ Test Gradle Test Run :twitter-java-sdk:test [Tests: 2/2/0/0] 
 
> Task :sdkman-java-sdk:test 
✔ Test org.jreleaser.sdk.sdkman.MinorReleaseSdkmanCommandTest [Tests: 2/2/0/0] [Time: 10,038 s] 
✔ Test org.jreleaser.sdk.sdkman.MajorReleaseSdkmanCommandTest [Tests: 2/2/0/0] [Time: 0,375 s] 
✔ Test org.jreleaser.sdk.sdkman.AnnounceSdkmanCommandTest [Tests: 2/2/0/0] [Time: 0,187 s] 
✔ Test org.jreleaser.sdk.sdkman.DefaultSdkmanCommandTest [Tests: 2/2/0/0] [Time: 0,180 s] 
✔ Test org.jreleaser.sdk.sdkman.ReleaseSdkmanCommandTest [Tests: 4/4/0/0] [Time: 0,455 s] 
 
> Task :slack-java-sdk:test 
✔ Test org.jreleaser.sdk.slack.SlackMessageTest [Tests: 2/2/0/0] [Time: 10,370 s] 
✔ Test Gradle Test Run :slack-java-sdk:test [Tests: 2/2/0/0] 
 
> Task :sdkman-java-sdk:test 
✔ Test Gradle Test Run :sdkman-java-sdk:test [Tests: 12/12/0/0] 
 
> Task :jreleaser-gradle-plugin:compileGroovy 
WARNING: An illegal reflective access operation has occurred 
WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/Users/ixchelruiz/.gradle/wrapper/dists/gradle-6.9-bin/2ecsmyp3bolyybemj56vfn4mt/gradle-6.9/lib/groovy-all-1.3-2.5.12.jar) to method java.util.AbstractCollection.hugeCapacity(int) 
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass 
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations 
WARNING: All illegal access operations will be denied in a future release 
 
> Task :zulip-java-sdk:test 
✔ Test org.jreleaser.sdk.zulip.ZulipMessageTest [Tests: 2/2/0/0] [Time: 6,432 s] 
✔ Test Gradle Test Run :zulip-java-sdk:test [Tests: 2/2/0/0] 
 
> Task :jreleaser-model:test 
✔ Test org.jreleaser.model.PlatformTest [Tests: 4/4/0/0] [Time: 0,345 s] 
✔ Test Gradle Test Run :jreleaser-model:test [Tests: 4/4/0/0] 
 
> Task :jreleaser-gradle-plugin:groovydoc 
Trying to override old definition of task fileScanner 
 
-------------------------------------------------------------------- 
43 projects                                      CONF        EXEC    
-------------------------------------------------------------------- 
: .................................. SUCCESS [  0,230 s] [  0,002 s]  
:artifactory-java-sdk .............. SUCCESS [  0,016 s] [  0,228 s]  
:codeberg-java-sdk ................. SUCCESS [  0,014 s] [  0,195 s]  
:disco-java-sdk .................... SUCCESS [  0,031 s] [  0,346 s]  
:discord-java-sdk .................. SUCCESS [  0,008 s] [  0,156 s]  
:genericgit-java-sdk ............... SUCCESS [  0,011 s] [  0,139 s]  
:git-sdk ........................... SUCCESS [  0,010 s] [  0,229 s]  
:gitea-java-sdk .................... SUCCESS [  0,023 s] [  0,217 s]  
:github-java-sdk ................... SUCCESS [  0,013 s] [  0,133 s]  
:gitlab-java-sdk ................... SUCCESS [  0,007 s] [  0,167 s]  
:gitter-java-sdk ................... SUCCESS [  0,008 s] [  0,134 s]  
:google-chat-java-sdk .............. SUCCESS [  0,009 s] [  0,114 s]  
:http-upload-java-sdk .............. SUCCESS [  0,009 s] [  0,161 s]  
:java-sdk-commons .................. SUCCESS [  0,012 s] [  0,201 s]  
:jdks-gradle-plugin ................ SUCCESS [  0,155 s] [  0,257 s]  
:jdks-maven-plugin ................. SUCCESS [  0,234 s] [  0,284 s]  
:jreleaser ......................... SUCCESS [  0,115 s] [ 21,023 s]  
:jreleaser-ant-tasks ............... SUCCESS [  0,032 s] [  5,029 s]  
:jreleaser-assemblers .............. SUCCESS [  0,010 s] [  0,083 s]  
:jreleaser-config-json ............. SUCCESS [  0,009 s] [  0,130 s]  
:jreleaser-config-toml ............. SUCCESS [  0,011 s] [  0,100 s]  
:jreleaser-config-yaml ............. SUCCESS [  0,014 s] [  0,107 s]  
:jreleaser-engine .................. SUCCESS [  0,010 s] [  0,197 s]  
:jreleaser-gradle-plugin ........... SUCCESS [  0,028 s] [ 33,230 s]  
:jreleaser-maven-plugin ............ SUCCESS [  0,057 s] [  0,407 s]  
:jreleaser-model ................... SUCCESS [  0,016 s] [ 25,310 s]  
:jreleaser-templates ............... SUCCESS [  0,022 s] [  5,900 s]  
:jreleaser-tool-provider ........... SUCCESS [  0,240 s] [ 01:13  m]  
:jreleaser-tools ................... SUCCESS [  0,016 s] [  0,123 s]  
:jreleaser-utils ................... SUCCESS [  0,013 s] [  0,367 s]  
:jreleaser-workflow ................ SUCCESS [  0,012 s] [  0,142 s]  
:mail-java-sdk ..................... SUCCESS [  0,011 s] [  6,855 s]  
:mastodon-java-sdk ................. SUCCESS [  0,009 s] [  0,067 s]  
:mattermost-java-sdk ............... SUCCESS [  0,006 s] [  0,135 s]  
:s3-java-sdk ....................... SUCCESS [  0,013 s] [  0,291 s]  
:sdkman-java-sdk ................... SUCCESS [  0,009 s] [ 17,177 s]  
:slack-java-sdk .................... SUCCESS [  0,008 s] [ 16,624 s]  
:teams-java-sdk .................... SUCCESS [  0,007 s] [  0,083 s]  
:telegram-java-sdk ................. SUCCESS [  0,007 s] [  0,095 s]  
:tool-sdk .......................... SUCCESS [  0,011 s] [  0,190 s]  
:twitter-java-sdk .................. SUCCESS [  0,012 s] [ 15,586 s]  
:webhooks-java-sdk ................. SUCCESS [  0,008 s] [  0,055 s]  
:zulip-java-sdk .................... SUCCESS [  0,008 s] [ 12,831 s]  
-------------------------------------------------------------------- 
43 projects executed 
-------------------------------------------------------------------- 
 
Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. 
Use '--warning-mode all' to show the individual deprecation warnings. 
See https://docs.gradle.org/6.9/userguide/command_line_interface.html#sec:command_line_warnings 
 
BUILD SUCCESSFUL in 1m 44s 
415 actionable tasks: 40 executed, 375 up-to-date 
➜  jreleaser git:(main) ✗ ./bi gradle build 
[Info] Running gradle... 
[Info] Running gradle command: /Users/ixchelruiz/.sdkman/candidates/gradle/current/bin/gradle --init-script /Users/ixchelruiz/.build-info/gradle/4.26.0/gradle.init aP 
[versioning] WARNING - the working copy has unstaged or uncommitted changes. 
[build-enforcer] Invalid bytecodeVersion for jackson-core-2.13.1.jar (com.fasterxml.jackson.core:jackson-core:2.13.1) : META-INF/versions/11/module-info.class: expected 55, but was 53 
[build-enforcer] Invalid bytecodeVersion for jackson-databind-2.13.1.jar (com.fasterxml.jackson.core:jackson-databind:2.13.1) : META-INF/versions/11/module-info.class: expected 55, but was 53 
[build-enforcer] Invalid bytecodeVersion for jackson-dataformat-cbor-2.13.1.jar (com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:2.13.1) : META-INF/versions/11/module-info.class: expected 55, but was 53 
[build-enforcer] Invalid bytecodeVersion for jackson-dataformat-toml-2.13.1.jar (com.fasterxml.jackson.dataformat:jackson-dataformat-toml:2.13.1) : META-INF/versions/11/module-info.class: expected 55, but was 53 
[build-enforcer] Invalid bytecodeVersion for jackson-dataformat-yaml-2.13.1.jar (com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.13.1) : META-INF/versions/11/module-info.class: expected 55, but was 53 
 
FAILURE: Build failed with an exception. 
 
* What went wrong: 
Task 'aP' is ambiguous in root project 'jreleaser'. Candidates are: 'activeProfiles', 'artifactoryPublish'. 
 
* Try: 
Run gradle tasks to get a list of available tasks. Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. 
 
* Get more help at https://help.gradle.org 
 
Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. 
Use '--warning-mode all' to show the individual deprecation warnings. 
See https://docs.gradle.org/6.9/userguide/command_line_interface.html#sec:command_line_warnings 
 
BUILD FAILED in 8s 
exit status 1 

Describe the bug

I just updated from 1.6.0 to 1.7.0 and now get the following error when I compile my go project:

# github.com/jfrog/build-info-go/entities
C:\Users\...\go\pkg\mod\github.com\jfrog\[email protected]\entities\buildinfo.go:209:82: cannot use &cdxDepsSlice (value of type *[]cyclonedx.Dependency) as type *[]string in struct literal

Current behavior

Build fails

Reproduction steps

Run go get -u on a project that uses github.com/jfrog/jfrog-client-go which updates build-info-go.
Try to build the updated project.

Expected behavior

The build should work.

Operating system type and version

Windows and Linux

Is your feature request related to a problem? Please describe.

We currently work in a sealed off environment with our local Artifactory that mirrors external sources for us. There is no direct connection to the outside otherwise. We're trying to build a docker container containing the bi client, but it currently hardcodes the dependency repo - https://github.com/jfrog/build-info-go/blob/main/utils/dependenciesutils.go#L37

Describe the solution you'd like to see

It would be nice to have the dependency repo as a parameter we can set.

Describe alternatives you've considered

There are no workarounds because the value is hardcoded in the source file.

Is your feature request related to a problem? Please describe.

We use https://pnpm.io for dependency management. It is nearly compatible with npm, but a pnpm workspace adds some capabilities which cause it to fail when npm is used. We would like to add the ability to generate build info for pnpm workspaces.

Describe the solution you'd like to see

Similar to NPM, this feature would detect pnpm workspaces and adjust the command to a compatible one

Describe alternatives you've considered

I'm using the jf cli to audit my pnpm workspace/ similar to an npm package with a package.json. Being able to override the commands that are used to list dependencies directly might allow something like this and other npm package manager replacements.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.

We are examining the output of several SBOM producers. We noticed that the cyclonedx json file changes between different runs for the same project with build info go. The ideal behavior is deterministic.

Describe the solution you'd like to see

You might sort the lists in your json before writing them as json files. Any stable sorting will do.

Describe the bug

Poetry build is making very strange assumptions about the nature of the virtualenv which poetry creates.

Current behavior

As far as I'm aware I have a completely normal poetry setup. I'm using pyenv to manage my virtual environments. When I run bi poetry install i get the following output:

[Error] failed extracting python site package form the following virtual env "/home/rvodden/.pyenv/versions/3.10.7/envs/library"

Reproduction steps

install pyenv
create a virtualenv using pyenv
create a poetry project in that virtualenv
run bi poetry install

Expected behavior

I'd expect bi to use correct semantics to establish the location of site-packages. For example, this command:

poetry run python -c 'import site; print(site.getsitepackages())'

will reliably report the location of site-packages. I don't really follow the logic which is employed to extract the site-packages location here:
https://github.com/jfrog/build-info-go/blob/main/utils/pythonutils/poetryutils.go#L211-L217

It looks to be making very specific assumptions about how virtualenvs are arranged which at first glance would appear to be more likely to be incorrect than correct in the majority of circumstances

Operating system type and version

ubuntu 20.04 i686

The title says it all: I have been using the jfrog tool to interact with an artifactory instance, including deploying artifacts from build pipelines and thus generating build-related metadata.
Does this tool here supersede some of the functionality offered by jfrog ? Or is this merely offering an alternative interface ?

Hey All,
I see the PR merged -> #172

but this code https://github.com/jfrog/build-info-go/blob/main/build/yarn.go#L163L166
is preventing from using yarn older version. Is this intentional??
Would a PR be accepted?? I do not see a contributor guide so was not sure.

Is your feature request related to a problem? Please describe.
Supporting the wrappers of maven and gradle is really needed as wrappers allows us to run a build with a specified version and settings without the build tool installation.

Describe the bug
It looks like the start time, for example: 2022-02-24T08:12:20.013+0200 does not comply the pattern of ^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}.\\d{3}(Z|[+-]\\d{4})$.

To Reproduce
Generate build-info and validate schema.

Expected behavior
Build info validated successfully.

Screenshots

Additional context
I used https://www.jsonschemavalidator.net to validate the schema.

I deployed an maven artifact and corresponding docker image to Artifactory through a standard pipeline, and I can fetch the build by using API:
https://<domain_name>/artifactory/api/build/<build_name>/<build_number>
But I can not find that repo which contains docker image (except .buildInfo.modules[0].properties."docker.image.tag").
So I do not understand: repoName is not a part of buildinfo ?
Who can explain for me ?
Thank you.

Is your feature request related to a problem? Please describe.
Currently, the schema exists only in the README. This way it is not testable. Also, users can't verify their own build-infos.

Describe the solution you'd like to see
Move the schema from README to a file.

Describe alternatives you've considered
Nope.

Additional context
File Spec schema and tests examples: https://github.com/jfrog/jfrog-cli/tree/v2/schema
File Spec schema in the SchemaStore: https://raw.githubusercontent.com/jfrog/jfrog-cli/v2/schema/filespec-schema.json

Is your feature request related to a problem? Please describe.
We can only use the CLI for yarn >= V2.4.0 and would like to request for yarn V1 support.

Describe the solution you'd like to see
Support Yarn V1

Describe alternatives you've considered
None yet. Still waiting.

Additional context
N/A

I would like to generate the build info for PHP composer projects

Is your feature request related to a problem? Please describe.
I develop C/C++ applications and my build dependencies are installed by the system package manager, but I would still like to track those using build-info.

Describe the solution you'd like to see
A wrapper mode similar to the one for pip would be nice.

Describe alternatives you've considered
It may also be possible to implement as a yum plugin.

Hi folks,

Thank you for your library. I have some suggestions to improve it.

Is your feature request related to a problem? Please describe.

I'm aware that you need to send a buildinfo to stdout and all other log messages to stderr.
But sometimes it's difficult to debug npm commands and understand what happens behind the scenes.

So, is it possible to send the stdout command result when commands go wrong ?

Try with a failed npm command that returns an error for example. Npm log messages are not very relevant on stderr. Sometimes there is useful information on stdout, but this library doesn't print it.

I have no idea, if it works the same for the other build tools (mvn, go, etc.)

Describe the solution you'd like to see

Maybe you should try to send the stdout command result in case of an error in the RunNpmCmd function before returning the error.

Describe alternatives you've considered
/

Additional context
/

Hi,
Is there a build command available to pass arguments with my environment URI? The utils/dependenciesutils.go is hard coded with https://releases.jfrog.io/artifactory/oss-release-local/ at line 41.

Example command to build 'bi':
./buildscripts/build.sh --site='https://pzasure.jfrog.io' --mvn='krishnam-mvn-virtual' --py="krishnam-pypi-virtual'

Another option is to read the artifactory path from Maven settings.xml using command mvn help:effective-settings

In the current folder structure, github.com/jfrog/build-info-go/build package contains all the logic to calculate build-info to all build tools (Maven, npm, Go ....).
One of go test ... arg is a package name and not an individual test file. As a result, we cant run specific build tool tests but all packages.
To overcome this problem, We need to split it into different build tools packages

Different projects generate quite different types of build metadata, from test reports to generated documentation.
It would be great if the build-info that is being pushed to artifactory would be extensible to allow for the above to be included.

For smaller data such items may be embedded into the build-info structure (and the containing artifactory repo), while for larger items, this may involve setting up additional repos with new artifacts being referenced by the build-info (similar to "dependencies").

Finally (though that is more a feature request for Artifactory itself), it would be great if the Artifactory web portal had built-in viewers for such artifact types, a way to navigate through test reports, generated HTML docs, etc.