diff --git a/docs/Makefile b/docs/Makefile index 8515d526e96be53f377cc92cb14f11bd75b81a2d..65f5e091213d36ce7bee80fd6aab0b9ae614a2eb 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -56,7 +56,7 @@ manuals: \ @../tezos-admin-client man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/tezos-admin-client.html @../tezos-signer man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/tezos-signer.html @../tezos-codec man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/tezos-codec.html - @../tezos-snoop man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/tezos-snoop.html + @../octez-snoop man -verbosity 3 -format html | sed "s#${HOME}#\$$HOME#g" > api/tezos-snoop.html # artificially depend on docexes to avoid concurrent dunes .PHONY: odoc diff --git a/docs/alpha/transaction_rollups.rst b/docs/alpha/transaction_rollups.rst index b3270031a1aa547572daeee07050214c4073270b..76762e7a2ddbfdbf2850c4503a0670755de007a7 100644 --- a/docs/alpha/transaction_rollups.rst +++ b/docs/alpha/transaction_rollups.rst @@ -588,7 +588,7 @@ provides a shell with the rollup node and client available in the Similarly to other Octez binaries like the baker, there exists a rollup node and client for each version of the Tezos protocol. You can use the ``alpha`` binaries on testnets like `Mondaynet or - Dailynet _`. This is the recommended way to + Dailynet `_. This is the recommended way to experiment with Transaction Rollups, as the finality period on Mondaynet and Dailynet is significantly shorter than on mainnet or other testnets. diff --git a/docs/developer/contributing.rst b/docs/developer/contributing.rst index 4b9cc52d46d788704475ee46a98b2c0fabe5ccc8..a9031db248de51b37daabb5b7abb556f8a56e1f5 100644 --- a/docs/developer/contributing.rst +++ b/docs/developer/contributing.rst @@ -25,10 +25,10 @@ Stretch*), the network you are connected to (e.g. *Carthagenet*), the binary or component (e.g. *tezos-node crashes* or *rpc X returns Y while Z was expected*). -Going further -~~~~~~~~~~~~~ +Fixing typos +~~~~~~~~~~~~ -You may also want to fix some typos and minor errors or incoherencies in the *documentation*, which is situated in the ``docs/`` subfolder of the code repository. +You may also want to fix some typos and minor errors or incoherencies in the *documentation*, which is situated in the ``docs/`` subfolder of the code repository, or within *comments* or *docstrings* within the code. Small tweaks like these can be contributed without creating a merge request and commits can rather be pushed directly to the ``typo-doc`` branch in the ``tezos/tezos`` repository. This branch is regularly merged into the master branch, e.g., every one or two weeks. (If the branch has been automatically deleted following a merge, just create it again.) This periodic merging is implemented by a series of MRs named "the typo train", created for you by a volunteer, and batching the currently pending fixes. @@ -38,7 +38,10 @@ The current edition of the typo train MR can be found in meta-issue :gl:`#2329`. If you don't have enough permissions to push to the branch above, you can still make commits in your own fork of the Octez repository, and ask for them to be cherry-picked on the typo/train on the ``#documentation`` channel on the Tezos Dev Slack space. Alternatively, you may of course create your own MRs for submitting your changes, without using the typo train. -To directly contribute to the *codebase*, expertise in a few areas is necessary. +Going further +~~~~~~~~~~~~~ + +To directly contribute to the *code* itself, expertise in a few areas is necessary. First, make sure that you are proficient enough in OCaml. The community website https://ocaml.org gives a few useful pointers for that. In diff --git a/docs/developer/testing.rst b/docs/developer/testing.rst index 991e51012cb4fd6ac697f88cd450b0d18a418dea..3089af6c57cb46fe94ee709143aa0ede09b2d2b3 100644 --- a/docs/developer/testing.rst +++ b/docs/developer/testing.rst @@ -112,18 +112,12 @@ Typical use cases: Example tests: - Unit tests for :src:`src/lib_requester`, in :src:`src/lib_requester/test/test_requester.ml`. To execute them locally, run ``dune build @src/lib_requester/runtest`` in - the Tezos root. To execute them on :ref:`your own machine - ` using the GitLab CI system, run - ``gitlab-runner exec docker unit:requester``. + the Tezos root. - Integration tests for the P2P layer in the shell. For instance :src:`src/lib_p2p/test/test_p2p_pool.ml`. This test forks a set of processes that exercise large parts of the P2P layer. To execute it locally, run ``dune build @runtest_p2p_pool`` in the Tezos - root. To execute the P2P tests on :ref:`your own machine - ` using the GitLab CI system, run - ``gitlab-runner exec docker unit:p2p``. The job-name - ``unit:p2p`` is ill-chosen, since the test is in fact an - integration test. + root. References: - `Alcotest README `_. @@ -203,15 +197,11 @@ Example tests: interpreter (in :src:`tests_python/tests_alpha/test_contract_opcodes.py`). To execute it locally, run ``cd tests_python && poetry run pytest tests/test_contract_opcodes.py`` - in the Tezos root. To execute them on :ref:`your own machine - ` using the GitLab CI system, run - ``gitlab-runner exec docker integration:contract_opcodes``. + in the Tezos root. - Setting up networks of nodes and ensuring their connection (in :src:`tests_python/tests_alpha/test_p2p.py`). To execute it locally, run ``cd tests_python && poetry run pytest tests/test_p2p.py`` in - the Tezos root. To execute them on :ref:`your own machine - ` using the GitLab CI system, run - ``gitlab-runner exec docker integration:p2p``. + the Tezos root. References: - `Pytest Documentation `_ @@ -571,8 +561,7 @@ Other For other types of tests, you need to manually modify the :src:`.gitlab-ci.yml`. Please refer to the `GitLab CI Pipeline Reference `_. A helpful tool for - this task is the `CI Lint tool `_, and ``gitlab-runner``, - introduced in the :ref:`next section `. + this task is the `CI Lint tool `_. Test coverage in merge requests ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -633,43 +622,6 @@ contains the HTML coverage report. GitLab also produces a `graph of the coverage ratio over time `_. - - - -.. _executing_gitlab_ci_locally: - -Executing the GitLab CI locally -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -GitLab offers the ability to run jobs defined in the :src:`.gitlab-ci.yml` file on your own machine. -This is helpful to debug the CI pipeline. -For this, you need to setup ``gitlab-runner`` on your machine. -To avoid using outdated versions of the binary, it is recommended to install a -`release from the development repository `_. - -``gitlab-runner`` works with the concept of `executor`. We recommend to use the -``docker`` executor to sandbox the environment the job will be executed in. This -supposes that you have docker installed on your machine. - -For example, if you want to run the job ``check_python_linting`` which checks the Python syntax, you can use: - -.. code-block:: bash - - gitlab-runner exec docker check_python_linting - -Note that the first time you execute a job, it may take a long time because it -requires downloading the docker image, and ``gitlab-runner`` is not verbose on this -subject. For instance, if Tezos' opam repository has changed, requiring -a refresh of the locally cached docker image. - -Local changes must be committed (but not necessarily pushed remotely) -before executing the job locally. Indeed, ``gitlab-runner`` will clone -the head of the current local branch to execute the job. - -Another limitation is that only single jobs can be executed using -``gitlab-runner``. For instance, there is no direct way of executing all -jobs in the stage ``test``. - Conventions ----------- diff --git a/docs/kathmandu/transaction_rollups.rst b/docs/kathmandu/transaction_rollups.rst index d2198cae30875aa366b2b3248b321b04bc7f2838..55ba0f68e34879322846483d0260adeed4bdc441 100644 --- a/docs/kathmandu/transaction_rollups.rst +++ b/docs/kathmandu/transaction_rollups.rst @@ -582,7 +582,7 @@ provides a shell with the rollup node and client available in the Similarly to other Octez binaries like the baker, there exists a rollup node and client for each version of the Tezos protocol. You can use the ``014-PtKathma`` binaries on testnets like - `Kathmandunet _` (``--network + `Kathmandunet `_ (``--network kathmandunet``). Note that, compared to testnets like Mondaynet or Dailynet, Kathmandunet is using the same protocol constants as Mainnet, meaning the finality period is 40,000 blocks (about 2 diff --git a/docs/lima/transaction_rollups.rst b/docs/lima/transaction_rollups.rst index e40488ec8c578ee3d2024c6c9f1d7f84f0b551fa..8a1b4f2142c254a21297a5a5099951908169bc53 100644 --- a/docs/lima/transaction_rollups.rst +++ b/docs/lima/transaction_rollups.rst @@ -588,7 +588,7 @@ provides a shell with the rollup node and client available in the Similarly to other Octez binaries like the baker, there exists a rollup node and client for each version of the Tezos protocol. You can use the ``alpha`` binaries on testnets like `Mondaynet or - Dailynet _`. This is the recommended way to + Dailynet `_. This is the recommended way to experiment with Transaction Rollups, as the finality period on Mondaynet and Dailynet is significantly shorter than on mainnet or other testnets. diff --git a/docs/user/snapshots.rst b/docs/user/snapshots.rst index 95705758e934a9aa6107783d2caf195073856d72..6dac8d6b4c92f5f7cdfc445185a63617c7d87c3f 100644 --- a/docs/user/snapshots.rst +++ b/docs/user/snapshots.rst @@ -168,7 +168,7 @@ represented as *cemented cycles* and will stay as it is for ever. Only the rest of the file contains data relative to the snapshot's target block, such as the current incomplete cycle and the block's associated ledger state. This canonical representation is well suited for -distributing snapshots through `IPFS `_. +distributing snapshots through `IPFS `_. Export capabilities diff --git a/src/proto_alpha/lib_protocol/alpha_context.mli b/src/proto_alpha/lib_protocol/alpha_context.mli index 18a61fc944b259d960bf821694b09bd3861c59a9..f905bf8b2d850714f8a2e01f486fe1ea4c6ef953 100644 --- a/src/proto_alpha/lib_protocol/alpha_context.mli +++ b/src/proto_alpha/lib_protocol/alpha_context.mli @@ -2486,6 +2486,7 @@ module Receipt : sig val group_balance_updates : balance_updates -> balance_updates tzresult end +(** This module re-exports definitions from {!Delegate_consensus_key}. *) module Consensus_key : sig type pk = { delegate : Signature.Public_key_hash.t; @@ -2506,7 +2507,7 @@ module Consensus_key : sig end (** This module re-exports definitions from {!Delegate_storage}, - {!Delegate_missed_endorsements_storage}, + {!Delegate_consensus_key}, {!Delegate_missed_endorsements_storage}, {!Delegate_slashed_deposits_storage}, {!Delegate_cycles}. *) module Delegate : sig val frozen_deposits_limit : diff --git a/src/proto_alpha/lib_protocol/delegate_consensus_key.mli b/src/proto_alpha/lib_protocol/delegate_consensus_key.mli index babfeb0349e1dd0157a86c71fb3dd1c54c0db2ab..edbf190c80390761b9eb5bdd69d94d8e8244c7fa 100644 --- a/src/proto_alpha/lib_protocol/delegate_consensus_key.mli +++ b/src/proto_alpha/lib_protocol/delegate_consensus_key.mli @@ -23,6 +23,12 @@ (* *) (*****************************************************************************) +(** Management of a delegate's consensus key, the one used to sign + blocks and consensus operations. It is responsible for maintaining + the tables {!Storage.Consensus_keys}, + {!Storage.Contract.Consensus_key}, and + {!Storage.Contract.Pending_consensus_keys}. *) + type error += | Invalid_consensus_key_update_noop of Cycle_repr.t | Invalid_consensus_key_update_active diff --git a/src/proto_alpha/lib_protocol/tez_repr.ml b/src/proto_alpha/lib_protocol/tez_repr.ml index c8a8aa98b69973d2736a5ada331359254ab1e4dc..2c16dfa99dbe2d256ca1094fff3241d6eb01c609 100644 --- a/src/proto_alpha/lib_protocol/tez_repr.ml +++ b/src/proto_alpha/lib_protocol/tez_repr.ml @@ -205,7 +205,9 @@ let () = pp opb id) - ~description:("A subtraction of two " ^ id ^ " amounts underflowed") + ~description: + ("A subtraction of two " ^ id + ^ " amounts underflowed (i.e., would have led to a negative amount)") (obj1 (req "amounts" (tup2 encoding encoding))) (function Subtraction_underflow (a, b) -> Some (a, b) | _ -> None) (fun (a, b) -> Subtraction_underflow (a, b)) ;