I learned about Lift and wanted to see what kinds of results it would produce on a real repo. The first experience is that it just said “Analysis failed” without further context. Clicking on the “Tool Results” tab included the non-descriptive “Resource not found. Visit the community for help.” (which I’m doing now), and the “Build Logs” tab includes the highly suspicious text “Build logs not available”
That does not allow me as a user to know what action to take in order to unstick this mess.
I also visited the troubleshooting page in the docs where I learned about .lift.toml and its setup and build keywords, which I added to the repo but it produced the exact same outcome (again, with the blank “Build Logs” tab). It was at that point that I gave up and posted here
The request is that I would want to see what Lift was attempting to do when it “failed” because trying to troubleshoot any system which gives back “Error: It didn’t work” error messages is an exercise is futility
Thanks @mdaniel. I agree it definitely should not fail with no explanation why, that’s not a good experience. We have an internal story to improve the build logs including adding more debug information. I’ll make sure a review of this post is included as part of that work.
@mdaniel Which repository are you trying to use Lift on? Is it public? Also could you give us your job ID (it’s the junky looking alphanum in the URL of the results page)?
I was explicitly not mentioning the job because my question wasn’t “why is my job failing” as much as “why do I have to come to the forums to get help troubleshooting job failures?”
My experience in this space says that if there are 3 ways of doing something in a build system, you will see all 4294967296 versions of it, and thus I am mystified how this feature shipped with the shruggle emoji as an outcome
But the answer to both of your questions is https://lift.sonatype.com/result/mdaniel/intellij-community/01F922FS3NE8BGM0VP5VW02P2V (and yes, it’s public – it’s merely a fork of JetBrains/intellij-community so that I could add the .lift.toml files to it)
Wow, what an unfriendly welcome you ran into, @mdaniel. I looked at the logs and see the error is a failure when git fetch-ing the code. Probably either a network failure or the commit indicated when analyze was pressed wasn’t in the repository when we tried to fetch.
There is currently effort to improve our error propagation but in this case we really should have a better retry method that more-or-less says “any recent commit of this branch” rather than “this commit in this repository”. I’ve forked the repository and will follow the analysis (Sonatype Lift -- Console). If that fails then we’ll have some investigation. If it succeeds then we’ll set our minds to tackling the rough corners mentioned.
EDIT: And it did fail in a similar manner as you mentioned. This is an odd one, thank you for pointing it out. Tackling it now.
OK, I have looked into the failure and see the repository of interest is 3.7GB. We use notably smaller volumes to back the repository clone which exclude repositories of such size. Additionally, extremely large repositories might take unreasonable lengths of time to clone. There are certainly several solutions available here, I will confer with the product group to see where this issue fits.
@tdubuisson Does Lift analyze prior commits? If not, a sparse commit would mitigate clones failing due a large history (e.g. a 50MB file modified 10 times, taking up 500MB in aggregate). However, it would not mitigate the issue for repositories with a large amount of files in the HEAD.
@rgomez What you suggest is one of the proposals I’ve posted internally. To answer your question Lift’s current tools do not analyze prior commits but we’ve left the door open for others to do so -
Lift is an open platform and users can bring their own tools, tools like trufflehog which searches git history, by writing rather small and simple shell scripts which respond to arguments of version/applicable/run.
A change could be codified, documented, and moved forward to ease the restriction.
If Lift is used periodically — or for the first time — the expectation may be “show me all of the issues in the this repository”. In that scenario, a full clone would be desirable for tools like trufflehog.
However, if it’s used to continuously scan a repository for issues, sparse checkouts make sense. I would assert (with no empirical data) that this ought to be the default behaviour. People should have the option to do a full history analysis; however, defaulting to sparse checkouts means faster scans, less network overhead, and less storage overhead for Sonatype. Not to mention that many/all of the default tools only require the latest changes.
(Aside: the GitHub Marketplace listing shows lift-bot commenting on a PR, however, I’m not sure how to configure this.)
@rgomez Lift-bot will comment on a PR any time an issue is discovered where the blamed line is contained within the diff of the PR and the comment has not been previously posted to this PR.
Thanks, @tdubuisson . And slightly more context on how to enable PR commenting: Lift will automatically analyze PRs and add PR comments for issues it finds. It will do this for any repo the Lift app is enabled on (via the GitHub app settings). To configure those settings, go to your GitHub account settings and find the “applications” tab:
Then click “configure” for the Sonatype GitHub app:
