-
Notifications
You must be signed in to change notification settings - Fork 3.4k
HBASE-22853 Git/Jira Release Audit Tool #1088
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HBASE-22853 Git/Jira Release Audit Tool #1088
Conversation
This is an application for performing an audit between the histories on our git branches and the `fixVersion` field set on issues in JIRA. It does this by building a Sqlite database from the commits found on each git branch, identifying Jira IDs and release tags, and then requesting information about those issues from Jira. Once both sources have been collected, queries can be performed against the database to look for discrepancies between the sources of truth (and, possibly, bugs in this script).
|
Heads up release managers/Jira janitors -- @infraio @Apache9 @busbey @apurtell @saintstack @joshelser |
|
💔 -1 overall
This message was automatically generated. |
|
long term, this would make a nice contribution to Apache Yetus. |
busbey
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one doc gap. looks great, let's give it a go.
|
Huh so the usage of pylint is broken in our personality? |
I generally agree, but I wonder how much of this branching style is hbase-specific. |
joshelser
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor docs questions, but this looks great!
virajjasani
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is cool, +1 overall :)
yeah, I'm totally on board with us using it locally here first and then seeing if it's suitable for others later.
shoot, is it? I wonder how long ago that happened. can someone get up a jira with a description and I'll try to find someone to chase it down? |
|
Address PR feedback, burn down the pylint complaints. |
|
|
💔 -1 overall
This message was automatically generated. |
* HBASE-22853 Git/Jira Release Audit Tool This is an application for performing an audit between the histories on our git branches and the `fixVersion` field set on issues in JIRA. It does this by building a Sqlite database from the commits found on each git branch, identifying Jira IDs and release tags, and then requesting information about those issues from Jira. Once both sources have been collected, queries can be performed against the database to look for discrepancies between the sources of truth (and, possibly, bugs in this script). Signed-off-by: Sean Busbey <[email protected]> Signed-off-by: Josh Elser <[email protected]> Signed-off-by: Viraj Jasani <[email protected]>
* HBASE-22853 Git/Jira Release Audit Tool This is an application for performing an audit between the histories on our git branches and the `fixVersion` field set on issues in JIRA. It does this by building a Sqlite database from the commits found on each git branch, identifying Jira IDs and release tags, and then requesting information about those issues from Jira. Once both sources have been collected, queries can be performed against the database to look for discrepancies between the sources of truth (and, possibly, bugs in this script). Signed-off-by: Sean Busbey <[email protected]> Signed-off-by: Josh Elser <[email protected]> Signed-off-by: Viraj Jasani <[email protected]>
This is an application for performing an audit between the histories on our git branches and the
fixVersionfield set on issues in JIRA. It does this by building a Sqlite database from the commits found on each git branch, identifying Jira IDs and release tags, and then requesting information about those issues from Jira. Once both sources have been collected, queries can be performed against the database to look for discrepancies between the sources of truth (and, possibly, bugs in this script).