jgbarah
commented
8 years ago This is a very good idea, indeed. I suggest using the following properties in the output dictionaries (JSON documents that will be stored in ElasticSearch):
- Git repo url. The url of the git repo from which the commit was retrieved (it would be better a "browseable url", that is, a link to a page where the repo can be browsed from a browser.
- Git repo string_id. A single string that would identify the repo. This will be helpful for naming the repo through the dashboard, since the url will be too long for that.
- Commit hash. The hash can be the unique identifier for commits.
- Commit hash first 7 chars. Again, as hashes are too long to show in the dashboard, having the first 7 chars available (which are usually unique, at least for a single repo) will be handy for representing commits in the dashboard.
Almost all of this can be obtained from Perceval output, we can discuss later how exactly to do that.
ghost
ijackson-citrix
As we will be dealing with multiple git repos, we should consider adding two pieces of information to the Code Review Database. Probably as part of making the matching independent of the Git repos 1) Repo (either an ID or a string) 2) Commit ID Eventually, we may want to expose these through into the ElasticSearch Index, such that it is possible in Kibana to a) filter by repo (e.g. xen.git, linux.git, qemu.git, mini-os.git, ...) b) match code review activity on the mailing lists to a commit ID (or range of IDs) - aka reverse look-up a code review by a commit for forensics I would assume that we will need some design, which will require input from Jesus. Maybe we need an "internal" flag also, if there are slightly different review workflows for repos, such that it becomes possible to specialize Lars