Skip to content

Conversation

csasarak
Copy link
Contributor

Overview

Provide an overview of this change. Describe the intent of this change, and how it implements that intent.

Example: This PR accomplishes X by doing Y.

Acceptance criteria

If this PR is successful, what impact does it have on the user experience?

Example: When users do X, Y should now happen.

Testing plan

How did you validate that this PR works? What literal steps did you take when manually checking that your code works?

Example:

  1. Set up test case X.
  2. Run command Y. Make sure Z happens.

This section should list concrete steps that a reviewer can sanity check and repeat on their own machine (and provide any needed test cases).

Risks

Highlight any areas that you're unsure of, want feedback on, or want reviewers to pay particular attention to.

Example: I'm not sure I did X correctly, can reviewers please double-check that for me?

Metrics

Is this change something that can or should be tracked? If so, can we do it today? And how? If its easy, do it

References

Add links to any referenced GitHub issues, Zendesk tickets, Jira tickets, Slack threads, etc.

Example:

Checklist

  • I added tests for this PR's change (or explained in the PR description why tests don't make sense).
  • If this PR introduced a user-visible change, I added documentation into docs/.
  • If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
  • If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an ## Unreleased section at the top.
  • If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
  • If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.

@csasarak csasarak marked this pull request as ready for review September 15, 2025 21:51
@csasarak csasarak requested a review from a team as a code owner September 15, 2025 21:51
@csasarak csasarak requested review from nficca, spatten and zlav and removed request for nficca September 15, 2025 21:51
Copy link
Contributor

@spatten spatten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a good change and we can and should ship it.

I added one question about logging something if we encounter multiple messages from Ficus that give us a snippet scan analysis ID.

Other than that, we should:

  • clean up the comments (and I know you just pushed this up and left them in knowing they needed to be cleaned up)
  • add an entry to the Changelog

and then ship this

<> " debug messages, "
<> pretty (length $ ficusMessageFindings messages)
<> " findings"
-- logDebug $
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's get rid of these comments

@spatten
Copy link
Contributor

spatten commented Sep 16, 2025

I tested this by compiling it and running against a directory with many copies of Linux.

On master, Ficus completed in around 20 minutes, but then the CLI just hung for > 1 hour. I gave up on it ever completing so don't know how long it actually took

On this branch, Ficus completed in around 20 minutes and the CLI got the analysis ID properly and everything worked

@spatten spatten merged commit bda178b into master Sep 16, 2025
19 checks passed
@spatten spatten deleted the no-ficus-buffering branch September 16, 2025 23:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants