yetus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casey Brotherton <cbrother...@cloudera.com>
Subject [DISCUSS]: Debug logging for submitted patches from contributors.
Date Wed, 28 Sep 2016 14:24:56 GMT
Hello,

Over the past couple of months, I have submitted a couple of small patches,
and hope to
add larger contributions.

In doing so, it seemed that there would be a benefit for contributors to be
able
to see debug logging for when YETUS tests itself through the Jira Plugin.

To first frame what I think I know:

When a patch is submitted to the YETUS jira component, within the next five
minutes, jenkins will
use the newly uploaded YETUS patch on the YETUS repository.

There is not currently a local unit test for jira integrations.

There will be times when a local, console run seems to succeed, but that
the jira integration will not work.
Likewise there will be cases where there the specific test is for text
within the Jira issue system.

In those cases, it will be helpful for non-committers to see debug output.

1)  One possible method would be to document the Jenkins build process, and
how to use an authentication token
to rerun the YETUS build and test that occurs every five minutes, with the
DEBUG flag set.

-- This is tied to a build implementation, and documentation may grow
stale, but would
allow DEBUG runs only when needed.

It is possible even if it is documented, that newbies may not find the
documentation immediately.

2)  Another possible method would be to run the YETUS on YETUS test that
occurs after the
" A patch to the testing environment has been detected. "  message with the
DEBUG flag always turned on.

-- This would create messages for every run, catching any failures.
  However, would likely increase the temporary disk space required to test
patches.

Does the suggestion to allow non-committers to see debug output make sense?
Is there a #3 that I missed?
Out of #1 and #2, is one more preferable?
  ( Once a consensus is reached, I can open a Jira and investigate further.
)

Thanks,
Casey

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message