From e182686b67900e21f2ada8ee635cd2208b42dfee Mon Sep 17 00:00:00 2001 From: Elias Date: Wed, 21 Feb 2024 17:05:45 +0100 Subject: [PATCH] Update documentation. --- README.adoc | 34 +++++++ README.md | 191 ---------------------------------------- doc/Overview.adoc | 139 +++++++++++++++++++++++++++++ doc/Usage.adoc | 163 ++++++++++++++++++++++++++++++++++ gitbark/cli/__main__.py | 6 +- pyproject.toml | 2 +- 6 files changed, 340 insertions(+), 195 deletions(-) create mode 100644 README.adoc delete mode 100644 README.md create mode 100644 doc/Overview.adoc create mode 100644 doc/Usage.adoc diff --git a/README.adoc b/README.adoc new file mode 100644 index 0000000..dcf2a68 --- /dev/null +++ b/README.adoc @@ -0,0 +1,34 @@ +== GitBark + +A framework that validates commits based on a set of fully customizable rules. This tool empowers you to enforce specific conditions, ensuring the integrity and adherence of your commits to project standards. Explore GitBark to elevate the validation process for a more robust and reliable version control workflow. + +**NOTE: This is work in progress** + +=== License + +.... +Copyright 2024 Yubico AB + +Licensed 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. +.... + +=== Installation +Currently GitBark can only be installed from source using the following command: + + pip install "git+https://github.com/YubicoLabs/gitbark.git + +=== Usage +Read the link:https://github.com/YubicoLabs/gitbark/blob/main/doc/Usage.adoc[Usage Guide] for instructions on how to use GitBark. + +=== Documentation +Read the link:https://github.com/YubicoLabs/gitbark/blob/main/doc/Overview.adoc[Overview] for a more comprehensive overview of GitBark. \ No newline at end of file diff --git a/README.md b/README.md deleted file mode 100644 index 8e84970..0000000 --- a/README.md +++ /dev/null @@ -1,191 +0,0 @@ -# GitBark - -`GitBark` is a framework that protects the integrity of git repositories. Its primary objective is to enforce strict adherence to predefined rules and policies for git commits. - - -**NOTE: This is work in progress** - -# License -``` -Copyright 2023 Yubico AB - -Licensed 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. -``` - -**Table of contents** -- [Usage](#usage) -- [Installation](#installation) -- [Commit Rules](#commit-rules) -- [Bark Rules](#bark-rules) -- [Receiving updates](#receiving-updates) - -# Usage -``` -Usage: bark [OPTIONS] COMMAND [ARGS]... - -Options: - --help Show this message and exit. - -Commands: - install Install GitBark in repo. - verify Verify repository or branch. -``` - -The `--help` argument can also be used to get detailed information about specific subcommands. - -``` -bark verify --help -``` - -# Installation -Currently GitBark can only be installed from source using the following command: - -``` -pip install "git+https://github.com/YubicoLabs/gitbark.git" -``` - -# Setup - -## 1. Define the initial rules for a branch. - -1. Checkout the branch you want to enforce rules on (e.g. the `main` branch). -2. In the root of your repository create a folder named `.gitbark`. This folder will contain all GitBark related stuff. -3. Within the `.gitbark` folder create a file named `commit_rules.yaml`. This file should define the [commit-rules](#commit-rules) that should apply. The rules that you define depend on the BarkModules you use. In this example let's assume we use [bark-core](https://github.com/YubicoLabs/gitbark-core), and want to use the `require_signature` rule. We will populate the `commit_rules.yaml` file as follows - ```yaml - rules: - - rule: require_signature - args: [authorized_keys=alice.pub] - ``` - - In this case, we will also add `alice.pub` to a newly created folder `.pubkeys/` with the path `.gitbark/.pubkeys`. This is required by the rule, see [here](https://github.com/YubicoLabs/gitbark-core#signatures). - -4. Once you are satisified with everything, save the changes and commit. - -## 2. Define the initial bark rules -1. Create the bark rules branch using ```git checkout --orphan bark_rules```. You might want to run `git rm -rf .` to start from a clean state. -2. Once again, create the `.gitbark` folder. -3. Within `.gitbark` create the `commit_rules.yaml` file in the same way as in step 1.3. -4. Within `.gitbark` create a file named `bark_rules.yaml`. This file should specify the BarkModules to import, and what [bootstrap](#bootstrap) commits should be used when validating different branches. An example of how that might look like: - ```yaml - modules: - - https://github.com/YubicoLabs/gitbark-core.git - branches: - - pattern: main - bootstrap: 50ef360f31a64ab54b103acbf57f3d38e501978d # commit hash from step 1.3. - ff_only: True - ``` - This `bark_rules.yaml` configuration tells GitBark that we want to use the `gitbark-core` module, and that the `main` branch should be validated using a specific commit as the bootstrap (in this case the one we created in step 1.3). - -5. Once you are satisfied, save the changes and commit. - -## 3. Install -When you've finished the above steps you are ready to install GitBark on your repository. To do that run `bark install`. The first time you run this you will be prompted to verify the bootstrap commit for the `bark_rules` branch. If the installation succeeds you can try it out by committing changes that violate the rules etc. - - -# Commit Rules -Commit rules can be thought of as a set of conditions that a commit must meet to be considered valid. These rules are defined within a YAML file named `commit_rules.yaml`, which is checked into the git repository `GitBark` is configured to run on. Since this file is under version control, every commit points to a specific version of the `commit_rules.yaml` file. - -## Specification -The specification of the `commit_rules.yaml` file is shown below: - - -### commit_rules.yaml - top level -| Attribute | Description | -| ----------- | ----------- | -| [`rules`](#commit_rulesyaml---rules) | the list of rules to be enforced (all rules within this clause need to be satisfied) | -| | | - -### commit_rules.yaml - rules -| Attribute | Description | -| ----------- | ----------- | -| `rule` | the id of the rule to enforce | -| `args` | (optional) the list of additional parameters to pass to the rule | -| `any` | (optional) a list of rules to be enforced (at least one of the rules within this clause needs to be satisfied)| -||| - -### Example specification -An example specification using rules exposed by [`GitBark Core`](https://github.com/YubicoLabs/gitbark-core) - -```yaml - rules: - - rule: require_signature - args: [authorized_keys=alice.pub] -``` - -## Validation -A commit is considered valid if it passes the rules defined in its "nearest" **valid** ancestor commits. We call these commits **validators**, which are the commits that define the rules that a new commit should be validated against. The **validators** for a commit **c** are chosen the following way: - -* If the parent of **c** itself is valid, the parent becomes a **validator** for **c** -* If the parent of **c** is not valid, **c** inherits all **validators** that the parent has. - -Once the validator commits are collected, the commit rules defined in them are applied to the commit being validated. The commit is considered valid if it passes ALL these rules. - -## Bootstrap -Since the validation follows a recursive pattern, at some point we will reach that does not have any parents or has parents that do not define any rules. This present a bootstrapping issue which we solve using a bootstrap commit, that define the initial rules for a branch and is explicitly trusted and considered valid. Bootstrap commits for specific branches are defined in [Bark Rules](#bark-rules). - -# Bark Rules -Bark Rules are per-repository, and define the rules for named branches (or branches matching a pattern), such as if we should allow rewrites to history (force pushes), and if they should be validated according to any commit rules using a specific bootstrap commit. Furthermore, these rules define the GitBark modules (modules that expose commit rules and subcommands) to import into the project. - -The Bark Rules are stored in a file named `bark_rules.yaml` which is checked into a special orphaned branch, named `bark_rules`. - -## Specification -The specification of the `bark_rules.yaml` file is listed below: - -### bark_rules.yaml - top level -| Attribute | Description | -| ----------- | ----------- | -| [`modules`](#bark_rulesyaml---modules) | list of GitBark modules | -| [`branches`](#bark_rulesyaml---branches) | list of configurations for branches | - -### bark_rules.yaml - modules -| Attribute | Description | -| -------------- | -------------------------- | -| repo | the Git repository URL | -| rev | the revision to clone from | - -### bark_rules.yaml - branches -| Attribute | Description | -| -------------- | ----------------------------- | -| pattern | the branch name regex pattern | -| ff_only | (optional: default `False`) set to `True` to enforce fast-forward only changes. | -| bootstrap | the hash of the bootstrap commit to use when validating the branch | - - -### Example specification - -```yaml -modules: - - repo: https://github.com/YubicoLabs/gitbark-core - rev: v1.2.3 -branches: - - pattern: main - bootstrap: 029ab6a31f8f1e3f03f5db8c5d938c51d2c5f73b - ff_only: True -``` -This specification implies that the "main" branch, need to be valid, using the commit with hash *"029ab6a31f8f1e3f03f5db8c5d938c51d2c5f73b"* as the bootstrap commit. Furthermore, it states that only fast-forward changes are allowed. - -## Root of trust -Since the `bark_rules.yaml` file among other things defines what bootstrap commits should be used to validate different branches, it is essential to protect the integrity of the `bark_rules` branch itself. As such, the `bark_rules` branch has Commit Rules itself that are validated using the root commit (of the `bark_rules` branch) as bootstrap. All other bootstrap commits for commit validation are covered by this bootstrap commit. As such, when the system is initialized, the user is asked to confirm the hash of this commit (like when connecting to an SSH server the first time). - -# Receiving updates -When receiving repository updates, typically via the "push", "pull" commands of Git, GitBark enforces the rules on any changes to existing local refs (that should be validated according to Bark Rules), and refuses to receive violating changes. - -This way, rules can be enforced securely across repository clones without needing to trust intermediate clones. For example, a team developers may enforce specific rules on their local clones even if a central Git hosting service does not yet support enforcing those rules, and may allow updates that violate those rules. The local clones will always remain in a consistent and trustworthy state in relation to established rules. - - - - - - - - diff --git a/doc/Overview.adoc b/doc/Overview.adoc new file mode 100644 index 0000000..f3423da --- /dev/null +++ b/doc/Overview.adoc @@ -0,0 +1,139 @@ +== Overview +This document provides a comprehensive overview of GitBark and its components, and how they can be used to ensure the integrity of source code repositories. For a quick guide on how to get started, refer to our link:https://github.com/YubicoLabs/gitbark/blob/main/doc/Usage.adoc[Usage Guide]. + +== Table of Contents + +* <> +* <> +* <> +* <> + +=== Commit Rules +Commit rules can be thought of as a set of conditions that a commit must meet to be considered valid. This section explores the concept of commit rules and their implementation and usage within GitBark. + +==== Implementation +Technically, commit rules are functions that operate on commit objects, potentially raising an exception to indicate whether the commit satisfies specified rule conditions. These functions are implemented in Python modules, referred to as Bark Modules. Serving as self-contained units, these modules encapsulate the behavior of one or more rules and reside outside GitBark, typically in Git repositories or on PyPI. They can be seamlessly integrated into GitBark for rule evaluation (refer to <> for more details). + +While developers have the flexibility to create custom commit rules, we have pre-built a Bark Module called (link:https://github.com/YubicoLabs/gitbark-core[GitBark Core]), encompassing a collection of useful rules ready for immediate use. + +==== Specification +To define the commit rules applicable to commits, developers must specify them in `/.bark/commit_rules.yaml`, which should be checked into the repository. Since this file is under version control, every commit points to a specific version of the `commit_rules.yaml` file (more on why this is important is described in the upcoming sections). + +The `commit_rules.yaml` file follows a specific structure with a list of rules. Each rule may have optional parameters as described below: + +[source, yaml] +---- +rules: +- rule_name_1: + parameter1: value1 + parameter2: value2 +- rule_name_2: + # No parameters for rule_name_2 +- rule_name_3: + parameter1: value1 + parameter2: value2 + parameter3: value3 +---- +The `rule_name` serves as the identifier for the rule specified by the corresponding Bark Module. The same principle applies to `parameter`; some rules support parameters while others do not, depending on the implementation. + +By default, all rules in the outer `rules` clause are validated using AND logic (all rules need to be satisfied). However, one can use the `any` clause to create more complex rule patterns. Rules defined in this clause are validated using OR logic (at least one of the rules need to be satisfied). See example below: + +[source, yaml] +---- +rules: +- commit_rule_name_1: + parameter1: value1 + parameter2: value2 +- any: + - commit_rule_name_2: + # No parameters for rule_name_2 + - commit_rule_name_3: + parameter1: value1 + parameter2: value2 + parameter3: value3 +---- + +==== Validation +A commit is considered valid if it passes the rules defined in its "nearest" **valid** ancestor commits. We call these commits **validators**, which are the commits that define the rules that a new commit should be validated against. The **validators** for a commit **c** are chosen the following way: + +* If the parent of **c** itself is valid, the parent becoms a **validator** for **c**. +* If the parent of **c** is not valid, **c** inherits all **validators** that the parent has. + +Once the validator commits are collected, the commit rules defined in them are applied to the commit being validated. The commit is considered valid if it passes **ALL** these rules. + +===== Bootstrap +Since the validation follows a recursive pattern, at some point we will reach a commit that does not have any parents or has parents that do not define any rules. This presents a bootstrapping issue which we solve using a bootstrap commit, that define the initial rules for a branch and is explicitly trusted and considered valid. Bootstrap commits for specific branches are defined in <>. + +=== Bark Rules +Bark Rules are repository-specific and define the configuration for validating specific branches, specifying conditions and criteria for the validation process. This configuration is encapsulated within a file named `/.bark/bark_rules.yaml`, which is committed to an orphaned branch named `bark_rules`. + +==== Specification +The `bark_rules.yaml` file adheres to a structured format wherein bootstrap commits are associated with specific references, identified through a regex pattern match. This mechanism informs GitBark about which references (typically branches) to validate, using the designated bootstrap commit. The example below illustrates that `refs/heads/main` is configured for validation, with the commit having the hash `8bd6128c239e1735858927af6cc91a8cf46c1924` designated as the bootstrap. + +[source, yaml] +---- +project: +- bootstrap: 8bd6128c239e1735858927af6cc91a8cf46c1924 + refs: + - pattern: refs/heads/main +---- + +Besides specifying what branches should be validated using a specific bootstrap commit, the `bark_rules.yaml` file also allows us to define <>. + +===== Ref Rules +Ref Rules are rules tailored for specific references (branches). In contrast to Commit Rules, which are not reference-specific, Ref Rules exclusively apply to the commits a particular reference points to. This distinction enables the definition of distinct rules for various references, exemplified in the `bark_rules.yaml` file below. It's worth noting that Ref Rules adhere to the same pattern as Commit Rules. + +[source, yaml] +---- +project: +- bootstrap: 8bd6128c239e1735858927af6cc91a8cf46c1924 + refs: + - pattern: refs/heads/main + rules: + - ref_rule_name_1: + parameter1: value1 + - ref_rule_name_2: + - pattern: refs/heads/feat + rules: + - ref_rule_name_3: + parameter3: value3 +---- + +Ref Rules can also be defined for the `bark_rules` branch itself by including them in the `bark_rules` clause, as shown below: + +[source, yaml] +---- +bark_rules: +- ref_rule_name_1: + parameter1: value1 +project: +... +---- + +==== Root of trust +Since the `bark_rules.yaml` file among other things defines what bootstrap commits should be used to validate different branches, it is essential to protect the integrity of the `bark_rules` branch itself. As such, the `bark_rules` branch can have Commit Rules itself that are validated using the root commit (of the `bark_rules` branch) as bootstrap. All other bootstrap commits for commit validation are covered by this bootstrap commit. As such, when the system is initialized, the user is asked to confirm the hash of this commit (like when connecting to an SSH server the first time), as illustrated below. + +---- +$ bark install +The bootstrap commit (7b54840ecd6a484ec78314ff32e57fb38b4769bb) of the bark_rules branch has not been verified! +Do you want to trust this commit as the bootstrap for bark? [y/N]: +---- + + +=== Bark Modules +Commit Rules and Ref Rules are implemented as Python modules or packages, referred to as 'Bark Modules.' These modules reside outside of GitBark, typically hosted in Git repositories or available on PyPI. To utilize specific Commit Rules and Ref Rules, it is necessary to specify which Bark Modules to employ. This configuration is accomplished in the `bark_rules` branch within the `requirements.txt` file, adhering to the standard pip requirements file. When specified GitBark installs the specific modules in a virtual environment residing in the repository, so that they can be used during validation. + +Here is an example requirements file including link:https://github.com/YubicoLabs/gitbark-core[GitBark Core] as a Bark Module: + +---- +git+https://github.com/YubicoLabs/gitbark-core.git +---- + +=== Git Hooks +Upon receiving updates to the local repository, commonly triggered by actions such as `git pull`, `git commit`, and `git push`, GitBark offers automated verification in alignment with the specified rules. This seamless process is made possible through the integration of client-side Git hooks. This way, rules can be enforced securely across repository clones without needing to trust intermediate clones. For example, a team developers may enforce specific rules on their local clones even if a central Git hosting service does not yet support enforcing those rules, and may allow updates that violate those rules. The local clones will always remain in a consistent and trustworthy state in relation to established rules. + +While this particular functionality isn't enabled by default, we strongly recommend enabling it to ensure the repository consistently maintains a trustworthy and consistent state. Achieve this by executing the `bark install` command, which effortlessly installs the essential Git hooks. + + + + diff --git a/doc/Usage.adoc b/doc/Usage.adoc new file mode 100644 index 0000000..a2693ce --- /dev/null +++ b/doc/Usage.adoc @@ -0,0 +1,163 @@ +== Usage +Now that you have GitBark link:https://github.com/YubicoLabs/gitbark?tab=readme-ov-file#installation[installed], you can start using it. Here are some of the most common commands you'll need. + +=== Setup GitBark +To setup GitBark, `cd` into your Git repository and run `bark setup`. + +==== 1. Define Bark Modules +Begin by defining the Bark Modules you want to inlude (for more information on Bark Modules see link:https://github.com/YubicoLabs/gitbark/blob/main/doc/Overview.adoc#bark-modules[here]). The example below shows how to add the link:https://github.com/YubicoLabs/gitbark-core[GitBark Core] module. + +---- +$ bark setup +Define what Bark Modules to add! + +Module to add (leave blank to skip): git+https://github.com/YubicoLabs/gitbark-core.git +Module to add (leave blank to skip): +---- +Press Enter to continue and install the specified modules in your project. + +==== 2. Specify rules for the `bark_rules` branch +The next step involves specifying the rules for the `bark_rules` branch, which contains configuration details for validating specific branches (for more information on Bark Rules see link:https://github.com/YubicoLabs/gitbark/blob/main/doc/Overview.adoc#bark-rules[here]). + +===== 2.1 Commit Rules for the `bark_rules` branch +Choose whether to specify Commit Rules for the `bark_rules` branch (for more information on Commit Rules see link:https://github.com/YubicoLabs/gitbark/blob/main/doc/Overview.adoc#commit-rules[here]). The setup wizard lists available rules from the selected Bark Modules, enabling interactive rule selection. + +---- +Specify Commit Rules for the 'bark_rules' branch! + +Choose rule (leave blank to skip): + [0] file_not_modified Prevents modification to specific files. + [1] max_parents Specifies the maximum number of parents for a commit. + [2] require_signature Requires the commit to be signed. + [3] require_valid_parents Specifies whether non-valid parents should be allowed. + > 1 +---- + +After completing the rule setup, GitBark generates the commit rule specification that will be included in `commit_rules.yaml` (for more details on the `commit_rules.yaml` file see link:https://github.com/YubicoLabs/gitbark/blob/main/doc/Overview.adoc#specification[here]). + +---- +Generated 'commit_rules.yaml' + +rules: +- require_signature: + authorized_keys: john.pub + +Do you confirm generation? [y/N]: y +---- + +===== 2.2 Ref Rules for the `bark_rules` branch +Choose whether to define Ref Rules for the `bark_rules` branch. +As opposed to Commit Rules, these only apply to specific references (for more information on Ref Rules see link:https://github.com/YubicoLabs/gitbark/blob/main/doc/Overview.adoc#ref-rules[here]). + +---- +Specify Branch Rules for the 'bark_rules' branch! + +Choose rule (leave blank to skip): + [0] require_approval Requires commits on the ref to be *Approved*. + + [1] require_fast_forward Prevents force pushing (non-linear history). + > +---- + +After setup, Gitbark generates a ref rule specification that will be included in `bark_rules.yaml` (for more details on the `bark_rules.yaml` file see link:https://github.com/YubicoLabs/gitbark/blob/main/doc/Overview.adoc#specification-1[here]). +---- +Generated 'bark_rules.yaml' + +bark_rules: +- require_approval: + authorized_authors: + - john.doe@test.com + threshold: 1 +project: [] + +Do you confirm generation? [y/N]: y +Do you want 'bark' to commit the changes? [y/N]: y +---- + +==== 3. Specify rules for the `main` branch +Depending on which `branch` you initiated the `bark setup` command from, GitBark will prompt you to specify the rules for that branch (commonly the `main` branch). + +===== 3.1 Commit Rules for the `main` branch +Specify Commit Rules for the `main` branch, similar to process in <<2.1 Commit Rules for the `bark_rules` branch, 2.1>>. + +===== 3.2 Bootstrap for the `main` branch +Define the boostrap commit used when validating the `main` branch (for more information on Bootstrap commit see link:https://github.com/YubicoLabs/gitbark/blob/main/doc/Overview.adoc#bootstrap[here]). By default, it will prompt you with the current HEAD commit of the branch as shown below, but you can also choose another commit as the bootstrap by providing the hash. + +---- +Configure how the 'main' branch should be validated! + +Do you want to verify the 'main' branch using commit 80a177b2b7fc39b4dd664fcda0cd185457fbaaeb as bootstrap? [y/N]: +---- + +===== 3.3 Ref rules for the `main` branch +Specify Ref Rules for the `main` branch, similar to process in <<2.2 Ref Rules for the `bark_rules` branch, 2.2>>. + +===== 4. Finish +Upon successful completion you'll see the message + +---- +Bark is initialized! +---- + +This indicates the setup process is complete. + +=== Install hooks +To enable GitBark to validate repository changes triggered by commands like `git pull`, `git push`, and `git commit`, execute the command `bark install`. + +---- +$ bark install +---- + +Upon running this command, GitBark will prompt you to verify the bootstrap commit of the `bark_rules` branch (see more on why this is link:https://github.com/YubicoLabs/gitbark/blob/main/doc/Overview.adoc#root-of-trust[here]). Confirm the trustworthiness of this commit, as shown below: + +---- +The bootstrap commit (8339a8653f0becf50a79d13e3eb76cd28f383ff2) of the bark_rules branch has not been verified! +Do you want to trust this commit as the bootstrap for bark? [y/N]: y +---- + +Once confirmed, GitBark installs the necessary Git hooks in the repository, ensuring that automatic verification is seamlessly performed on subsequent changes. + +=== Verify branch +To manually verify a branch execute the command `bark verify`. + +---- +$ bark verify +---- + +By default this will verify the branch you are currently on. Alternatively, you can verify a single commit or a specific branch by providing a TARGET to, as shown below. + +---- +$ bark verify feat +---- + +To verify all branches specified for validation, use the `--all` flag: + +---- +$ bark verify --all +---- + +=== Protect a branch +To protect a branch and instruct GitBark how to validate a specific branch, use the command: + +---- +$ bark protect +---- + +Executing this command adds the current branch to `bark_rules.yaml` instructing GitBark to validate it during the verification process. It will also ask if you want to enforce any Ref Rules. + +When performing this operation, GitBark will also prompt you to specify a bootstrap commit to use for validating this branch. + + +=== Add Commit Rules Interactively +To interactively add commit rules for the current branch use the command: + +---- +$ bark add-rules +---- + +=== Add Bark Modules Interactively +To interactively add bark modules use the command: + +---- +$ bark add-modules +---- \ No newline at end of file diff --git a/gitbark/cli/__main__.py b/gitbark/cli/__main__.py index ba211d2..ac8c0b7 100644 --- a/gitbark/cli/__main__.py +++ b/gitbark/cli/__main__.py @@ -179,10 +179,10 @@ def protect(ctx): @click.pass_context def install(ctx): """ - Install GitBark modules in repo. + Install hooks. - This command assumes GitBark has been configured in the repository. If so, - it will verify it and install required GitBark modules and hooks. + Install GitBark in Git hooks, so that verification is performed automatically + on repository changes. """ project = ctx.obj["project"] diff --git a/pyproject.toml b/pyproject.toml index ac9dfa2..6738a95 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -5,7 +5,7 @@ version = "0.1.0" description = "A git repository consistency verification framework" authors = ["Elias Bonnici "] license = "APACHE-2.0" -readme = "README.md" +readme = "README.adoc" packages=[{include = "gitbark"}] [tool.poetry.dependencies]