Comments (19)
this is a neat idea, agreed that
wily report --format json
should be a supported command, that way people to have their own logic.
The wily diff
command is the one I would target for any kind of hard-coded trigger.
At the moment it compares the last indexed revision against the current file.
But it could be extended to compare HEAD against a specific revision index
from wily.
Hey @tonybaloney , saw your presentation on Wily at PyCon. Very interesting stuff.
I think the ability to integrate this into a pipeline would generate a lot of value.
from wily.
It should be possible to use BeautifulSoup to parse the HTML to access any of the values:
pip install beautifulsoup4 wily
git checkout -b branch_for_wily # avoid wily "HEAD is a detached symbolic reference" error
wily build .
wily report --format HTML .
python -c "import bs4 ; print(bs4.BeautifulSoup(open('wily_report/index.html')).prettify())"
Not exactly as cool as wily report --format JSON . would be but it might do in a pinch.
from wily.
thanks for raising this request. This feature is not something that is supported right now, you can use the wily diff
command as a pre-commit hook, but there is no way to programmatically return an error code for a specific metric.
from wily.
Same on Travis CI
from wily.
I got it to work on Travis CI by adding a git checkout -b:
- pip install wily
- git checkout -b branch_for_wily # avoid wily error: "HEAD is a detached symbolic reference"
- wily build .
- wily report .
from wily.
When running on Continuous Integration perhaps wily could run with some reasonable defaults and not prompt the user in these headless environments:
import os
if os.getenv("CI"):
print("Avoid prompting the user here...")
See: https://docs.travis-ci.com/user/environment-variables/#default-environment-variables
from wily.
So, this does work, but I'm more interested in performing automated rejection based on specific metrics. You could definitely parse the values out of the Wily report but it would be ideal to have a programmatic way to access those values, or perhaps expect a Wily Error if a metric fails to exceed a minimum.
from wily.
I love wily and I would also would very much like to use this as part of the CI, perhaps with an additional config file that would allow to set threshold per metrics.
@tonybaloney I'd like to take a crack at doing this, if you believe this a good first issue.
from wily.
@liiight sure! I would really appreciate your help
from wily.
Awesome.
I was thinking of optionally passing threshold per metric via cli args / pyproject.toml section.
WDYT?
from wily.
Great idea! Have a go with changing the return code of the app to fail if a certain metric is below/above what was provided on the CLI.
This should be in wily diff
command
from wily.
So I've taken a look at the code and I have a few ideas/suggestion/questions:
- The core code is very much coupled with its CLI usage, meaning that if we want to neatly separate the ability to take config from CLI or via config file, it would require a bit of refactoring to do it nicely. This might be a good idea to do as a first step (if you agree with this obviously) as the more logic added to wily, the more difficult it would become to make this change. This will also potentially grant the ability to use wily as a python lib and not just as a CLI app.
- Alternatively, we can add the threshold options directly to the CLI for now, which shouldn't be too difficult. This would allow to deliver this wanted functionality quicker and worry about the refactor later (if at all).
WDYT @tonybaloney ?
from wily.
The configuration is overriden by the CLI, but the configuration object is established from a file (if it exists)
https://github.com/tonybaloney/wily/blob/master/wily/config.py
from wily.
cool, I'll use that
from wily.
Would it make sense to treat metrics that return -
as 0? I'm calculating the diff between current
and new
in the diff function.
Also is there any sense in checking for an absolute threshold or just a positive one (a higher new
than current
)? I'm leaning towards the latter as I don't see much sense in failing a build on improved metrics, but I wonder if there is such a use case for that.
from wily.
There are a few scenarios to consider:
- Renamed modules, will go from
{num}
to-
- Renamed functions/classes (as above)
- Modules with zero data
Does diff not already calculate the delta between the current metrics and the last entry in the database?
from wily.
Also consider the Metric
definitions have extra metadata in them to explain their type, whether higher or lower is better and how to calculate the total for a directory
https://github.com/tonybaloney/wily/blob/master/wily/operators/halstead.py#L29-L39
from wily.
Renamed modules, will go from
{num}
to-
Hmm, this could be tricky as I wouldn't want to fail a build on a file rename. Is there a programmatic way to determine if a module was renamed?
Does diff not already calculate the delta between the current metrics and the last entry in the database?
Not that I can tell. This is partly what I was referring to when talking about the function is coupled with its CLI usage. I think that ideally diff()
should return a dict (for example) specifying current and new value per module and let the CLI app determine how to format this into a table, or in this, case change the exit status based on additional configuration.
Also consider the Metric definitions have extra metadata in them to explain their type, whether higher or lower is better and how to calculate the total for a directory
Good point, this will be relevant when determining failure/succes
from wily.
Related Issues (20)
- Add Code of Conduct
- Wily fails to setup archiver sometimes HOT 5
- In-line visualization of maintainability index HOT 1
- GitHub Actions workflow: git ls-tree error on wily diff command HOT 3
- list-metrics outputs metrics in unpredictable order HOT 1
- HTML report fails due to codec errors
- HTML report has spurious characters from console colors
- HTML report cannot scroll horizontally when displaying too many metrics HOT 1
- Allow report to only display revisions that have changes
- Allow standalone plotly.min.js when creating graphs
- Graphs for directories don't work in Windows due to path representation
- Add CLI option to get a graph of all tracked files
- `wily rank` for revision without data raises statistics.StatisticsError
- Windows: aggregated graphs only show data for modified/added files
- Generate annotated source listings with inline visualization of code metrics
- Log calls should all be lazy-formatted
- Unable to use wily on cli HOT 4
- Number of Files
- Wily Build not wokring HOT 2
- Feature request: Measure metrics on a sub-file basis. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wily.