aw-was-here commented on a change in pull request #144: URL: https://github.com/apache/yetus/pull/144#discussion_r500369809
########## File path: asf-site-src/source/documentation/in-progress/precommit/index.html.md ########## @@ -0,0 +1,164 @@ +<!--- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +--> + +# Basic Precommit + +<!-- MarkdownTOC levels="1,2,3" autolink="true" indent=" " bullets="*" bracket="round" --> + +* [Purpose](#purpose) +* [Goals](#goals) +* [Pre-requisites](#pre-requisites) + * [Base Requirements](#base-requirements) + * [Plug-ins](#plug-ins) + * [Bundled Plug-ins](#bundled-plug-ins) + * [Optional Plug-ins](#optional-plug-ins) +* [More information](#more-information) + +<!-- /MarkdownTOC --> + +# Purpose + +Performing reviews can be an overwhelming process. The more complex the base, the more comprehensive reviews end up. Building that functionality into the build itself is a full time job. Plus, if a new check is added, there is a good chance that the existing code has problems and just want to prevent new bits from making the existing problem worse. + +This is where Apache Yetus' precommit utilities come into the picture. + +All patches to the source base go through a test that does some (relatively) light checking to make sure the proposed change does not break unit tests and/or passes some other prerequisites such as code formatting guidelines. This is meant as a preliminary check for reviewers so that the basic patch is in a known state and for contributors to know if they have followed the project's guidelines. This check may also be used by individual developers to verify a patch prior to sending to the QA systems. + +# Goals + +* Everyone's time is valuable. The quicker contributors can get feedback and iterate, the more likely and faster their contribution will get checked in. A committer should be able to focus on the core issues of a contribution rather than details that can be determined automatically. +* Checks should be fast. There is no value in testing parts of the source tree that are not immediately impacted by a change. Unit testing is the target. They are not a replacement for full builds or integration tests. +* In many build systems (e.g., maven), a modular design has been picked. This modularity should be exploited to reduce the amount of checks that need to be performed. +* Projects that use the same language will, with a high degree of certainty, benefit from the same types of checks. +* Portability matters. Tooling should be as operating system and language agnostic as possible. + +# Pre-requisites + +Almost all of the precommit components are written in bash for maximum portability. As such, it mostly assumes the locations of commands to be in the file path. However, in many cases, this assumption may be overridden via command line options. + +For Solaris and Solaris-like operating systems, the default location for the POSIX binaries is in `/usr/xpg4/bin` and the default location for the GNU binaries is `/usr/gnu/bin`. Review comment: Makes sense! ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
