Apache
/
hbase
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

HBASE-27774 Move Dockerfile and python-requirements.txt used only by flaky-tests job 

Signed-off-by: Peter Somogyi <psomogyi@apache.org>
This commit is contained in:
Nick Dimiduk 2023-04-04 13:35:16 +02:00 committed by GitHub
parent 143e9b4ff6
commit 308cdb08c7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 15 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
dev-support/Dockerfile → dev-support/flaky-tests/Dockerfile
View File

@ -22,7 +22,7 @@
# dev-support/flaky-tests/flaky-reporting.Jenkinsfile
FROM ubuntu:22.04
COPY . /hbase/dev-support
COPY dev-support/flaky-tests/python-requirements.txt /hbase/dev-support/flaky-tests/
RUN DEBIAN_FRONTEND=noninteractive apt-get -qq -y update \
&& DEBIAN_FRONTEND=noninteractive apt-get -qq -y install --no-install-recommends \
@ -30,4 +30,4 @@ RUN DEBIAN_FRONTEND=noninteractive apt-get -qq -y update \
python3-pip='22.0.2+dfsg-*' \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/* \
&& pip3 install --no-cache-dir -r /hbase/dev-support/python-requirements.txt
&& pip3 install --no-cache-dir -r /hbase/dev-support/flaky-tests/python-requirements.txt

2
dev-support/flaky-tests/flaky-reporting.Jenkinsfile
View File

@ -45,7 +45,7 @@ pipeline {
declare -a flaky_args
flaky_args=("${flaky_args[@]}" --urls "${JENKINS_URL}/job/HBase%20Nightly/job/${BRANCH_NAME}" --is-yetus True --max-builds 20)
flaky_args=("${flaky_args[@]}" --urls "${JENKINS_URL}/job/HBase-Flaky-Tests/job/${BRANCH_NAME}" --is-yetus False --max-builds 50)
docker build -t hbase-dev-support dev-support
docker build -t hbase-dev-support -f dev-support/flaky-tests/Dockerfile .
docker run --ulimit nproc=12500 -v "${WORKSPACE}":/hbase -u `id -u`:`id -g` --workdir=/hbase hbase-dev-support \
./dev-support/flaky-tests/report-flakies.py --mvn -v -o output "${flaky_args[@]}"
'''

0
dev-support/python-requirements.txt → dev-support/flaky-tests/python-requirements.txt
View File

68
src/main/asciidoc/_chapters/developer.adoc
View File

@ -2254,75 +2254,31 @@ If you are new to submitting patches to open source or new to submitting patches
link:https://commons.apache.org/[Apache Commons Project].
It provides a nice overview that applies equally to the Apache HBase Project.
[[submitting.patches.create]]
==== Create Patch
Make sure you review <<common.patch.feedback,common.patch.feedback>> for code style. If your
patch
Make sure you review <<common.patch.feedback,common.patch.feedback>> for code style. If your patch
was generated incorrectly or your code does not adhere to the code formatting guidelines, you may
be asked to redo some work.
.Using submit-patch.py (recommended)
HBase enforces code style via a maven plugin. After you've written up your changes, apply the
formatter before committing.
[source,bourne]
----
$ dev-support/submit-patch.py -jid HBASE-xxxxx
----
Use this script to create patches, upload to jira and optionally create/update reviews on
Review Board. Patch name is automatically formatted as _(JIRA).(branch name).(patch number).patch_
to follow Yetus' naming rules. Use `-h` flag to know detailed usage information. Most useful options
are:
* `-b BRANCH, --branch BRANCH` : Specify base branch for generating the diff. If not specified,
tracking branch is used. If there is no tracking branch, error will be thrown.
* `-jid JIRA_ID, --jira-id JIRA_ID` : If used, deduces next patch version from attachments in the
jira and uploads the new patch. Script will ask for jira username/password for authentication.
If not set, patch is named <branch>.patch.
By default, it'll also create/update review board. To skip that action, use `-srb` option. It uses
'Issue Links' in the jira to figure out if a review request already exists. If no review
request is present, then creates a new one and populates all required fields using jira summary,
patch description, etc. Also adds this review's link to the jira.
Save authentication credentials (optional)::
Since attaching patches on JIRA and creating/changing review request on ReviewBoard requires
valid user authentication, the script will prompt you for username and password. To avoid the hassle every
time, set up `~/.apache-creds` with login details and encrypt it by following the steps in footer
of script's help message.
Python dependencies:: To install required python dependencies, execute
`pip install -r dev-support/python-requirements.txt` from the master branch.
.Manually
. Use `git rebase -i` first, to combine (squash) smaller commits into a single larger one.
. Create patch using IDE or Git commands. `git format-patch` is preferred since it preserves patch
author's name and commit message. Also, it handles binary files by default, whereas `git diff`
ignores them unless you use the `--binary` option.
. Patch name should be as follows to adhere to Yetus' naming convention: +
`(JIRA).(branch name).(patch number).patch` +
For eg. HBASE-11625.master.001.patch, HBASE-XXXXX.branch-1.2.0005.patch, etc.
. Attach the patch to the JIRA using `More->Attach Files` then click on btn:[Submit Patch]
button, which'll trigger Hudson job to check patch for validity.
. If your patch is longer than a single screen, also create a review on Review Board and
add the link to JIRA. See <<reviewboard,reviewboard>>.
---
$ mvn spotless:apply
---
When your commit is ready, present it to the community as a
link:https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests[GitHub Pull Request].
.Few general guidelines
* Always patch against the master branch first, even if you want to patch in another branch.
HBase committers always apply patches first to the master branch, and backport if necessary.
* Submit one single patch for a fix. If necessary, squash local commits to merge local commits into
a single one first. See this
HBase committers always apply patches first to the master branch, and backport as necessary. For
complex patches, you may be asked to perform the backport(s) yourself.
* Submit one single PR for a single fix. If necessary, squash local commits to merge local commits
into a single one first. See this
link:http://stackoverflow.com/questions/5308816/how-to-use-git-merge-squash[Stack Overflow
question] for more information about squashing commits.
* Please understand that not every patch may get committed, and that feedback will likely be
provided on the patch.
* If you need to revise your patch, leave the previous patch file(s) attached to the JIRA, and
upload a new one with incremented patch number. +
Click on btn:[Cancel Patch] and then on btn:[Submit Patch] to trigger the presubmit run.
[[submitting.patches.tests]]
==== Unit Tests