> > CircleCI can build github forked branches.
Yes it can, but we currently require each member of the community to set up their own CircleCI in order to test Cassandra (and non-paid account will have many tests failing). I looked into CircleCI JIRA integration and it seems that we would need every member to go into their settings to enable JIRA integration (get the correct tokens, link, etc.). Assuming we did go through this route, then we would require all members to also tag commits to have CircleCI know to forward (which is step one in what I proposed). I am fine with Jenkins or CircleCI; though I feel CircleCI is more effort for each member. The finer granularity of code review comments can also be on the github > commit pages, again you don't need to open the PR I just tested this out and what I see is the following 1) branch has a jira link, so PR comments make it into jira 2) going to the commit and commenting *does not* go into jira. Here is the test case (maybe it eventually will and its just slower this route?) . https://issues.apache.org/jira/browse/CASSANDRA-15508 https://github.com/dcapwell/cassandra/commit/0a9bec8f2d0b0eb0c96b85d03dafbee317270eeb So, given the stance that all conversations go into JIRA, in order to have any conversation in the commit, someone will need to copy this also into JIRA. > Can’t you currently open a PR with the right commit message, have do > review there with all comments posted back to JIRA, run CI on it and then > merge it closing the PR? This is the basic workflow you are proposing yes? Yep. It is the reviewer and authors job to make sure CI ran and didn’t introduce > new failing tests, it doesn’t matter how they were ran. I agree it doesn't matter how it runs, I am just proposing a small change which makes it easier to automate so we can have these results posted back into JIRA. This would give more visibility to reviewers, authors, and maintains the history better since there is a reference in JIRA that this was known stable or not pre-merge; the current process requires more effort from both parties, so trying to help lower this. > It is just as easy to let something through when “pr triggered” tests have > a failure as it is tests manually linked from a JIRA comment, if the author > and reviewer think the failures are not new. I agree that human judgement is the current gate keeper for merge or not but as I understand it test failing is supposed to be a blocker for commit, and tests failing is a blocker for release. Given this are we not supposed to right now fix these things before committing/releasing? Wouldn't an automated system which annotates JIRA only help bring visibility to this? If someone want to setup some extra niceties, like auto triggered builds or > something, to happen if people use the PR workflow, then I see no problem > there. But I don’t think we need to force use of PRs. I am more than willing to help set this up; i started this conversation to make sure we are all on the same page or not. But it doesn’t need to be forced. I am fine not forcing anything, but I am reacting to what I currently see happening in the project; tests fail as the norm and this is kinda seen as expected, even though it goes against the policies as I understand it. If there are alternatives to make this better, I would be glad to listen; just proposing the one which I use frequently as my attempt to get the ball rolling. On Thu, Jan 23, 2020 at 9:09 AM Jeff Jirsa <jji...@gmail.com> wrote: > On Thu, Jan 23, 2020 at 6:18 AM Jeremiah Jordan <jerem...@datastax.com> > wrote: > > > Can’t you currently open a PR with the right commit message, have do > > review there with all comments posted back to JIRA, run CI on it and then > > merge it closing the PR? This is the basic workflow you are proposing > yes? > > > > > Yes you can. > > > > It is the reviewer and authors job to make sure CI ran and didn’t > > introduce new failing tests, it doesn’t matter how they were ran. It is > > just as easy to let something through when “pr triggered” tests have a > > failure as it is tests manually linked from a JIRA comment, if the author > > and reviewer think the failures are not new. > > > > Agreed. Any committer who commits while tests are broken is ignoring > policy. Moving patch submission from one system to another won't somehow > make committers adhere to policy. > > > > > > If someone want to setup some extra niceties, like auto triggered builds > > or something, to happen if people use the PR workflow, then I see no > > problem there. But I don’t think we need to force use of PRs. > > > > This is why I don’t think we need to “switch” to using PR’s. There is no > > need to switch. People can “also” use PRs. If someone who likes the PR > > workflow sets up some more nice stuff to happen when it is used, that > would > > probably encourage more people to do things that way. But it doesn’t need > > to be forced. > > > > Agreed. >
