Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generated scan results should show the version of scancode-toolkit that was used #670

Open
DennisClark opened this issue Apr 13, 2023 · 8 comments
Labels
enhancement New feature or request

Comments

@DennisClark
Copy link

I was not able to find in the generated scan results the version of scancode-toolkit that was used in a recent scan from SCIO 32.1.0. That information would be very useful in the generated scan results. (If it is already there, please advise where I can see it.)

Example scan results attached.

slint-1.0.0.tar.gz_scan.json.zip

@DennisClark DennisClark added the enhancement New feature or request label Apr 13, 2023
@DennisClark
Copy link
Author

@pombredanne please comment on the best place to put this information.

@tdruez
Copy link
Contributor

tdruez commented Apr 13, 2023

Maybe a new entry in the header, such as:

{"headers": [{  
    "tool_name": "scanpipe",  
    "tool_version": "32.1.0", 
    "tool_extra": "scancode@31.2.4",
]}
...

Suggestion for naming the tool_extra label welcomed!

@DennisClark
Copy link
Author

how about toolkit or tool_kit ?

@pombredanne
Copy link
Contributor

pombredanne commented Apr 14, 2023

or "other_tools": ["scancode-toolkit@31.2.4"] ?

or a purl? "other_tools": ["pkg:pypi/scancode-toolkit@31.2.4"] ?

tdruez added a commit that referenced this issue Apr 17, 2023
Signed-off-by: Thomas Druez <tdruez@nexb.com>
@tdruez
Copy link
Contributor

tdruez commented Apr 17, 2023

"other_tools": ["pkg:pypi/scancode-toolkit@31.2.4"] added in headers.

@tdruez tdruez closed this as completed Apr 17, 2023
@armijnhemel
Copy link

Is top level really the best place to add this information?

What I am seeing in the output is this:

            "runs": [
                {
                    "pipeline_name": "scan_package",
                    "status": "success",
                    "description": "Scan a single package archive with ScanCode-toolkit.",
                    "uuid": "ad7359b8-e94d-4963-9b58-700c2f3a7768",
                    "created_date": "2023-04-11T18:03:42.732065Z",
                    "scancodeio_version": "32.1.0",
                    "task_id": "ad7359b8-e94d-4963-9b58-700c2f3a7768",
                    "task_start_date": "2023-04-11T18:03:42.783160Z",
                    "task_end_date": "2023-04-11T18:05:03.464152Z",
                    "task_exitcode": 0,
                    "task_output": "",
                    "log": ...
                }
            ],

and I think it makes much more sense to record the versions of the used tools in each individual pipeline entry in the runs list. A not so imaginary use case would be if someone would want to have two pipelines using a different version of Scancode-toolkit, for example for regression testing or acceptance testing (I am aware that this might mean reworking the output result format in packages as well as that gives a squashed view of the results).

I would also suggest using the exact same field names as scancode-toolkit uses:

      "tool_name": "scancode-toolkit",
      "tool_version": "v32.0.0rc3-105-g6b1c2ce1d4",

or perhaps even include the verbatim scancode headers, including the options with which scancode was run, which are now completely missing from the scancode.io results (judging by the output that was posted here).

As an example I did a short (partial) scan of a package and the headers of the JSON look like this:

  "headers": [
    {
      "tool_name": "scancode-toolkit",
      "tool_version": "v32.0.0rc3-105-g6b1c2ce1d4",
      "options": {
        "input": [
          "/tmp/bash-3.2.57"
        ],
        "--json-pp": "/tmp/bash.json",
        "--license": true
      },
      "notice": "Generated with ScanCode and provided on an \"AS IS\" BASIS, WITHOUT WARRANTIES\nOR CONDITIONS OF ANY KIND, either express or implied. No content created from\nScanCode should be considered or used as legal advice. Consult an Attorney\nfor any legal advice.\nScanCode is a free software code scanning tool from nexB Inc. and others.\nVisit https://github.com/nexB/scancode-toolkit/ for support and download.",
      "start_timestamp": "2023-04-17T202648.441176",
      "end_timestamp": "2023-04-17T202858.816933",
      "output_format_version": "3.0.0",
      "duration": 130.37576985359192,
      "message": null,
      "errors": [],
      "warnings": [],
      "extra_data": {
        "system_environment": {
          "operating_system": "linux",
          "cpu_architecture": "64",
          "platform": "Linux-6.2.10-100.fc36.x86_64-x86_64-with-glibc2.35",
          "platform_version": "#1 SMP PREEMPT_DYNAMIC Thu Apr  6 23:20:10 UTC 2023",
          "python_version": "3.10.10 (main, Feb  8 2023, 00:00:00) [GCC 12.2.1 20221121 (Red Hat 12.2.1-4)]"
        },
        "spdx_license_list_version": "3.20",
        "files_count": 956
      }
    }
  ]

This output gives me a lot more information than the one from scancode.io related to for example the spdx_license_list_version, which options were enabled (--license), and so on.

I also noticed that there are some different fields for what basically amounts to the same data in the two formats such as start_timestamp vs task_start_date.

@tdruez tdruez reopened this Apr 18, 2023
@pombredanne
Copy link
Contributor

@armijnhemel I think we cannot really separate the ScanCode toolkit version from a ScanCode.io version as they are closely tied to and you cannot just switch a ScanCode TK version this way. We cannot also configure the SCTK arguments: instead these are baked in the code of a pipeline.

But we should surely come with an harmonized header format and could also provide more details.

@pombredanne
Copy link
Contributor

We should also include more environment details such as version of various tools in symbols collection, OS, etc. We already do some of this in ScanCode Toolkit results

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants