- Revenera Community
- Code Insight
- Code Insight Forum
- Re: Version Scanning Best Practices
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Printer Friendly Page
Version Scanning Best Practices
We have seen odd behavior when uploading new versions of the software and starting a new scan. Training from Flexera did not cover procedure on what steps to take. We have seen inventory research get deleted which represents a huge loss of time and effort.
What are the best practices for handling scans for new software versions?
Which version of FNCI are you using?
The answer depends on what you want to accomplish. If you want only the most recent BOM for your product. Then you will want to upload the newest code, delete the previously uploaded files and scan. But if you want to keep each BOM for each version, then you will want to look at Copying and Branching projects. See section 12 in the User Guide (v6.13.1).
If you are using v7 2019, it's a little more complicated. You will need to export your current scan, create a new project, scan your newest version of the code, then import the export from the previous into the new project. For files that remain the same all the research you do will be copied on top of the new project.
Please let me know if this is helpful. I can provide more information depending on which version you use.
We are using FlexNet CodeInsight 2019 R1.
I see how to export "Project Data" on the summary page but don't see an option to import JSON file into newly created project.
Your solution should mirror how source code repositories are managed with branching and tagging.
We don't ever want to loose the time and effort researching inventory items. If an inventory item is no longer used, it should be marked as deprecated rather than permanently deleted. Ideally, we should be able to classify the software version number when uploading source code to a project so that changes to inventory items can be tracked by software version.
In FNCI 2019 R1/R2, Import functionality is available via REST API only (not currently supported via Web UI).
You can find information on Export/Import scenarios and usage examples in Chapter 4 of the user Guide titled "Exporting and Importing Project Data". The updated chapter is also attached to this post.
The section titled "Branching a project and Audit work reuse" in the introduction best describes your use case. More specifically, here is how you would handle scanning of multiple versions of the same product:
- Perform analysis of the version 1 codebase in MyProjectV1
- Export data from MyProjectV1 (use the Web UI option or the REST API)
- Save the myprojectv1.json data file
- Create MyProjectV2 (make sure the project is of type "Standard")
- Point MyProjectV2 to the version 2 codebase
- Scan MyProjectV2
- Import myprojectv1.json data file into MyProjectV2 using the Import API
- Result: you now have two nearly identical projects with audit results from MyProjectV1 applied to MyProjectV2. You can keep MyProjectV1 as a snapshot and use MyProjectV2 for ongoing scanning until you are ready to move to MyProjectV3.
A few points to keep in mind:
- A scan is always required in the target project prior to import in order to build the codebase file tree.
- In Step #5 the version 2 codebase should be the same or similar to that of the version 1 codebase. This is because the relative file path is the key used to determine which data gets imported from the source project to the target project.
- Make sure the relative file paths are aligned before attempting to import. For example, the following two file paths are aligned between the source and target projects: /home/fnci/scanRoot/1/ePortal-1.3/src/gettext.c and /home/fnci/scanRoot/2/ePortal-2.0/src/gettext.c . If the file paths are not aligned (for example if moving data between servers), you can manipulate the exported json data file to make sure the file paths match.
- export import
- export import branching projects
- project copy
- reuse audit results
As of 2019 R1, if any field for a system-created inventory is manually modified by a user, the inventory item is no longer treated as system-created, and therefore NEVER deleted (even if the associated file no longer exists).
The only possible edit to the inventory item by the system is to add new files to it based on matching detection rules.
Likewise, user-created inventory is never deleted (existing behavior).
Inventory deletion occurs only for system-created inventory that has never been touched by a user and has zero file associations.
We currently don't have this filed as an enhancement. The majority of requests have been around improved filtering for files and for evidence (you'll find many improvements in these areas).
Is there a specific use case you'd like to address with the inventory sort/filtering option? Is it related to the rescan scenario to be able to quickly see if file associations were removed from inventory? Or something else? I'd like to file this as an enhancement, so thank you in advance for the info!
You are correct. we use it "to be able to quickly see if file associations were removed from inventory".
- We don't want FNCI to automatically remove all zero file evidence inventory as we have inventory we track without file evidence.
- It's a check for us to make sure we have scanned the correct branch. If we suddenly see hundreds of zero file evidence, we may have scanned the wrong branch.
- Making sure if the component was removed from the build by developers, it should show zero evidence in FNCI inventory. (we can safely remove the inventory item). However if the evidence is there, the developers are still using the old component, and we can remediate the issue.
We have added the requirement "SCA-18236: Better handling of inventory deletion/modification" based on your feedback and will prioritize into an upcoming release.