bugout-dev / locust Goto Github PK

We are getting this error in CI/CD pipelines that comes from not pinning protobuf version:
https://github.com/bugout-dev/moonstream/runs/7560456052?check_suite_focus=true

We need to build GitHub Actions so that whenever a commit is pushed to main:

1. PyPI release: We run python setup.py sdist bdist_wheel and then twine upload --non-interactive dist/* (this will need PyPI username and password as secrets)

2. Docker push: We run LOCUST_DOCKER_PUSH=true docker/build.sh v$(python -m locust.version) (this will need a DockerHub token as a secret)

1. It doesn't stop at definition boundaries at the moment. Sums up the sizes of hunks even if they exceed the boundaries of a function/class definition.

2. It doesn't correctly count deleted lines.

In the locust summary, it should be clear to viewers which functions/classes have been added for the first time in the code base, which ones are merely updated, and which were removed.

For the analysis of large Pull Request, it is difficult to capture and focus on Locust result with 10+ changed functions. In my opinion, it would be easier to perceive it in a more compressed form.

For example:

What should our approach be in adding Locust support for other languages?

Locust is written in such a way that all parts of the summarization process besides the AST traversal should be programming language invariant.

This question is more about the handoff between run times. For example, how should Locust call out to a Javascript AST walker?

Right now, I am thinking of just:

1. Writing the diff structures to the filesystem (as JSON)
2. Exec-ing the Javascript AST walker
3. Having it write its output (same summary format as Locust) back to the filesystem (as JSON)
4. Putting the objects in those files through the rendering pipeline

Some considerations:

1. Users will have to have Python AND a compiler/runtime for whatever other language we're targeting available to them. This can be through Docker if they wish (but our Docker images will probably get large).
2. Maybe it would be better to reimplement the diff processor and renderer in C or Go - a language in which it would be easy to just statically compile a binary so that we don't force users to set up Python environments just to run Locust.

These are just some early and woolly thoughts on the topic. I would like to add Javascript support before December, though.

The Locust in the Locust summary title for --format html and --format html-github outputs should link back to this GitHub repository.

The code in question is here: https://github.com/simiotics/locust/blob/main/locust/render.py#L224

Right now, if you wanted to store a JSON summary and an HTML summary, you would have to run the summarization process (including AST traversal) twice.

It's much more reasonable to create clearer interfaces between diff-calculation, AST traversal, and rendering. This will allow us to:

1. Apply more logic to the output of locust (e.g. do not print if there are no changed files in the Locust summary)
2. Set up #21

Each environment variable should reference the definition it is used inside (if one exists). Otherwise, the reference should be null.

locust --depth <n> should only render the top n levels of a Locust summary.

locust --depth 1 would be similar to git diff --stat, where it would show only the files changed.

locust --depth 2 would show files and top-level functions + classes in those files.

And so on.

Nested paths are not prefixed by the URL provided by the --github parameter.

Hello zomglings,

hbt here from https://news.ycombinator.com/item?id=25007701

I'd like to reply to your comment then explain what I'm planning to build

Your questions

Q:

Would this be a lot easier in go? The case that scares me a bit in Go is implicit imports (e.g. importing a driver for use with database/sql). But maybe all that is very clear when doing static analysis?

A:
There are already utilities for golang and existing apis.

• guru https://github.com/golang/tools/tree/master/cmd/guru

Example of usage: guru -json -scope "github.com/hbt/fh/cmd/hbt-cli" callers "hbt-cli/lib/util/git/git.go:#645"

Example of output:

        {                           
                "pos": "/home/hassen/workspace/fh/hbt-cli/lib/cmds/devcmd/gw.go:122:63",                                                          
                "desc": "static function call",                          
                "caller": "(github.com/hbt/fh/hbt-cli/lib/cmds/devcmd.GitWorkDev).handleCustomProjects"                                           
        },                          
        {                           
                "pos": "/home/hassen/workspace/fh/hbt-cli/lib/cmds/devcmd/gw.go:123:63",                                                          
                "desc": "static function call",                          
                "caller": "(github.com/hbt/fh/hbt-cli/lib/cmds/devcmd.GitWorkDev).handleCustomProjects"                                           
        },                          
        {                           
                "pos": "/home/hassen/workspace/fh/hbt-cli/lib/util/goutil/mage.go:71:40",                                                         
                "desc": "static function call",                          
                "caller": "(github.com/hbt/fh/hbt-cli/lib/util/goutil.MageBuild).BuildLocally"                                                    
        },                          
        {                           
                "pos": "/home/hassen/workspace/fh/hbt-cli/lib/cmds/go/order.go:32:35",                                                            
                "desc": "static function call",                          
                "caller": "(github.com/hbt/fh/hbt-cli/lib/cmds/go.GoOrderCmd).Run$1"                                                              
        },                          
        {                           
                "pos": "/home/hassen/workspace/fh/hbt-cli/lib/cmds/go/impl.go:43:38",                                                             
                "desc": "static function call",                          
                "caller": "(github.com/hbt/fh/hbt-cli/lib/cmds/go.GoImplementInterfaceCmd).Run"                                                   
        },                          
        {                           
                "pos": "/home/hassen/workspace/fh/hbt-cli/lib/cmds/selfdev/create.go:61:38",                                                      
                "desc": "static function call",                          
                "caller": "(github.com/hbt/fh/hbt-cli/lib/cmds/selfdev.CreateCmd).getPackagePath"                                                 
        }                           
]                                   

The guru tool uses an existing library to do the AST parsing and provides an API for querying go programs.

  callees         show possible targets of selected function call                                                                           
        callers         show possible callers of selected function                                                                                
        callstack       show path from callgraph root to selected function                                                                        
        definition      show declaration of selected identifier                                                                                   
        describe        describe selected syntax: definition, methods, etc                                                                        
        freevars        show free variables of selection                                                                                          
        implements      show 'implements' relation for selected type or method                                                                    
        peers           show send/receive corresponding to selected channel op                                                                    
        pointsto        show variables the selected pointer may point to                                                                          
        referrers       show all refs to entity denoted by selected identifier                                                                    
        what            show basic information about the selected syntax node                                                                     
        whicherrs       show possible values of the selected error variable     

• github codeql -- https://securitylab.github.com/tools/codeql

This is also pretty good for querying AST across multiple languages

• another alternative implementation - https://github.com/ofabry/go-callvis

My goal

My main goal is:

• provide a better "git diff" prior to committing code and detect the following issues

  • changes to the callgraphs that would have been hard to notice (e.g calls that have been affected by change, other modules that were affected by change and was unaware because outside of scope etc.).
  • changes to a functions that are "risky" (are used a lot)
  • unwanted changes (e.g logging, debug etc.). Easily detectable via callgraph, harder to detect when just text

• commit metadata and value of a commit: we often say, writing software is about iteration but somehow that doesn't apply to writing a commit and we are expected to get everything right (message, changes within scope etc.)

  • provide metadata such as new/modified declarations
  • changes to callgraph
  • calculate the "value" of a commit. This is more for work/team management. Detecting how often functions are created vs modified, the scope of changes, patterns per author.

Anyway, as soon as I find the bandwidth, I will push out something more concrete.

Right now, we show the total number of lines and changed lines for each definition (functions, async functions, classes) in a Python file.

We should also provide the total_lines and changed_lines statistics per file.

As a follow-on bit of work, we should give users the option to order files in a summary:

1. Alphabetically
2. By number of changed lines
3. By proportion of changed lines

The setting should cascade down to definitions.

The logic is simple - we should:

1. pip install locust from PyPI
2. get the version of the PyPI locust
3. compare it to the version of the locust in the PR
4. if the locust version from the PR is not semver greater than the version of locust from PyPI, fail the check

We should add a console_scripts entry for locust.version in setup.py.

Although we are using the proto definitions to generate data containers in the code, we still require conversion to JSON when passing data between pipeline steps (especially through plugins).

locust.git, locust.parse, and locust.render should all accept -i and -o arguments in two possible formats json, pb.

GitHub's PR UI shows the diff of the base branch with a ref in which the base branch has been merged into the head branch.

Locust summaries take the diff of the base branch with the head branch directly.

When the base branch contains changes not in the head branch, the Locust summary shows different modifications than the GitHub diff.

When the Locust summary is generated for GitHub, Locust should:

1. Try to merge the base branch into the head branch. If this succeeds, set base=base, head=base->head
2. If this merge fails, fall back to base=base, head=head
3. Take diff of base with head.
4. Run Locust summary generator, but replace all links to files with links to diffs (i.e. PR comments).

This last change should probably get its own issue, as it's a substantial improvement in the user experience, and seems like a significant chunk of work.

This will allow users to generate a Locust summary for the current revision in their repository (instead of a diff between revisions).

This can be a little bit confusing when viewing a locust summary, because it differs from what GitHub says about number of files changed.

locust.git already contains a lot of this information in its output. That's probably a good starting point for this issue.

Code bases with multiple languages (e.g. frontend Javascript and backend Python) should not receive empty Locust summaries for changes in non-Python code.

If the rendered string is empty, we can do an easy check for it in the CI environment (-z in bash, for example).

This was requested by a user.

Right now the link goes directly to the file within the commit, but I was expecting to see the diff.

Is there a way to auto-hide old Locust summaries when a new one is posted to the PR? Here's an example PR.

The Javascript plugin duplicates the data structure definitions (PatchInfo, HunkInfo, RawDefinition, LocustChange, etc.) from the core Python library.

The fact that each plugin has to define its own data structures creates two kinds of issues:

1. Plugins can very easily go out of date in terms of their input and output interfaces
2. It is easy to make mistakes when defining a data structure that sits at a plugin boundary

Protobufs are a great way to give plugins a consistent interface to program against. We can define all of the core Locust data types as proto files and generate data structures for each language using protoc.

More documentation on protobuf: https://github.com/protocolbuffers/protobuf