Closed patsonluk closed 1 year ago
+1 to this feature.
In one of the create*py files, there was a mechanism to compare Solr releases against each other. The way that was done was to first fetch the "git tags", then running the commits on them. I think we should support that feature, and hence rename this to something else (other than tag). Can we try "annotations" or "keywords" or "custom-tags" or "milestones"? If there's no suitable name, then we can settle with "tag" and document it clearly.
+1 to this feature.
In one of the create*py files, there was a mechanism to compare Solr releases against each other. The way that was done was to first fetch the "git tags", then running the commits on them. I think we should support that feature, and hence rename this to something else (other than tag). Can we try "annotations" or "keywords" or "custom-tags" or "milestones"? If there's no suitable name, then we can settle with "tag" and document it clearly.
For sure! What about "groups" instead of "tags"?
Sorry I have only gone through the code of createGraph.py
and didn't look at createBranchGraph.py
and createReleaseGraph.py
. I think in long run, it might be good to see if the changes in #38 can be applied to the createBranchGraph.py
and createReleaseGraph.py
as well. So we will only have one path to generate all graphs.
Since #38 added the ability to compare and render graphs for performance comparisons between any branches
(to be renamed to groupings
), in theory it should already be able to compare similarly to createBranchGraph.py
, and if the meta file generate also put git tags into the groupings
, then it should cover createReleaseGraph.py
too i suppose? 😊
Description
The graph rendering code can generate comparisons between 2 branches by reading the processed results grouped by matching against the
branches
defined in themeta.prop
file - every single test run will generate ameta.prop
file which hasbranches
property listing all the code branch names that contain the commit hash tested.However the graph rendering code itself actually doesn't really care if it's a branch or any other values that it's trying to match. All it does is look a list of values "tagged" to a test run and then generate graph based on whether any of those values match the values provided by the user for graph comparisons.
We are actually generating meta data file outside of solr-bench and make use of this behavior to generate graphs that compare between other things.
Therefore, it makes sense to name the list that keep currently keep track of
branches
of a particular commit to something more generic, proposing to rename it totags
. As those are tags assigned to a particular run and can be used for matching/filtering, and it just turns out that those tags are always branch names within the current scope of solr-bench (which could also expand in the future)