feat: replace lockfile detection with phylum status
#322
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The changes here are centered around the use of `phylum status` for project and dependency file information. The `phylum status` command for printing project and lockfile details was added in CLI v5.1.0 but the fix to search for manifests' lockfiles in parent, rather than child directories was added in CLI v5.6.0, making this the new minimum CLI version required for new and existing installs. Now that both lockfiles and manifests are supported, the "lockfile" language has been changed to the more general term "dependency file" where it is externally visible (e.g., log and help output) but kept as "lockfile" internally (e.g., code/variable names). It is still not clear what to do for the situations where dependency files require more context for lockfile generation than just the previous/base version of that same file. Actions taken include: * Use `phylum status` for common tasks instead of custom code to * look for dependency files in `.phylum_project` * detect the dependency files present * acquire the initial project file backup * Downgrade the minimum CLI version required for new/existing installs * Remove the straddling code for `phylum analyze` command usage * No longer needed now that the minimum CLI version is > v5.3.1-rc1 * Remove the CINone pre-requisite * Needing to run from the root of a git repository is no longer true * Provide warning message when attempting to create a Phylum project outside the top-level of a `git` repository * Update externally visible `lockfile` language throughout * Use `dependency file` instead, to represent lockfiles and manifests * Format and refactor throughout * Improve log messages Closes #244
Phylum OSS Supply Chain Risk Analysis - SUCCESSThe Phylum risk analysis is complete and has passed the active policy. |
cd-work
reviewed
Oct 5, 2023
cd-work
requested changes
Oct 5, 2023
cd-work
approved these changes
Oct 6, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The changes here are centered around using
phylum statusforproject and dependency file information. The
phylum statuscommand forprinting project and lockfile details was added in CLI v5.1.0 but the
fix to search for manifests' lockfiles in parent, rather than child
directories was added in CLI v5.6.0, making this the new minimum CLI
version required for new and existing installs.
Now that both lockfiles and manifests are supported, the "lockfile"
language has been changed to the more general term "dependency file"
where it is externally visible (e.g., log and help output) but kept as
"lockfile" internally (e.g., code/variable names).
Actions taken include:
phylum statusfor common tasks instead of custom code to.phylum_projectphylum analyzecommand usageCINoneimplementation pre-requisiteoutside the top-level of a
gitrepositoryphylum initwith latest CLIlockfilelanguage throughoutdependency fileinstead, to represent lockfiles and manifestsscripts/docker_test.shCloses #244
Checklist
closes #<issueNum>in description above)?Have you created sufficient tests?Testing
Changes from this PR have been built in a Docker image and hosted on Docker Hub for my account, as the
lockfile_detectiontag.Local testing has been performed for a variety of scenarios. Screenshots are coming...
It is still not clear what to do for the situations where dependency files require more context for lockfile generation than just the previous/base version of that same file. For example, a provided manifest file that is part of a larger workspace may require a full checkout of the previous version of that file in order to have the directory structure available for determining where the generated lockfile goes...and then what it contains.