[jira] [Created] (YETUS-1245) Automatically mark as outdated old GitHub PR comments
Nick Dimiduk created YETUS-1245: --- Summary: Automatically mark as outdated old GitHub PR comments Key: YETUS-1245 URL: https://issues.apache.org/jira/browse/YETUS-1245 Project: Yetus Issue Type: Improvement Components: Precommit Reporter: Nick Dimiduk Over on HBase, we use Yetus precommit on our PR builds. Often times, a PR is opened and as reviews come in, several commits are pushed to the PR branch. Also, we actually invoke Yetus three times -- once for static checks and twice more for different JDK testing. Thus each push receives three comments from Yetus. It would be great if Yetus could go back and mark as hidden/outdated all the old comments from previous builds. That way, reviewers can always find the current state, and folks interested in the discussion history aren't spending all their time scrolling past old automation reports. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (YETUS-1181) post-0.14.0 release doc updates
[ https://issues.apache.org/jira/browse/YETUS-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785907#comment-17785907 ] Nick Dimiduk commented on YETUS-1181: - (y) > post-0.14.0 release doc updates > --- > > Key: YETUS-1181 > URL: https://issues.apache.org/jira/browse/YETUS-1181 > Project: Yetus > Issue Type: Improvement > Components: build >Affects Versions: 0.15.0 >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer >Priority: Major > Fix For: 0.15.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Updates to the release documentation post-0.14.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (YETUS-1236) Publish a `latest` tag for the docker image
[
https://issues.apache.org/jira/browse/YETUS-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774819#comment-17774819
]
Nick Dimiduk commented on YETUS-1236:
-
If we're going to insist on going against the grain of the Docker conventions,
we should document this clearly. I'd prefer that we publish {{latest}} as our
most recent tagged release, as is convention.
> Publish a `latest` tag for the docker image
> ---
>
> Key: YETUS-1236
> URL: https://issues.apache.org/jira/browse/YETUS-1236
> Project: Yetus
> Issue Type: Task
>Reporter: Nick Dimiduk
>Priority: Major
>
> Trying to do a quick thing with the docker image, I was confused by the error
> response {{docker: Error response from daemon: manifest unknown.}} I
> eventually realized that I wasn't explicitly providing an image tag, and so
> of course an image could not be resolved.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (YETUS-1236) Publish a `latest` tag for the docker image
Nick Dimiduk created YETUS-1236:
---
Summary: Publish a `latest` tag for the docker image
Key: YETUS-1236
URL: https://issues.apache.org/jira/browse/YETUS-1236
Project: Yetus
Issue Type: Task
Reporter: Nick Dimiduk
Trying to do a quick thing with the docker image, I was confused by the error
response {{docker: Error response from daemon: manifest unknown.}} I eventually
realized that I wasn't explicitly providing an image tag, and so of course an
image could not be resolved.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (YETUS-1234) remove mac-10-15 from yetus-homebrew build
[ https://issues.apache.org/jira/browse/YETUS-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762620#comment-17762620 ] Nick Dimiduk commented on YETUS-1234: - Oh, that's why that build failed. Thanks. > remove mac-10-15 from yetus-homebrew build > -- > > Key: YETUS-1234 > URL: https://issues.apache.org/jira/browse/YETUS-1234 > Project: Yetus > Issue Type: Bug >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer >Priority: Major > > github actions no longer supports that host so need to upgrade to macos 11 or > whatever. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (YETUS-1230) hadolint is not executable on arm64
[
https://issues.apache.org/jira/browse/YETUS-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762611#comment-17762611
]
Nick Dimiduk commented on YETUS-1230:
-
[~aw] ah okay. I'll review that one when you have a PR.
> hadolint is not executable on arm64
> ---
>
> Key: YETUS-1230
> URL: https://issues.apache.org/jira/browse/YETUS-1230
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Affects Versions: 0.14.1
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Using the image published at ghcr.io/apache/yetus:0.14.1 to test a project
> locally, said project includes a Dockerfile, I see the following:
> {noformat}
> executable '/usr/bin/hadolint' for 'hadolint' is not executable.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (YETUS-1230) hadolint is not executable on arm64
[
https://issues.apache.org/jira/browse/YETUS-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk reassigned YETUS-1230:
---
Assignee: Nick Dimiduk
> hadolint is not executable on arm64
> ---
>
> Key: YETUS-1230
> URL: https://issues.apache.org/jira/browse/YETUS-1230
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Affects Versions: 0.14.1
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Using the image published at ghcr.io/apache/yetus:0.14.1 to test a project
> locally, said project includes a Dockerfile, I see the following:
> {noformat}
> executable '/usr/bin/hadolint' for 'hadolint' is not executable.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (YETUS-1232) Periodically rebuild container images
Nick Dimiduk created YETUS-1232: --- Summary: Periodically rebuild container images Key: YETUS-1232 URL: https://issues.apache.org/jira/browse/YETUS-1232 Project: Yetus Issue Type: Improvement Components: build Reporter: Nick Dimiduk I'm picking up Yetus for a new repo in HBase and while I sit here waiting on my own image to build, I realised that Yetus images are stale. Starting from `yetus-base:0.14.1`, I have loads of packages to update. Since we expect users to be pulling these images directly, I think we should be explicitly calling `apt-get update && apt-get upgrade` and rebuild on a timer. I propose a weekly cadence, but almost anything will do. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (YETUS-1230) hadolint is not executable on arm64
[
https://issues.apache.org/jira/browse/YETUS-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated YETUS-1230:
Summary: hadolint is not executable on arm64 (was: hadolint is not
executable)
> hadolint is not executable on arm64
> ---
>
> Key: YETUS-1230
> URL: https://issues.apache.org/jira/browse/YETUS-1230
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Affects Versions: 0.14.1
>Reporter: Nick Dimiduk
>Priority: Major
>
> Using the image published at ghcr.io/apache/yetus:0.14.1 to test a project
> locally, said project includes a Dockerfile, I see the following:
> {noformat}
> executable '/usr/bin/hadolint' for 'hadolint' is not executable.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (YETUS-1230) hadolint is not executable
[
https://issues.apache.org/jira/browse/YETUS-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17734178#comment-17734178
]
Nick Dimiduk commented on YETUS-1230:
-
Oh. We only install hadolint on x86 arch images :(
> hadolint is not executable
> --
>
> Key: YETUS-1230
> URL: https://issues.apache.org/jira/browse/YETUS-1230
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Affects Versions: 0.14.1
>Reporter: Nick Dimiduk
>Priority: Major
>
> Using the image published at ghcr.io/apache/yetus:0.14.1 to test a project
> locally, said project includes a Dockerfile, I see the following:
> {noformat}
> executable '/usr/bin/hadolint' for 'hadolint' is not executable.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (YETUS-1231) codespell is trying to parse contents the of .git
[
https://issues.apache.org/jira/browse/YETUS-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17734177#comment-17734177
]
Nick Dimiduk commented on YETUS-1231:
-
Maybe this is a {{codespell}} bug ; I cannot find a value for {{--skip}} that
has it omit the {{.git}} directory.
> codespell is trying to parse contents the of .git
> -
>
> Key: YETUS-1231
> URL: https://issues.apache.org/jira/browse/YETUS-1231
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Affects Versions: 0.15.0
>Reporter: Nick Dimiduk
>Priority: Major
>
> Using {{ghcr.io/apache/yetus:main}}, it seems the default {{codespell}}
> configuration is inspecting the contents of .git.
> {noformat}
>
>
> codespell plugin: full
>
>
> [Mon Jun 19 12:53:05 PM UTC 2023 DEBUG]: offset clock by 0
> WARNING: Cannot decode file using encoding "utf-8":
> ./.git/objects/68/2543a559782bec05d0d49067742babf19e34bd
> WARNING: Trying next encoding "iso-8859-1"
> WARNING: Cannot decode file using encoding "utf-8":
> ./.git/objects/74/65efc508cca072a4e103d8ce905d93f3a10010
> WARNING: Trying next encoding "iso-8859-1"
> WARNING: Cannot decode file using encoding "utf-8":
> ./.git/objects/f0/d57d38957178df8e9daae4eba779282ad62379
> WARNING: Trying next encoding "iso-8859-1"
> WARNING: Cannot decode file using encoding "utf-8":
> ./.git/objects/78/1615f230919cdcf42cc398cd1fc07a12ff2803
> WARNING: Trying next encoding "iso-8859-1"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (YETUS-1231) codespell is trying to parse contents the of .git
Nick Dimiduk created YETUS-1231:
---
Summary: codespell is trying to parse contents the of .git
Key: YETUS-1231
URL: https://issues.apache.org/jira/browse/YETUS-1231
Project: Yetus
Issue Type: Bug
Components: Precommit
Affects Versions: 0.15.0
Reporter: Nick Dimiduk
Using {{ghcr.io/apache/yetus:main}}, it seems the default {{codespell}}
configuration is inspecting the contents of .git.
{noformat}
codespell plugin: full
[Mon Jun 19 12:53:05 PM UTC 2023 DEBUG]: offset clock by 0
WARNING: Cannot decode file using encoding "utf-8":
./.git/objects/68/2543a559782bec05d0d49067742babf19e34bd
WARNING: Trying next encoding "iso-8859-1"
WARNING: Cannot decode file using encoding "utf-8":
./.git/objects/74/65efc508cca072a4e103d8ce905d93f3a10010
WARNING: Trying next encoding "iso-8859-1"
WARNING: Cannot decode file using encoding "utf-8":
./.git/objects/f0/d57d38957178df8e9daae4eba779282ad62379
WARNING: Trying next encoding "iso-8859-1"
WARNING: Cannot decode file using encoding "utf-8":
./.git/objects/78/1615f230919cdcf42cc398cd1fc07a12ff2803
WARNING: Trying next encoding "iso-8859-1"
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (YETUS-1230) hadolint is not executable
Nick Dimiduk created YETUS-1230:
---
Summary: hadolint is not executable
Key: YETUS-1230
URL: https://issues.apache.org/jira/browse/YETUS-1230
Project: Yetus
Issue Type: Bug
Components: Precommit
Affects Versions: 0.14.1
Reporter: Nick Dimiduk
Using the image published at ghcr.io/apache/yetus:0.14.1 to test a project
locally, said project includes a Dockerfile, I see the following:
{noformat}
executable '/usr/bin/hadolint' for 'hadolint' is not executable.
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (YETUS-1220) [mvn] Module directory listing fails when run against an empty local repository
Nick Dimiduk created YETUS-1220:
---
Summary: [mvn] Module directory listing fails when run against an
empty local repository
Key: YETUS-1220
URL: https://issues.apache.org/jira/browse/YETUS-1220
Project: Yetus
Issue Type: Bug
Affects Versions: 0.12.0
Reporter: Nick Dimiduk
Over in hbase-operator-tools, I noticed that the first time Yetus's maven
plugin goes to collect a list of module paths, it will silently fail. It
appears that maven's dependency resolver doesn't find a dependency module from
the same multi-module project. Subsequent invocations of this code complete
successfully, I presume because those indications happen after a {{mvn
install}} has occurred, populating the local repo.
{noformat}
% cat output/maven-patch-dirlist-.txt
Tue May 16 16:06:46 UTC 2023
cd /Users/ndimiduk/tmp/operator-tools-testpatch/yetus-precommit-check/src
/usr/share/maven/bin/mvn --batch-mode
-Dmaven.repo.local=/Users/ndimiduk/yetus-m2/unknown--full-4824 -fae -q
exec:exec -Dexec.executable=pwd -Dexec.args=''
/Users/ndimiduk/tmp/operator-tools-testpatch/yetus-precommit-check/src
/Users/ndimiduk/tmp/operator-tools-testpatch/yetus-precommit-check/src/hbase-table-reporter
/Users/ndimiduk/tmp/operator-tools-testpatch/yetus-precommit-check/src/hbase-hbck2
/Users/ndimiduk/tmp/operator-tools-testpatch/yetus-precommit-check/src/hbase-kubernetes-deployment
[ERROR] Failed to execute goal on project hbase-tools: Could not resolve
dependencies for project
org.apache.hbase.operator.tools:hbase-tools:jar:1.3.0-SNAPSHOT: Could not find
artifact org.apache.hbase.operator.tools:hbase-hbck2:jar:1.3.0-SNAPSHOT in
apache.snapshots (https://repository.apache.org/snapshots) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :hbase-tools
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (YETUS-1112) Document what permissions the Apache Yetus GITHUB_TOKEN requires
[
https://issues.apache.org/jira/browse/YETUS-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17689190#comment-17689190
]
Nick Dimiduk commented on YETUS-1112:
-
Paging through the {{curl}} invocations, comparing the API calls to the GitHub
Apps Permissions list, this is what I come up with.
||Yetus {{github.sh}} function||Permission||
| github_locate_sha_patch | /search/issues ??|
| github_start_checkrun | Repository permissions :: Checks :: write |
| github_end_checkrun | Repository permissions :: Checks :: write |
| github_linecomments | Repository permissions :: Checks :: write |
| github_write_comment | Repository permissions :: Issues :: write |
| github_initialize | Repository permissions :: Metadata :: read |
| github_locate_pr_patch | Repository permissions :: Pull requests :: read |
| github_status_write | Repository permissions :: Statuses :: write |
> Document what permissions the Apache Yetus GITHUB_TOKEN requires
>
>
> Key: YETUS-1112
> URL: https://issues.apache.org/jira/browse/YETUS-1112
> Project: Yetus
> Issue Type: Improvement
> Components: Precommit
>Affects Versions: 0.13.0
>Reporter: Allen Wittenauer
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (YETUS-1217) Github plugin support for reading access token from a file
[ https://issues.apache.org/jira/browse/YETUS-1217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk resolved YETUS-1217. - Resolution: Won't Fix The more I learn about GitHub API access, the less I think this is the correct approach. > Github plugin support for reading access token from a file > -- > > Key: YETUS-1217 > URL: https://issues.apache.org/jira/browse/YETUS-1217 > Project: Yetus > Issue Type: Improvement > Components: Precommit >Reporter: Nick Dimiduk >Priority: Major > > Some build environments provide secret materials via local file path. Lets > have the GitHub robot (and others?) support reading these secret files > directly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (YETUS-1217) Github plugin support for reading access token from a file
Nick Dimiduk created YETUS-1217: --- Summary: Github plugin support for reading access token from a file Key: YETUS-1217 URL: https://issues.apache.org/jira/browse/YETUS-1217 Project: Yetus Issue Type: Improvement Components: Precommit Reporter: Nick Dimiduk Some build environments provide secret materials via local file path. Lets have the GitHub robot (and others?) support reading these secret files directly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (YETUS-633) GitHub Checks integration
[ https://issues.apache.org/jira/browse/YETUS-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530654#comment-17530654 ] Nick Dimiduk commented on YETUS-633: I don't follow your meaning by "requires a hosted, live service". Can you elaborate? > GitHub Checks integration > - > > Key: YETUS-633 > URL: https://issues.apache.org/jira/browse/YETUS-633 > Project: Yetus > Issue Type: Wish > Components: Precommit >Reporter: Sean Busbey >Priority: Major > > GitHub has launched a feature for putting CI feedback into its own tab: > https://github.com/apache/yetus/pull/12/checks > Would be nice. lots of open questions. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (YETUS-1164) start-build-env.sh doesn't work on a Mac
[
https://issues.apache.org/jira/browse/YETUS-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk resolved YETUS-1164.
-
Resolution: Not A Problem
I suppose we might add some test to {{start-build-env.sh}} that can assert on
the presence of this required capability.
> start-build-env.sh doesn't work on a Mac
>
>
> Key: YETUS-1164
> URL: https://issues.apache.org/jira/browse/YETUS-1164
> Project: Yetus
> Issue Type: Bug
> Components: build
>Affects Versions: 0.14.0
>Reporter: Nick Dimiduk
>Priority: Major
>
> Following the https://github.com/apache/yetus#building-quickstart , I found
> {noformat}
> $ mvn clean install
> [ERROR] Could not create local repository at /home/ndimiduk/.m2/repository ->
> [Help 1]
> {noformat}
> I believe the issue here is that Docker is not "native" on the Mac (and
> probably other platforms also... Windows maybe?), because there is a virtual
> machine between the user's home directory and the docker container. Things
> fall apart with {{start-build-env.sh}} because it mounts various directories
> in the user's home directory into the container as volumes. These paths exist
> on the host OS, but not on the guest OS VM where the docker service runs.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (YETUS-1164) start-build-env.sh doesn't work on a Mac
[
https://issues.apache.org/jira/browse/YETUS-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529362#comment-17529362
]
Nick Dimiduk commented on YETUS-1164:
-
Oooh, this is some Docker Desktop feature. When I encountered the above, I was
using [Minikube|https://minikube.sigs.k8s.io/docs/] as my docker service
provider. It looks like minikube does provide similar capabilities, but they're
not enabled out of the box. I need some incantation of {{minikube mount}}.
> start-build-env.sh doesn't work on a Mac
>
>
> Key: YETUS-1164
> URL: https://issues.apache.org/jira/browse/YETUS-1164
> Project: Yetus
> Issue Type: Bug
> Components: build
>Affects Versions: 0.14.0
>Reporter: Nick Dimiduk
>Priority: Major
>
> Following the https://github.com/apache/yetus#building-quickstart , I found
> {noformat}
> $ mvn clean install
> [ERROR] Could not create local repository at /home/ndimiduk/.m2/repository ->
> [Help 1]
> {noformat}
> I believe the issue here is that Docker is not "native" on the Mac (and
> probably other platforms also... Windows maybe?), because there is a virtual
> machine between the user's home directory and the docker container. Things
> fall apart with {{start-build-env.sh}} because it mounts various directories
> in the user's home directory into the container as volumes. These paths exist
> on the host OS, but not on the guest OS VM where the docker service runs.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (YETUS-1164) start-build-env.sh doesn't work on a Mac
Nick Dimiduk created YETUS-1164:
---
Summary: start-build-env.sh doesn't work on a Mac
Key: YETUS-1164
URL: https://issues.apache.org/jira/browse/YETUS-1164
Project: Yetus
Issue Type: Bug
Components: build
Affects Versions: 0.14.0
Reporter: Nick Dimiduk
Following the https://github.com/apache/yetus#building-quickstart , I found
{noformat}
$ mvn clean install
[ERROR] Could not create local repository at /home/ndimiduk/.m2/repository ->
[Help 1]
{noformat}
I believe the issue here is that Docker is not "native" on the Mac (and
probably other platforms also... Windows maybe?), because there is a virtual
machine between the user's home directory and the docker container. Things fall
apart with {{start-build-env.sh}} because it mounts various directories in the
user's home directory into the container as volumes. These paths exist on the
host OS, but not on the guest OS VM where the docker service runs.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (YETUS-1109) Posting new comments to a Github PR should hide all previous buildbot comments
[ https://issues.apache.org/jira/browse/YETUS-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17342912#comment-17342912 ] Nick Dimiduk commented on YETUS-1109: - Or, why would a project be unable to deprecate their old style of precommit commenting on a PR in favor of using the new functionality added in 0.13? > Posting new comments to a Github PR should hide all previous buildbot comments > -- > > Key: YETUS-1109 > URL: https://issues.apache.org/jira/browse/YETUS-1109 > Project: Yetus > Issue Type: Improvement > Components: Precommit >Reporter: Nick Dimiduk >Priority: Major > > A quality-of-life request in absence of YETUS-633. When the robot posts a new > comment with a build result, it should go back and mark as hidden all > comments that it has previously made. This makes it easier for humans to find > comments made by other humans throughout the history, while also being clear > on what the latest build result is. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (YETUS-1109) Posting new comments to a Github PR should hide all previous buildbot comments
[ https://issues.apache.org/jira/browse/YETUS-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17342911#comment-17342911 ] Nick Dimiduk commented on YETUS-1109: - Thanks for the reference, [~aw]. I'm curious though -- can Apache HBase project use GitHub Actions for it's PR pre-commit builds? I think the practical answer is no, because HBase's builds are huge compared to the resources available to Actions. Do I read that correctly? > Posting new comments to a Github PR should hide all previous buildbot comments > -- > > Key: YETUS-1109 > URL: https://issues.apache.org/jira/browse/YETUS-1109 > Project: Yetus > Issue Type: Improvement > Components: Precommit >Reporter: Nick Dimiduk >Priority: Major > > A quality-of-life request in absence of YETUS-633. When the robot posts a new > comment with a build result, it should go back and mark as hidden all > comments that it has previously made. This makes it easier for humans to find > comments made by other humans throughout the history, while also being clear > on what the latest build result is. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (YETUS-1109) Posting new comments to a Github PR should hide all previous buildbot comments
Nick Dimiduk created YETUS-1109: --- Summary: Posting new comments to a Github PR should hide all previous buildbot comments Key: YETUS-1109 URL: https://issues.apache.org/jira/browse/YETUS-1109 Project: Yetus Issue Type: Improvement Components: Precommit Reporter: Nick Dimiduk A quality-of-life request in absence of YETUS-633. When the robot posts a new comment with a build result, it should go back and mark as hidden all comments that it has previously made. This makes it easier for humans to find comments made by other humans throughout the history, while also being clear on what the latest build result is. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (YETUS-1039) Homebrew is still broken
Nick Dimiduk created YETUS-1039:
---
Summary: Homebrew is still broken
Key: YETUS-1039
URL: https://issues.apache.org/jira/browse/YETUS-1039
Project: Yetus
Issue Type: Bug
Components: homebrew
Reporter: Nick Dimiduk
Trying out the tap after YETUS-1032, I get
{noformat}
$ brew tap apache/yetus https://github.com/apache/yetus-homebrew
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> Updated Formulae
Updated 1 formula.
==> Tapping apache/yetus
Cloning into '/usr/local/Homebrew/Library/Taps/apache/homebrew-yetus'...
remote: Enumerating objects: 17, done.
remote: Counting objects: 100% (17/17), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 17 (delta 4), reused 15 (delta 3), pack-reused 0
Unpacking objects: 100% (17/17), 10.84 KiB | 925.00 KiB/s, done.
Tapped 1 formula (48 files, 64.8KB).
$ brew install --debug apache/yetus/yetus
/usr/local/Homebrew/Library/Homebrew/brew.rb (Formulary::TapLoader): loading
/usr/local/Homebrew/Library/Taps/apache/homebrew-yetus/Formula/yetus.rb
==> Installing yetus from apache/yetus
/usr/bin/curl --disable --globoff --show-error --user-agent Homebrew/2.5.6\
\(Macintosh\;\ Intel\ Mac\ OS\ X\ 10.15.7\)\ curl/7.64.1 --header
Accept-Language:\ en --retry 3 --silent --location
https://www.apache.org/dyn/closer.cgi\?filename=/yetus/0.12.0/apache-yetus-0.12.0-bin.tar.gz\=download\=1
Error: Failed to download resource "yetus"
Download failed: Couldn't determine mirror, try again later.
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (YETUS-923) Expose volume mount options for users of Docker Desktop
[
https://issues.apache.org/jira/browse/YETUS-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated YETUS-923:
---
Description: Running builds in docker using Docker Desktop on a Mac is
incredibly slow. Using HBase as a testing tool, {{mvn clean install
-DskipTests}} run "natively" takes about ~2 minutes while the same command run
within the Docker Desktop container environment takes ~45 minutes. Apparently
this is to be expected, but can be improved by specifying a [volume mount
option|https://docs.docker.com/docker-for-mac/osxfs-caching/]. Right now
there's no way to expose such an option to the user. Ideally pre-commit could
even detect the environment and apply the necessary options accordingly. (was:
Running builds in docker using Docker Desktop on a Mac is incredibly slow.
Using HBase as a testing tools, a {{man clean install -DskipTests}} run
"natively" takes about ~2 minutes while the same command run within the Docker
Desktop container environment takes ~45 minutes. Apparently this is to be
expected, but can be improved by specifying a [volume mount
option|https://docs.docker.com/docker-for-mac/osxfs-caching/]. Right now
there's no way to expose such an option to the user. Ideally pre-commit could
even detect the environment and apply the necessary options accordingly.)
> Expose volume mount options for users of Docker Desktop
> ---
>
> Key: YETUS-923
> URL: https://issues.apache.org/jira/browse/YETUS-923
> Project: Yetus
> Issue Type: Improvement
> Components: Precommit
>Reporter: Nick Dimiduk
>Priority: Major
> Attachments: YETUS-923.demo.patch
>
>
> Running builds in docker using Docker Desktop on a Mac is incredibly slow.
> Using HBase as a testing tool, {{mvn clean install -DskipTests}} run
> "natively" takes about ~2 minutes while the same command run within the
> Docker Desktop container environment takes ~45 minutes. Apparently this is to
> be expected, but can be improved by specifying a [volume mount
> option|https://docs.docker.com/docker-for-mac/osxfs-caching/]. Right now
> there's no way to expose such an option to the user. Ideally pre-commit could
> even detect the environment and apply the necessary options accordingly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (YETUS-959) Dead link in precommit-advanced
Nick Dimiduk created YETUS-959: -- Summary: Dead link in precommit-advanced Key: YETUS-959 URL: https://issues.apache.org/jira/browse/YETUS-959 Project: Yetus Issue Type: Bug Components: website and documentation Affects Versions: 0.11.1 Reporter: Nick Dimiduk On [precommit-advanced |https://yetus.apache.org/documentation/0.11.1/precommit-advanced/], down under Personalities > Module & Profile Determination, there's a link [modules|https://yetus.apache.org/documentation/0.11.1/precommit-advanced/precommit-glossary.md#genericoutside-definitions] that returns a 404. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (YETUS-958) precommit-basic docs contains merge conflict marker
[ https://issues.apache.org/jira/browse/YETUS-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated YETUS-958: --- Attachment: Screen Shot 2020-03-26 at 3.54.03 PM.png > precommit-basic docs contains merge conflict marker > --- > > Key: YETUS-958 > URL: https://issues.apache.org/jira/browse/YETUS-958 > Project: Yetus > Issue Type: Bug > Components: website and documentation >Affects Versions: 0.11.1 >Reporter: Nick Dimiduk >Priority: Major > Attachments: Screen Shot 2020-03-26 at 3.54.03 PM.png > > > Down at the bottom of > [precommit-basic|http://yetus.apache.org/documentation/0.11.1/precommit-basic/], > in the Docker section, there are merge conflict markers that appear to have > come in with YETUS-109. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (YETUS-958) precommit-basic docs contains merge conflict marker
Nick Dimiduk created YETUS-958: -- Summary: precommit-basic docs contains merge conflict marker Key: YETUS-958 URL: https://issues.apache.org/jira/browse/YETUS-958 Project: Yetus Issue Type: Bug Components: website and documentation Affects Versions: 0.11.1 Reporter: Nick Dimiduk Down at the bottom of [precommit-basic|http://yetus.apache.org/documentation/0.11.1/precommit-basic/], in the Docker section, there are merge conflict markers that appear to have come in with YETUS-109. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (YETUS-943) Test patch fails to extract version information from a JDK11 jvm
[
https://issues.apache.org/jira/browse/YETUS-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated YETUS-943:
---
Fix Version/s: 0.12.0
> Test patch fails to extract version information from a JDK11 jvm
>
>
> Key: YETUS-943
> URL: https://issues.apache.org/jira/browse/YETUS-943
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Affects Versions: 0.11.1
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
>Priority: Minor
> Fix For: 0.12.0
>
> Time Spent: 7h
> Remaining Estimate: 0h
>
> Trying to use pre-commit with AdoptOpenJDK11 in the test matrix, the logic
> for extracting the version information is incorrect.
> For JDK8, the output is
> {noformat}
> root@ab2cb99dbf34:/# /usr/lib/jvm/jdk8u232-b09/bin/java -version
> openjdk version "1.8.0_232"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_232-b09)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.232-b09, mixed mode)
> {noformat}
> which Yetus parses as "1.8.0_232".
> For JDK11, it's
> {noformat}
> root@ab2cb99dbf34:/# /usr/lib/jvm/jdk-11.0.6+10/bin/java -version
> openjdk version "11.0.6" 2020-01-14
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)
> {noformat}
> which Yetus parses as "2020-01-14".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (YETUS-943) Test patch fails to extract version information from a JDK11 jvm
[
https://issues.apache.org/jira/browse/YETUS-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk resolved YETUS-943.
Resolution: Fixed
> Test patch fails to extract version information from a JDK11 jvm
>
>
> Key: YETUS-943
> URL: https://issues.apache.org/jira/browse/YETUS-943
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Affects Versions: 0.11.1
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
>Priority: Minor
> Fix For: 0.12.0
>
> Time Spent: 7h
> Remaining Estimate: 0h
>
> Trying to use pre-commit with AdoptOpenJDK11 in the test matrix, the logic
> for extracting the version information is incorrect.
> For JDK8, the output is
> {noformat}
> root@ab2cb99dbf34:/# /usr/lib/jvm/jdk8u232-b09/bin/java -version
> openjdk version "1.8.0_232"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_232-b09)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.232-b09, mixed mode)
> {noformat}
> which Yetus parses as "1.8.0_232".
> For JDK11, it's
> {noformat}
> root@ab2cb99dbf34:/# /usr/lib/jvm/jdk-11.0.6+10/bin/java -version
> openjdk version "11.0.6" 2020-01-14
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)
> {noformat}
> which Yetus parses as "2020-01-14".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (YETUS-943) Test patch fails to extract version information from a JDK11 jvm
[
https://issues.apache.org/jira/browse/YETUS-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated YETUS-943:
---
Release Note: This patch alters `report_jvm_version` to extract JVM vendor
and version information from Java system properties. It now returns a string
that is the concatenation of verdor and runtime versions.
> Test patch fails to extract version information from a JDK11 jvm
>
>
> Key: YETUS-943
> URL: https://issues.apache.org/jira/browse/YETUS-943
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Affects Versions: 0.11.1
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
>Priority: Minor
> Time Spent: 6h
> Remaining Estimate: 0h
>
> Trying to use pre-commit with AdoptOpenJDK11 in the test matrix, the logic
> for extracting the version information is incorrect.
> For JDK8, the output is
> {noformat}
> root@ab2cb99dbf34:/# /usr/lib/jvm/jdk8u232-b09/bin/java -version
> openjdk version "1.8.0_232"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_232-b09)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.232-b09, mixed mode)
> {noformat}
> which Yetus parses as "1.8.0_232".
> For JDK11, it's
> {noformat}
> root@ab2cb99dbf34:/# /usr/lib/jvm/jdk-11.0.6+10/bin/java -version
> openjdk version "11.0.6" 2020-01-14
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)
> {noformat}
> which Yetus parses as "2020-01-14".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (YETUS-953) multijdk support does not report all unit results in "Other Tests" section
[ https://issues.apache.org/jira/browse/YETUS-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056515#comment-17056515 ] Nick Dimiduk commented on YETUS-953: You guys have a chance check out the demo PRs I posted? HBase builds are now using JDK11, so I'd like to get these small Yetus fixes landed for the next release. > multijdk support does not report all unit results in "Other Tests" section > -- > > Key: YETUS-953 > URL: https://issues.apache.org/jira/browse/YETUS-953 > Project: Yetus > Issue Type: Bug > Components: Precommit >Affects Versions: 0.11.1 >Reporter: Nick Dimiduk >Priority: Major > Attachments: Untitled 2.png, Untitled.png > > > One JDK is reported, but not the other. See > https://github.com/apache/hbase/pull/1214#issuecomment-591757259 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (YETUS-922) Precommit qualitative checks vote be -0 on overall improvement
[
https://issues.apache.org/jira/browse/YETUS-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052305#comment-17052305
]
Nick Dimiduk commented on YETUS-922:
bq. This is literally the point of {{--tests-filter}}
[~aw] I disagree. {{--tests-filter}} says "I want to run these checks, but
regardless of the result, I want them to vote at worst -0." What I'm asking for
is the voting system to say, "hey, it's not perfect, but it's better than you
found it. Good work, +1." If the patch produces more total infractions than
were already present, I still want a -1, which {{--tests-filter}} denies me.
As I said in the description, one can refactor/restructure code without making
material changes to the implementation therein. The check-tool-output-diff
approach isn't smart enough to track lines through a history, so it's unable to
be certain if a given change is new to the codebase or not.
> Precommit qualitative checks vote be -0 on overall improvement
> --
>
> Key: YETUS-922
> URL: https://issues.apache.org/jira/browse/YETUS-922
> Project: Yetus
> Issue Type: Improvement
> Components: Precommit
>Reporter: Nick Dimiduk
>Priority: Minor
>
> Looking at the output over on
> [hbase/775|https://github.com/apache/hbase/pull/775#issuecomment-547725241],
> I think the -1 votes on qualitative checks are a bit harsh. The tests I'm
> looking at are {{javac}} and {checkstyle}}, where we have a qualitative
> measure of change in quality. In this case, the patch improved quality by
> reducing the overall number of failure occurrences. I think these should be
> voted as -0 rather than -1. I suspect the reasoning behind the -1 vote is
> that the patch is viewed to have introduced new failures. The thing is, with
> patches that refactor code, this simple diff isn't able to distinguish
> between an actual new failure and a moved failure.
> I could also argue that they should actually be +1 when {{total}} is less
> than {{previous}} because it's positive trajectory for the code base.
> {noformat}
> javac | hbase-server generated 1 new + 3 unchanged - 3 fixed = 4 total (was 6)
> checkstyle | hbase-server: The patch generated 12 new + 270 unchanged - 37
> fixed = 282 total (was 307)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (YETUS-953) multijdk support does not report all unit results in "Other Tests" section
[ https://issues.apache.org/jira/browse/YETUS-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052296#comment-17052296 ] Nick Dimiduk commented on YETUS-953: bq. The JDK Test Results that links back to testReport/ is a Jenkins thing. There will only ever be one of those since Jenkins can only process one set of junit result files. Is that so? The job archives test results from multiple stages, and when I brows the the Report, I do see path prefixes from each stage as part of the failure links. I agree that it doesn't seem to handle this very well. bq. The other looks like a bug, but it's hard to say if it is bug with YETUS-943 applied or a previously existing bug. Very well. I've posted [hbase#1237|https://github.com/apache/hbase/pull/1237], which demonstrates [hbase#1214|https://github.com/apache/hbase/pull/1214] but without the patch proposed on YETUS-943. > multijdk support does not report all unit results in "Other Tests" section > -- > > Key: YETUS-953 > URL: https://issues.apache.org/jira/browse/YETUS-953 > Project: Yetus > Issue Type: Bug > Components: Precommit >Affects Versions: 0.11.1 >Reporter: Nick Dimiduk >Priority: Major > Attachments: Untitled 2.png, Untitled.png > > > One JDK is reported, but not the other. See > https://github.com/apache/hbase/pull/1214#issuecomment-591757259 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (YETUS-633) GitHub Checks integration
[
https://issues.apache.org/jira/browse/YETUS-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052286#comment-17052286
]
Nick Dimiduk commented on YETUS-633:
bq. It is only available to Github Apps and can only be used via a callback.
That means that the only place where checks might work that is on (AFAIK)
anyone's roadmap would be as part of YETUS-578.
Is that still true? My read of the Checks API is that a GitHub _can_ initiate a
call to the target application (ie, via a {{pull_request}} event). However, an
application _could_ become aware of the presence of the change through some
other means, for example, a polling job in Jenkins. Regardless of how the
target application is notified, it's free to interact with the Check API,
registering checks or suites and updating their progress. This is the scenario
I am thinking through via YETUS-952, HBASE-23767.
Actions, Checks, Status... these are all so similar. Is there a document that
summarizes which should be used by whom?
> GitHub Checks integration
> -
>
> Key: YETUS-633
> URL: https://issues.apache.org/jira/browse/YETUS-633
> Project: Yetus
> Issue Type: Wish
> Components: Precommit
>Reporter: Sean Busbey
>Priority: Major
>
> GitHub has launched a feature for putting CI feedback into its own tab:
> https://github.com/apache/yetus/pull/12/checks
> Would be nice. lots of open questions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (YETUS-953) multijdk support does not report all unit results in "Other Tests" section
[ https://issues.apache.org/jira/browse/YETUS-953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051426#comment-17051426 ] Nick Dimiduk commented on YETUS-953: Attaching some screenshots. > multijdk support does not report all unit results in "Other Tests" section > -- > > Key: YETUS-953 > URL: https://issues.apache.org/jira/browse/YETUS-953 > Project: Yetus > Issue Type: Bug > Components: Precommit >Affects Versions: 0.11.1 >Reporter: Nick Dimiduk >Priority: Major > Attachments: Untitled 2.png, Untitled.png > > > One JDK is reported, but not the other. See > https://github.com/apache/hbase/pull/1214#issuecomment-591757259 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (YETUS-953) multijdk support does not report all unit results in "Other Tests" section
[ https://issues.apache.org/jira/browse/YETUS-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated YETUS-953: --- Attachment: Untitled 2.png > multijdk support does not report all unit results in "Other Tests" section > -- > > Key: YETUS-953 > URL: https://issues.apache.org/jira/browse/YETUS-953 > Project: Yetus > Issue Type: Bug > Components: Precommit >Affects Versions: 0.11.1 >Reporter: Nick Dimiduk >Priority: Major > Attachments: Untitled 2.png, Untitled.png > > > One JDK is reported, but not the other. See > https://github.com/apache/hbase/pull/1214#issuecomment-591757259 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (YETUS-953) multijdk support does not report all unit results in "Other Tests" section
[ https://issues.apache.org/jira/browse/YETUS-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated YETUS-953: --- Attachment: Untitled.png > multijdk support does not report all unit results in "Other Tests" section > -- > > Key: YETUS-953 > URL: https://issues.apache.org/jira/browse/YETUS-953 > Project: Yetus > Issue Type: Bug > Components: Precommit >Affects Versions: 0.11.1 >Reporter: Nick Dimiduk >Priority: Major > Attachments: Untitled.png > > > One JDK is reported, but not the other. See > https://github.com/apache/hbase/pull/1214#issuecomment-591757259 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (YETUS-953) multijdk support does not report all unit results in "Other Tests" section
[ https://issues.apache.org/jira/browse/YETUS-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated YETUS-953: --- Summary: multijdk support does not report all unit results in "Other Tests" section (was: multijak support does not report all unit results in "Other Tests" section) > multijdk support does not report all unit results in "Other Tests" section > -- > > Key: YETUS-953 > URL: https://issues.apache.org/jira/browse/YETUS-953 > Project: Yetus > Issue Type: Bug > Components: Precommit >Affects Versions: 0.11.1 >Reporter: Nick Dimiduk >Priority: Major > > One JDK is reported, but not the other. See > https://github.com/apache/hbase/pull/1214#issuecomment-591757259 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (YETUS-953) multijak support does not report all unit results in "Other Tests" section
Nick Dimiduk created YETUS-953: -- Summary: multijak support does not report all unit results in "Other Tests" section Key: YETUS-953 URL: https://issues.apache.org/jira/browse/YETUS-953 Project: Yetus Issue Type: Bug Components: Precommit Affects Versions: 0.11.1 Reporter: Nick Dimiduk One JDK is reported, but not the other. See https://github.com/apache/hbase/pull/1214#issuecomment-591757259 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (YETUS-952) Support GitHub Checks API for PR pre-commit builds
Nick Dimiduk created YETUS-952: -- Summary: Support GitHub Checks API for PR pre-commit builds Key: YETUS-952 URL: https://issues.apache.org/jira/browse/YETUS-952 Project: Yetus Issue Type: Improvement Components: Precommit Reporter: Nick Dimiduk GitHub provides an interface through which CI robots can interact with a PR, the [Checks API|https://developer.github.com/v3/checks/]. I'd like to see support added to the GitHub plugin for optionally posting back to the API as test-patch progresses through it's tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (YETUS-951) test-patch should complain more loudly about unrecognized PATCH_OR_ISSUE
Nick Dimiduk created YETUS-951:
--
Summary: test-patch should complain more loudly about unrecognized
PATCH_OR_ISSUE
Key: YETUS-951
URL: https://issues.apache.org/jira/browse/YETUS-951
Project: Yetus
Issue Type: Improvement
Components: Precommit
Reporter: Nick Dimiduk
I ended up losing a fair bit of time the other day, trying to work on a GitHub
PR pre-check without enabling the {{github}} plugin. The error messages apply
patch were obscure and unhelpful. I think the fall-through logic should be more
helpful, printing a message that says something like "Unrecognized patch
reference / don't know what to do with ${PATCH_OR_ISSUE}." The current
messaging just says "ERROR: ${PATCH_OR_ISSUE} does not apply to
${PATCH_OR_ISSUE}," which left me thinking somehow the git checkout wasn't
clean, when in fact there was no plugin support for the GitHub PR URL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (YETUS-943) Test patch fails to extract version information from a JDK11 jvm
[
https://issues.apache.org/jira/browse/YETUS-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047097#comment-17047097
]
Nick Dimiduk commented on YETUS-943:
[~aw] I tried to ping you over on [https://github.com/apache/hbase/pull/1214,]
not sure if it went through.
> Test patch fails to extract version information from a JDK11 jvm
>
>
> Key: YETUS-943
> URL: https://issues.apache.org/jira/browse/YETUS-943
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Affects Versions: 0.11.1
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
>Priority: Minor
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Trying to use pre-commit with AdoptOpenJDK11 in the test matrix, the logic
> for extracting the version information is incorrect.
> For JDK8, the output is
> {noformat}
> root@ab2cb99dbf34:/# /usr/lib/jvm/jdk8u232-b09/bin/java -version
> openjdk version "1.8.0_232"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_232-b09)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.232-b09, mixed mode)
> {noformat}
> which Yetus parses as "1.8.0_232".
> For JDK11, it's
> {noformat}
> root@ab2cb99dbf34:/# /usr/lib/jvm/jdk-11.0.6+10/bin/java -version
> openjdk version "11.0.6" 2020-01-14
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)
> {noformat}
> which Yetus parses as "2020-01-14".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (YETUS-944) Maven version number parsing broken for maven 3.5.4
[
https://issues.apache.org/jira/browse/YETUS-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042231#comment-17042231
]
Nick Dimiduk commented on YETUS-944:
Attaching screenshot from an [HBase
PR|https://github.com/apache/hbase/pull/1183#issuecomment-589460392].
!YETUS-944.png|width=638,height=101!
> Maven version number parsing broken for maven 3.5.4
> ---
>
> Key: YETUS-944
> URL: https://issues.apache.org/jira/browse/YETUS-944
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Affects Versions: 0.11.1
>Reporter: Nick Dimiduk
>Priority: Minor
> Attachments: YETUS-944.png
>
>
> It seems maven is not holding their version string format as part of their
> public API contract. With maven-3.5.4, I see
> {noformat}
> maven=2018-06-17T18:33:14Z)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (YETUS-944) Maven version number parsing broken for maven 3.5.4
[
https://issues.apache.org/jira/browse/YETUS-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated YETUS-944:
---
Attachment: YETUS-944.png
> Maven version number parsing broken for maven 3.5.4
> ---
>
> Key: YETUS-944
> URL: https://issues.apache.org/jira/browse/YETUS-944
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Affects Versions: 0.11.1
>Reporter: Nick Dimiduk
>Priority: Minor
> Attachments: YETUS-944.png
>
>
> It seems maven is not holding their version string format as part of their
> public API contract. With maven-3.5.4, I see
> {noformat}
> maven=2018-06-17T18:33:14Z)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (YETUS-943) Test patch fails to extract version information from a JDK11 jvm
[
https://issues.apache.org/jira/browse/YETUS-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk reassigned YETUS-943:
--
Assignee: Nick Dimiduk
> Test patch fails to extract version information from a JDK11 jvm
>
>
> Key: YETUS-943
> URL: https://issues.apache.org/jira/browse/YETUS-943
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Affects Versions: 0.11.1
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
>Priority: Minor
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Trying to use pre-commit with AdoptOpenJDK11 in the test matrix, the logic
> for extracting the version information is incorrect.
> For JDK8, the output is
> {noformat}
> root@ab2cb99dbf34:/# /usr/lib/jvm/jdk8u232-b09/bin/java -version
> openjdk version "1.8.0_232"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_232-b09)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.232-b09, mixed mode)
> {noformat}
> which Yetus parses as "1.8.0_232".
> For JDK11, it's
> {noformat}
> root@ab2cb99dbf34:/# /usr/lib/jvm/jdk-11.0.6+10/bin/java -version
> openjdk version "11.0.6" 2020-01-14
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)
> {noformat}
> which Yetus parses as "2020-01-14".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (YETUS-944) Maven version number parsing broken for maven 3.5.4
[
https://issues.apache.org/jira/browse/YETUS-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042227#comment-17042227
]
Nick Dimiduk commented on YETUS-944:
A study in {{men -version}}, at least on Mac OS, reveals
{noformat}
$ /usr/local/Cellar/maven/3.6.3/bin/mvn -version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/Cellar/maven/3.6.3/libexec
Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "Mac"
{noformat}
{noformat}
$ /usr/local/Cellar/maven@3.5/3.5.4/bin/mvn -version
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T11:33:14-07:00)
Maven home: /usr/local/Cellar/maven@3.5/3.5.4/libexec
Java version: 11.0.5, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "Mac"
{noformat}
{noformat}
$ /usr/local/Cellar/maven@3.3/3.3.9/bin/mvn -version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T08:41:47-08:00)
Maven home: /usr/local/Cellar/maven@3.3/3.3.9/libexec
Java version: 11.0.5, vendor: AdoptOpenJDK
Java home: /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "Mac"
{noformat}
{noformat}
$ /usr/local/Cellar/maven@3.2/3.2.5/bin/mvn -version
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
2014-12-14T09:29:23-08:00)
Maven home: /usr/local/Cellar/maven@3.2/3.2.5/libexec
Java version: 11.0.5, vendor: AdoptOpenJDK
Java home: /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
{noformat}
> Maven version number parsing broken for maven 3.5.4
> ---
>
> Key: YETUS-944
> URL: https://issues.apache.org/jira/browse/YETUS-944
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Affects Versions: 0.11.1
>Reporter: Nick Dimiduk
>Priority: Minor
>
> It seems maven is not holding their version string format as part of their
> public API contract. With maven-3.5.4, I see
> {noformat}
> maven=2018-06-17T18:33:14Z)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (YETUS-944) Maven version number parsing broken for maven 3.5.4
Nick Dimiduk created YETUS-944:
--
Summary: Maven version number parsing broken for maven 3.5.4
Key: YETUS-944
URL: https://issues.apache.org/jira/browse/YETUS-944
Project: Yetus
Issue Type: Bug
Components: Precommit
Affects Versions: 0.11.1
Reporter: Nick Dimiduk
It seems maven is not holding their version string format as part of their
public API contract. With maven-3.5.4, I see
{noformat}
maven=2018-06-17T18:33:14Z)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (YETUS-943) Test patch fails to extract version information from a JDK11 jvm
Nick Dimiduk created YETUS-943:
--
Summary: Test patch fails to extract version information from a
JDK11 jvm
Key: YETUS-943
URL: https://issues.apache.org/jira/browse/YETUS-943
Project: Yetus
Issue Type: Bug
Components: Precommit
Affects Versions: 0.11.1
Reporter: Nick Dimiduk
Trying to use pre-commit with AdoptOpenJDK11 in the test matrix, the logic for
extracting the version information is incorrect.
For JDK8, the output is
{noformat}
root@ab2cb99dbf34:/# /usr/lib/jvm/jdk8u232-b09/bin/java -version
openjdk version "1.8.0_232"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_232-b09)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.232-b09, mixed mode)
{noformat}
which Yetus parses as "1.8.0_232".
For JDK11, it's
{noformat}
root@ab2cb99dbf34:/# /usr/lib/jvm/jdk-11.0.6+10/bin/java -version
openjdk version "11.0.6" 2020-01-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)
{noformat}
which Yetus parses as "2020-01-14".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (YETUS-934) Precommit does not accept a caller's value of MAVEN_ARGS
[
https://issues.apache.org/jira/browse/YETUS-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk reassigned YETUS-934:
--
Assignee: (was: Nick Dimiduk)
> Precommit does not accept a caller's value of MAVEN_ARGS
>
>
> Key: YETUS-934
> URL: https://issues.apache.org/jira/browse/YETUS-934
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Reporter: Nick Dimiduk
>Priority: Major
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> We're trying to increase parallelism within maven over on HBASE-23779. The
> patch doesn't appear to work, seems like Yetus doesn't propagate the value of
> {{MAVEN_ARGS}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (YETUS-934) Precommit does not accept a caller's value of MAVEN_ARGS
[
https://issues.apache.org/jira/browse/YETUS-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk resolved YETUS-934.
Resolution: Invalid
Looks like I was taking a wrong-headed approach, as [~busbey] and [~aw]
explained in the PR comments. Thanks guys.
> Precommit does not accept a caller's value of MAVEN_ARGS
>
>
> Key: YETUS-934
> URL: https://issues.apache.org/jira/browse/YETUS-934
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
>Priority: Major
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> We're trying to increase parallelism within maven over on HBASE-23779. The
> patch doesn't appear to work, seems like Yetus doesn't propagate the value of
> {{MAVEN_ARGS}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (YETUS-934) Precommit does not accept a caller's value of MAVEN_ARGS
[
https://issues.apache.org/jira/browse/YETUS-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk reassigned YETUS-934:
--
Assignee: Nick Dimiduk
> Precommit does not accept a caller's value of MAVEN_ARGS
>
>
> Key: YETUS-934
> URL: https://issues.apache.org/jira/browse/YETUS-934
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We're trying to increase parallelism within maven over on HBASE-23779. The
> patch doesn't appear to work, seems like Yetus doesn't propagate the value of
> {{MAVEN_ARGS}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (YETUS-934) Precommit does not accept a caller's value of MAVEN_ARGS
Nick Dimiduk created YETUS-934:
--
Summary: Precommit does not accept a caller's value of MAVEN_ARGS
Key: YETUS-934
URL: https://issues.apache.org/jira/browse/YETUS-934
Project: Yetus
Issue Type: Bug
Components: Precommit
Reporter: Nick Dimiduk
We're trying to increase parallelism within maven over on HBASE-23779. The
patch doesn't appear to work, seems like Yetus doesn't propagate the value of
{{MAVEN_ARGS}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (YETUS-934) Precommit does not accept a caller's value of MAVEN_ARGS
[
https://issues.apache.org/jira/browse/YETUS-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031868#comment-17031868
]
Nick Dimiduk commented on YETUS-934:
I think this is your issue, [~stack].
> Precommit does not accept a caller's value of MAVEN_ARGS
>
>
> Key: YETUS-934
> URL: https://issues.apache.org/jira/browse/YETUS-934
> Project: Yetus
> Issue Type: Bug
> Components: Precommit
>Reporter: Nick Dimiduk
>Priority: Major
>
> We're trying to increase parallelism within maven over on HBASE-23779. The
> patch doesn't appear to work, seems like Yetus doesn't propagate the value of
> {{MAVEN_ARGS}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (YETUS-930) Interrupt signal not pushed down to running tool
Nick Dimiduk created YETUS-930:
--
Summary: Interrupt signal not pushed down to running tool
Key: YETUS-930
URL: https://issues.apache.org/jira/browse/YETUS-930
Project: Yetus
Issue Type: Improvement
Components: Precommit
Reporter: Nick Dimiduk
Interrupting a running build from a Jenkins job takes a little while. Looks
like the interrupt request isn't pushed down to, in this case, the running
maven process. From the Jenkins log
{noformat}
19:15:34 cd
/home/jenkins/jenkins-slave/workspace/Base-PreCommit-GitHub-PR_PR-1020/src
19:15:34 /usr/share/maven/bin/mvn --batch-mode
-Dmaven.repo.local=/home/jenkins/jenkins-slave/workspace/Base-PreCommit-GitHub-PR_PR-1020/yetus-m2/hbase-master-patch-1
clean verify -fae --batch-mode -pl hbase-shaded/hbase-shaded-check-invariants
-am -Dtest=NoUnitTests -DHBasePatchProcess -Prelease -Dmaven.javadoc.skip=true
-Dcheckstyle.skip=true -Dfindbugs.skip=true >
/home/jenkins/jenkins-slave/workspace/Base-PreCommit-GitHub-PR_PR-1020/out/branch-shadedjars.txt
2>&1
Aborted by ndimiduk
19:17:42 Sending interrupt signal to process
Click here to forcibly terminate running steps
Aborted by ndimiduk
19:18:02 After 20s process did not stop
19:18:12 Sending interrupt signal to process
Click here to forcibly terminate running steps
{noformat}
The Yetus process does honor the interrupt request, so I don't think it's a
bug. Simply could be better.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (YETUS-929) test-patch incorrectly reports malformed xml in a patch
[ https://issues.apache.org/jira/browse/YETUS-929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17014614#comment-17014614 ] Nick Dimiduk commented on YETUS-929: Ah indeed. Thanks. > test-patch incorrectly reports malformed xml in a patch > --- > > Key: YETUS-929 > URL: https://issues.apache.org/jira/browse/YETUS-929 > Project: Yetus > Issue Type: Bug > Components: Precommit >Affects Versions: 0.11.1 >Reporter: Nick Dimiduk >Priority: Major > > I have a PR wherein [Yetus fails the patch| > https://github.com/apache/hbase/pull/1010#issuecomment-573157065] in the XML > check. However, visual inspection of the patch reveals nothing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (YETUS-929) test-patch incorrectly reports malformed xml in a patch
Nick Dimiduk created YETUS-929: -- Summary: test-patch incorrectly reports malformed xml in a patch Key: YETUS-929 URL: https://issues.apache.org/jira/browse/YETUS-929 Project: Yetus Issue Type: Bug Components: Precommit Affects Versions: 0.11.1 Reporter: Nick Dimiduk I have a PR wherein [Yetus fails the patch| https://github.com/apache/hbase/pull/1010#issuecomment-573157065] in the XML check. However, visual inspection of the patch reveals nothing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (YETUS-928) @author checking is overly aggressive
Nick Dimiduk created YETUS-928: -- Summary: @author checking is overly aggressive Key: YETUS-928 URL: https://issues.apache.org/jira/browse/YETUS-928 Project: Yetus Issue Type: Bug Components: Precommit Reporter: Nick Dimiduk It looks like the author check is scanning the entire content of the patch, comment included. Thus it triggers a false positive when the git commit contains the text "@author". For an example, see https://github.com/apache/yetus/pull/81. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (YETUS-926) Add visual separation to console report summary
[ https://issues.apache.org/jira/browse/YETUS-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk resolved YETUS-926. Resolution: Fixed Thanks [~busbey] > Add visual separation to console report summary > --- > > Key: YETUS-926 > URL: https://issues.apache.org/jira/browse/YETUS-926 > Project: Yetus > Issue Type: Improvement > Components: Precommit >Reporter: Nick Dimiduk >Assignee: Nick Dimiduk >Priority: Minor > Fix For: 0.12.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The final output table is a wall of text. If you squint a little, you can see > that there are subsections contained within. Add some visual separation > between sections so that one can navigate the results. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (YETUS-926) Add visual separation to console report summary
[ https://issues.apache.org/jira/browse/YETUS-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated YETUS-926: --- Fix Version/s: 0.12.0 > Add visual separation to console report summary > --- > > Key: YETUS-926 > URL: https://issues.apache.org/jira/browse/YETUS-926 > Project: Yetus > Issue Type: Improvement > Components: Precommit >Reporter: Nick Dimiduk >Assignee: Nick Dimiduk >Priority: Minor > Fix For: 0.12.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The final output table is a wall of text. If you squint a little, you can see > that there are subsections contained within. Add some visual separation > between sections so that one can navigate the results. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (YETUS-926) Add visual separation to console report summary
Nick Dimiduk created YETUS-926: -- Summary: Add visual separation to console report summary Key: YETUS-926 URL: https://issues.apache.org/jira/browse/YETUS-926 Project: Yetus Issue Type: Improvement Components: Precommit Reporter: Nick Dimiduk Assignee: Nick Dimiduk The final output table is a wall of text. If you squint a little, you can see that there are subsections contained within. Add some visual separation between sections so that one can navigate the results. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (YETUS-924) Update site "Documentation" dropdown with latest release
[ https://issues.apache.org/jira/browse/YETUS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16972744#comment-16972744 ] Nick Dimiduk commented on YETUS-924: Nope, it's not available in the drop-down. No way to navigate back to the "root" of the documentation tree. What am I missing? > Update site "Documentation" dropdown with latest release > > > Key: YETUS-924 > URL: https://issues.apache.org/jira/browse/YETUS-924 > Project: Yetus > Issue Type: Task > Components: website and documentation >Reporter: Nick Dimiduk >Priority: Major > Attachments: Untitled.png > > > It seems our release process doesn't include updating the website > "documentation" drop-down with a link to include the latest release. Right > now the latest available version is 0.10.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (YETUS-924) Update site "Documentation" dropdown with latest release
[ https://issues.apache.org/jira/browse/YETUS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated YETUS-924: --- Attachment: Untitled.png > Update site "Documentation" dropdown with latest release > > > Key: YETUS-924 > URL: https://issues.apache.org/jira/browse/YETUS-924 > Project: Yetus > Issue Type: Task > Components: website and documentation >Reporter: Nick Dimiduk >Priority: Major > Attachments: Untitled.png > > > It seems our release process doesn't include updating the website > "documentation" drop-down with a link to include the latest release. Right > now the latest available version is 0.10.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (YETUS-924) Update site "Documentation" dropdown with latest release
Nick Dimiduk created YETUS-924: -- Summary: Update site "Documentation" dropdown with latest release Key: YETUS-924 URL: https://issues.apache.org/jira/browse/YETUS-924 Project: Yetus Issue Type: Task Components: website and documentation Reporter: Nick Dimiduk It seems our release process doesn't include updating the website "documentation" drop-down with a link to include the latest release. Right now the latest available version is 0.10.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (YETUS-923) Expose volume mount options for users of Docker Desktop
[
https://issues.apache.org/jira/browse/YETUS-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16967130#comment-16967130
]
Nick Dimiduk commented on YETUS-923:
Attaching a patch that plumbs through the {{delegated}} volume mount option.
Reduces the docker build time to ~30 minutes.
> Expose volume mount options for users of Docker Desktop
> ---
>
> Key: YETUS-923
> URL: https://issues.apache.org/jira/browse/YETUS-923
> Project: Yetus
> Issue Type: Improvement
> Components: Precommit
>Reporter: Nick Dimiduk
>Priority: Major
> Attachments: YETUS-923.demo.patch
>
>
> Running builds in docker using Docker Desktop on a Mac is incredibly slow.
> Using HBase as a testing tools, a {{man clean install -DskipTests}} run
> "natively" takes about ~2 minutes while the same command run within the
> Docker Desktop container environment takes ~45 minutes. Apparently this is to
> be expected, but can be improved by specifying a [volume mount
> option|https://docs.docker.com/docker-for-mac/osxfs-caching/]. Right now
> there's no way to expose such an option to the user. Ideally pre-commit could
> even detect the environment and apply the necessary options accordingly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (YETUS-923) Expose volume mount options for users of Docker Desktop
[
https://issues.apache.org/jira/browse/YETUS-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated YETUS-923:
---
Attachment: YETUS-923.demo.patch
> Expose volume mount options for users of Docker Desktop
> ---
>
> Key: YETUS-923
> URL: https://issues.apache.org/jira/browse/YETUS-923
> Project: Yetus
> Issue Type: Improvement
> Components: Precommit
>Reporter: Nick Dimiduk
>Priority: Major
> Attachments: YETUS-923.demo.patch
>
>
> Running builds in docker using Docker Desktop on a Mac is incredibly slow.
> Using HBase as a testing tools, a {{man clean install -DskipTests}} run
> "natively" takes about ~2 minutes while the same command run within the
> Docker Desktop container environment takes ~45 minutes. Apparently this is to
> be expected, but can be improved by specifying a [volume mount
> option|https://docs.docker.com/docker-for-mac/osxfs-caching/]. Right now
> there's no way to expose such an option to the user. Ideally pre-commit could
> even detect the environment and apply the necessary options accordingly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (YETUS-923) Expose volume mount options for users of Docker Desktop
Nick Dimiduk created YETUS-923:
--
Summary: Expose volume mount options for users of Docker Desktop
Key: YETUS-923
URL: https://issues.apache.org/jira/browse/YETUS-923
Project: Yetus
Issue Type: Improvement
Components: Precommit
Reporter: Nick Dimiduk
Running builds in docker using Docker Desktop on a Mac is incredibly slow.
Using HBase as a testing tools, a {{man clean install -DskipTests}} run
"natively" takes about ~2 minutes while the same command run within the Docker
Desktop container environment takes ~45 minutes. Apparently this is to be
expected, but can be improved by specifying a [volume mount
option|https://docs.docker.com/docker-for-mac/osxfs-caching/]. Right now
there's no way to expose such an option to the user. Ideally pre-commit could
even detect the environment and apply the necessary options accordingly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (YETUS-922) Precommit qualitative checks vote be -0 on overall improvement
Nick Dimiduk created YETUS-922:
--
Summary: Precommit qualitative checks vote be -0 on overall
improvement
Key: YETUS-922
URL: https://issues.apache.org/jira/browse/YETUS-922
Project: Yetus
Issue Type: Improvement
Components: Precommit
Reporter: Nick Dimiduk
Looking at the output over on
[hbase/775|https://github.com/apache/hbase/pull/775#issuecomment-547725241], I
think the -1 votes on qualitative checks are a bit harsh. The tests I'm looking
at are {{javac}} and {checkstyle}}, where we have a qualitative measure of
change in quality. In this case, the patch improved quality by reducing the
overall number of failure occurrences. I think these should be voted as -0
rather than -1. I suspect the reasoning behind the -1 vote is that the patch is
viewed to have introduced new failures. The thing is, with patches that
refactor code, this simple diff isn't able to distinguish between an actual new
failure and a moved failure.
I could also argue that they should actually be +1 when {{total}} is less than
{{previous}} because it's positive trajectory for the code base.
{noformat}
javac | hbase-server generated 1 new + 3 unchanged - 3 fixed = 4 total (was 6)
checkstyle | hbase-server: The patch generated 12 new + 270 unchanged - 37
fixed = 282 total (was 307)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
