GNOME.org
 

[Notes] [Git][BuildGrid/buildgrid][mablanch/51-user-facing-docs] 4 commits: Turn existing instruction material into documentation

Title: GitLab

Martin Blanchard pushed to branch mablanch/51-user-facing-docs at BuildGrid / buildgrid

Commits:

16 changed files:

Changes:

  • CONTRIBUTING.rst
    1 
    -Contributing to BuildGrid
    2 
    -=========================
    3 
    -Some guidelines for people wanting to contribute. Also please always feel free to speak to us, we're very friendly :-)
    4 1
    5 
    -Feature Additions
    6 
    ------------------
    2 
    +.. _contributing:
    3 
    +
    4 
    +Contributing
    5 
    +============
    7 6
    8 
    -We welcome contributions in the form of bug fixes or feature additions / enhancements. Please discuss with us before submitting anything, as we may well have some important context which will could help guide your efforts.
    7 
    +Some guidelines for people wanting to contribute. Also please always feel free
    8 
    +to speak to us, we're very friendly :-)
    9 9
    10 
    -Any major feature additions should be raised as a proposal on the `Mailing List <https://lists.buildgrid.build/cgi-bin/mailman/listinfo/buildgrid/>`_ to be discussed, and then eventually followed up with an issue here on gitlab. We recommend that you propose the feature in advance of commencing work. We are also on irc - you can find us on #buildgrid on freenode.
    11 10
    12 
    -The author of any patch is expected to take ownership of that code and is to support it for a reasonable time-frame. This means addressing any unforeseen side effects and quirks the feature may have introduced. More on this below in 'Granting Committer Access'.
    11 
    +.. _feature-additions:
    13 12
    14 
    -Patch Submissions
    13 
    +Feature additions
    15 14 
     -----------------
    16 15
    17 
    -We will be running `trunk based development <https://trunkbaseddevelopment.com>`_. The idea behind this is that merge requests to the trunk will be small and made often, thus making the review and merge process as fast as possible. We do not want to end up with a huge backlog of outstanding merge requests. If possible,
    18 
    -it is preferred that merge requests address specific points and clearly outline what problem they are solving.
    16 
    +We welcome contributions in the form of bug fixes or feature additions. Please
    17 
    +discuss with us before submitting anything, as we may well have some important
    18 
    +context which will could help guide your efforts.
    19 
    +
    20 
    +Any major feature additions should be raised first as a proposal on the
    21 
    +`BuildGrid mailing list`_ to be discussed, and then eventually followed up with
    22 
    +an issue on GitLab. We recommend that you propose the feature in advance of
    23 
    +commencing work.
    24 
    +
    25 
    +The author of any patch is expected to take ownership of that code and is to
    26 
    +support it for a reasonable time-frame. This means addressing any unforeseen
    27 
    +side effects and quirks the feature may have introduced. More on this below in
    28 
    +:ref:`Committer access <committer-access>`.
    19 29
    20 
    -Branches must be submitted as merge requests on gitlab and should be associated with an issue report on gitlab, whenever possible. If it's a small change, we'll accept an MR without it being associated to a gitlab issue, but generally we prefer an issue to be raised in advance. This is so that we can track the work that is currently in progress on the project - please see our Gitlab policy below.
    30 
    +.. _BuildGrid mailing list: https://lists.buildgrid.build/cgi-bin/mailman/listinfo/buildgrid
    31 
    +
    32 
    +
    33 
    +.. _patch-submissions:
    34 
    +
    35 
    +Patch submissions
    36 
    +-----------------
    21 37
    22 
    -Each commit should address a specific gitlab issue number in the commit message. This is really important for provenance reasons.
    38 
    +We are running `trunk based development`_. The idea behind this is that merge
    39 
    +requests to the trunk will be small and made often, thus making the review and
    40 
    +merge process as fast as possible. We do not want to end up with a huge backlog
    41 
    +of outstanding merge requests. If possible, it is preferred that merge requests
    42 
    +address specific points and clearly outline what problem they are solving.
    23 43
    24 
    -Merge requests that are not yet ready for review must be prefixed with the `WIP:` identifier, but if we stick to trunk based development then the 'WIP:' identifier will not stay around for very long on a merge request.
    44 
    +Branches must be submitted as merge requests (MR) on GitLab and should be
    45 
    +associated with an issue, whenever possible. If it's a small change, we'll
    46 
    +accept an MR without it being associated to an issue, but generally we prefer an
    47 
    +issue to be raised in advance. This is so that we can track the work that is
    48 
    +currently in progress on the project.
    25 49
    26 
    -When a merge request is ready for review, please find someone willing to do the review (ideally a maintainer) and assign them the MR on gitlab, leaving a comment asking for their review.
    50 
    +Below is a list of good patch submission good practice:
    27 51
    28 
    -Submitted branches should not contain a history of work done.
    52 
    +- Each commit should address a specific issue number in the commit message. This
    53 
    +  is really important for provenance reasons.
    54 
    +- Merge requests that are not yet ready for review must be prefixed with the
    55 
    +  ``WIP:`` identifier, but if we stick to trunk based development then the
    56 
    +  ``WIP:`` identifier will not stay around for very long on a merge request.
    57 
    +- When a merge request is ready for review, please find someone willing to do
    58 
    +  the review (ideally a maintainer) and assign them the MR, leaving a comment
    59 
    +  asking for their review.
    60 
    +- Submitted branches should not contain a history of work done.
    61 
    +- Unit tests should be a separate commit.
    62 
    +
    63 
    +.. _trunk based development: https://trunkbaseddevelopment.com
    29 64
    30 
    -Unit tests should be a separate commit.
    31 65
    32 66 
     Commit messages
    33 67 
     ~~~~~~~~~~~~~~~
    34 
    -Commit messages must be formatted with a brief summary line, optionally followed by an empty line and then a
    35 
    -free form detailed description of the change.
    36 
    -
    37 
    -The summary line must start with what changed, followed by a colon and a very brief description of the
    38 
    -change.
    39 68
    40 
    -If there is an associated issue, it **must** be mentioned somewhere in the commit message.
    69 
    +Commit messages must be formatted with a brief summary line, optionally followed
    70 
    +by an empty line and then a free form detailed description of the change. The
    71 
    +summary line must start with what changed, followed by a colon and a very brief
    72 
    +description of the change. If there is an associated issue, it **must** be
    73 
    +mentioned somewhere in the commit message.
    41 74
    42 75 
     **Example**::
    43 76
    44 
    -  worker.py: Fixed to be more human than human
    77 
    +   worker.py: Fixed to be more human than human
    78 
    +
    79 
    +   Gifted the worker with a past so we can create
    80 
    +   a cushion or a pillow for their emotions and
    81 
    +   consequently, we can control them better.
    82 
    +
    83 
    +   This fixes issue #8.
    45 84
    46 
    -  Gifted the worker with a past so we can create
    47 
    -  a cushion or a pillow for their emotions and
    48 
    -  consequently, we can control them better.
    49 
    -
    50 
    -  This fixes issue #8
    85 
    +For more tips, please read `The seven rules of a great Git commit message`_.
    51 86
    52 
    -
    53 
    -For more tips, please see `this <https://chris.beams.io/posts/git-commit/#seven-rules/>`_ article.
    87 
    +.. _The seven rules of a great Git commit message: https://chris.beams.io/posts/git-commit/#seven-rules
    88 
    +
    89 
    +
    90 
    +.. _coding-style:
    54 91
    55 92 
     Coding style
    56 93 
     ------------
    57 
    -Coding style details for BuildGrid.
    58 94
    95 
    +Python coding style for BuildGrid is `PEP 8`_. We do have a couple of minor
    96 
    +exceptions to this standard, we dont want to compromise code readability by
    97 
    +being overly restrictive on line length for instance.
    98 
    +
    99 
    +BuildGrid's test suite includes a PEP8 style compliance check phase (using
    100 
    +`pep8`_) and a code linting phase (using `pylint`_). That test suite is
    101 
    +automatically run for every change submitted to the GitLab server and the merge
    102 
    +request sytem requires the test suite execution to succed before changes can
    103 
    +be pulled upstream. This means you have to respect the BuildGrid coding style.
    59 104
    60 
    -Style guide
    61 
    -~~~~~~~~~~~
    62 
    -Python coding style for BuildGrid is pep8, which is documented here: https://www.python.org/dev/peps/pep-0008/
    105 
    +Configuration and exceptions for ``pep8`` and ``pylint`` can be found in:
    63 106
    64 
    -We have a couple of minor exceptions to this standard, we dont want to compromise
    65 
    -code readability by being overly restrictive on line length for instance.
    107 
    +- The `setup.cfg`_ file for ``pep8``.
    108 
    +- The `.pylintrc`_ file for ``pylint``.
    109 
    +
    110 
    +.. _PEP 8: https://www.python.org/dev/peps/pep-0008
    111 
    +.. _pep8: https://pep8.readthedocs.io
    112 
    +.. _pylint: https://pylint.readthedocs.io
    113 
    +.. _setup.cfg: https://gitlab.com/BuildGrid/buildgrid/blob/master/setup.cfg
    114 
    +.. _.pylintrc: https://gitlab.com/BuildGrid/buildgrid/blob/master/.pylintrc
    66 115
    67 116
    68 117 
     Imports
    69 118 
     ~~~~~~~
    119 
    +
    70 120 
     Module imports inside BuildGrid are done with relative ``.`` notation
    71 121
    72 122 
     Good::
    ... ... @@ -77,99 +127,85 @@ Bad::
    77 127
    78 128 
       from buildgrid.worker import Worker
    79 129
    80 
    -Ordering
    81 
    -''''''''
    82 
    -For better readability and consistency, we try to keep private symbols below
    83 
    -public symbols. In the case of public modules where we may have a mix of
    84 
    -*API private* and *local private* symbols, *API private* symbols should come
    85 
    -before *local private* symbols.
    86 
    -
    87 130
    88 131 
     Symbol naming
    89 132 
     '''''''''''''
    90 
    -Any private symbol must start with a single leading underscore for two reasons:
    91 
    -
    92 
    -* So that it does not bleed into documentation and *public API*.
    93 
    -
    94 
    -* So that it is clear to developers which symbols are not used outside of the declaring *scope*
    95 
    -
    96 
    -Remember that with python, the modules (python files) are also symbols
    97 
    -within their containing *package*, as such; modules which are entirely
    98 
    -private to BuildGrid are named as such, e.g. ``_roy.py``.
    99 133
    100 
    -Granting Committer Access
    101 
    --------------------------
    102 
    -
    103 
    -We'll hand out commit access to anyone who has successfully landed a single patch to the code base. Please request this via irc or the mailing list.
    104 
    -
    105 
    -This of course relies on contributors being responsive and show willingness to address problems after landing branches there should not be any problems here.
    106 
    -
    107 
    -What we are expecting of committers here in general is basically to
    108 
    -escalate the review in cases of uncertainty:
    109 
    -
    110 
    -* If the patch/branch is very trivial (obvious few line changes or typos etc), and you are confident of the change, there is no need for review.
    111 
    -
    112 
    -* If the patch/branch is non trivial, please obtain a review from another committer who is familiar with the area which the branch effects. An approval from someone who is not the patch author will be needed before any merge.
    113 
    -
    114 
    -We don't have any detailed policy for "bad actors", but will of course handle things on a case by case basis - commit access should not result in commit wars or be used as a tool to subvert the project when disagreements arise, such incidents (if any) would surely lead to temporary suspension of commit rights.
    134 
    +Any private symbol must start with a single leading underscore for two reasons:
    115 135
    116 
    -BuildGrid policy for use of Gitlab features
    117 
    --------------------------------------------
    136 
    +- So that it does not bleed into documentation and *public API*.
    137 
    +- So that it is clear to developers which symbols are not used outside of the
    138 
    +  declaring *scope*.
    118 139
    119 
    -We intend to make use of some of gitlab's features in order to structure the activity of the BuildGrid project. In doing so we are trying to achieve the following goals:
    140 
    +Remember that with python, the modules (python files) are also symbols within
    141 
    +their containing *package*, as such; modules which are entirely private to
    142 
    +BuildGrid are named as such, e.g. ``_roy.py``.
    120 143
    121 
    -* Full transparency of the current WIP items
    122 
    -* Provide a view of all current and planned activity which is relatively easy for the viewer to digest
    123 
    -* Ensure that we keep it simple and easy to contribute to the project
    124 144
    125 
    -We propose to make use of the following Gitlab features:
    145 
    +.. _committer-access:
    126 146
    127 
    -* Milestones
    128 
    -* Labels
    129 
    -* Boards
    130 
    -* Templates
    147 
    +Committer access
    148 
    +----------------
    131 149
    132 
    -Milestones
    133 
    -~~~~~~~~~~
    134 
    -`Milestones <https://docs.gitlab.com/ee/user/project/milestones/>`_ are based on periods of time and what we want to achieve within those periods of time.
    150 
    +We'll hand out commit access to anyone who has successfully landed a single
    151 
    +patch to the code base. Please request this via irc or the mailing list.
    135 152
    136 
    -We have seen them used in the same way as `Epics <https://docs.gitlab.com/ee/user/group/epics/index.html#doc-nav/>`_ in other projects (since the Epic feature is only available with GitLab Ultimate) and this does not work. Milestones must be time-line based.
    153 
    +This of course relies on contributors being responsive and show willingness to
    154 
    +address problems after landing branches there should not be any problems here.
    137 155
    138 
    -Milestones can overlap, and we can be working towards multiple milestones at any one time. They allow us to group together all sub tasks into an overall aim.
    156 
    +What we are expecting of committers here in general is basically to escalate the
    157 
    +review in cases of uncertainty:
    139 158
    140 
    -Labels
    141 
    -~~~~~~
    142 
    -`Labels <https://docs.gitlab.com/ee/user/project/labels.html/>`_ allow us to filter tickets on gitlab in useful ways. They do complexity and effort as they grow in number and usage, though, so the general approach is to have the minimum possible.
    159 
    +- If the change is very trivial (obvious few line changes, typos…), and you are
    160 
    +  confident of the change, there is no need for review.
    161 
    +- If the change is non trivial, please obtain a review from another committer
    162 
    +  who is familiar with the area which the branch effects. An approval from
    163 
    +  someone who is not the patch author will be needed before any merge.
    143 164
    144 
    -Type Labels
    145 
    -'''''''''''
    146 
    -We have:
    165 
    +.. note::
    147 166
    148 
    -* Bug
    149 
    -* Documentation
    150 
    -* Enhancement
    151 
    -* Tests
    167 
    +   We don't have any detailed policy for "bad actors", but will of course handle
    168 
    +   things on a case by case basis - commit access should not result in commit
    169 
    +   wars or be used as a tool to subvert the project when disagreements arise.
    170 
    +   Such incidents (if any) would surely lead to temporary suspension of commit
    171 
    +   rights.
    152 172
    153 
    -This is useful for filtering different types of issues. We may expand this at some point.
    154 173
    155 
    -Priority Labels
    156 
    -'''''''''''''''
    157 
    -For now, we only have 'High Priority', which indicates an urgent task. We may add more granularity if we get more contributors.
    174 
    +.. _gitlab-features:
    158 175
    159 
    -Status
    160 
    -'''''
    161 
    -We have:
    176 
    +GitLab features
    177 
    +---------------
    162 178
    163 
    -* ToDo
    164 
    -* Doing
    179 
    +We intend to make use of some of GitLab's features in order to structure the
    180 
    +activity of the BuildGrid project. In doing so we are trying to achieve the
    181 
    +following goals:
    165 182
    166 
    -These labels are used when structuring tickets on a Board. GitLab issues start life in the 'Backlog' column by default, and we move them into 'ToDo' when they are coming up in the next few weeks. 'Doing' is only for when an item is currently being worked on. These labels don't have to be manually applied, they are applied by GitLab when moving the issue from column to column when using a Board - see below.
    183 
    +- Full transparency of the current work in progress items.
    184 
    +- Provide a view of all current and planned activity which is relatively easy
    185 
    +  for the viewer to digest.
    186 
    +- Ensure that we keep it simple and easy to contribute to the project.
    167 187
    168 
    -Issue Boards
    169 
    -~~~~~~~~~~~~
    170 
    -`Boards <https://docs.gitlab.com/ee/user/project/issue_board.html#doc-nav/>`_ allow you to visualise and manage issues in a simple way, and we can create different types of board by filtering labels. For now, we are just utilising Boards in order to be able to see all of the currently in flight items at a glance.
    188 
    +We are currenlty using the following GitLab features:
    171 189
    172 
    -Templates
    173 
    -~~~~~~~~~
    174 
    -`Issue templates <https://docs.gitlab.com/ee/user/project/description_templates.html#doc-nav/>`_ help us to receive good quality information in issues.
    190 
    +- `Milestones`_: we have seen them used in the same way as `Epics`_ in other
    191 
    +  projects. BuildGrid milestones must be time-line based, can overlap and we can
    192 
    +  be working towards multiple milestones at any one time. They allow us to group
    193 
    +  together all sub tasks into an overall aim. See our `BuildGrid milestones`_.
    194 
    +- `Labels`_: allow us to filter tickets in useful ways. They do complexity and
    195 
    +  effort as they grow in number and usage, though, so the general approach is
    196 
    +  to have the minimum possible. See our `BuildGrid labels`_.
    197 
    +- `Boards`_: allow us to visualise and manage issues and labels in a simple way.
    198 
    +  For now, we are only utilising one boards. Issues start life in the
    199 
    +  ``Backlog`` column by default, and we move them into ``ToDo`` when they are
    200 
    +  coming up in the next few weeks. ``Doing`` is only for when an item is
    201 
    +  currently being worked on. Moving an issue from column to column automatically
    202 
    +  adjust the tagged labels. See our `BuildGrid boards`_.
    175 203
    204 
    +.. _Milestones: https://docs.gitlab.com/ee/user/project/milestones
    205 
    +.. _Epics: https://docs.gitlab.com/ee/user/group/epics
    206 
    +.. _BuildGrid milestones: https://gitlab.com/BuildGrid/buildgrid/milestones
    207 
    +.. _Labels: https://docs.gitlab.com/ee/user/project/labels.html
    208 
    +.. _BuildGrid labels: https://gitlab.com/BuildGrid/buildgrid/labels
    209 
    +.. _Boards: https://docs.gitlab.com/ee/user/project/issue_board.html
    210 
    +.. _BuildGrid boards: https://gitlab.com/BuildGrid/buildgrid/boards
    211 
    +.. _Templates: https://docs.gitlab.com/ee/user/project/description_templates.html

  • README.rst
    1 
    -BuildGrid
    2 
    -=========
    1 
    +
    2 
    +.. _about:
    3 
    +
    4 
    +About
    5 
    +=====
    3 6
    4 7 
     .. image:: https://gitlab.com/Buildgrid/buildgrid/badges/master/pipeline.svg
    5 8 
        :target: https://gitlab.com/BuildStream/buildstream/commits/master
    ... ... @@ -7,79 +10,38 @@ BuildGrid
    7 10 
     .. image:: https://gitlab.com/BuildGrid/buildgrid/badges/master/coverage.svg?job=coverage
    8 11 
        :target: https://gitlab.com/BuildGrid/buildgrid/commits/master
    9 12
    13 
    +BuildGrid is a Python remote execution service which implements Google's
    14 
    +`Remote Execution API`_ and the `Remote Workers API`_. The project's goal is to
    15 
    +be able to execute build jobs remotely on a grid of computers in order to
    16 
    +massively speed up build times. Workers on the grid should be able to run with
    17 
    +different environments. It is designed to work with but not exclusively
    18 
    +`BuildStream`_.
    10 19
    11 
    -BuildGrid is a python remote execution service which implements the `Remote Execution API <https://github.com/bazelbuild/remote-apis//>`_ and the `Remote Workers API <https://docs.google.com/document/d/1s_AzRRD2mdyktKUj2HWBn99rMg_3tcPvdjx3MPbFidU/edit#heading=h.1u2taqr2h940/>`_.
    12 
    -
    13 
    -The goal is to be able to execute build jobs remotely on a grid of computers to massively speed up build times. Workers on the system will also be able to run with different environments. It is designed to work with but not exclusively with `BuildStream <https://wiki.gnome.org/Projects/BuildStream/>`_.
    14 
    -
    15 
    -Install
    16 
    --------
    17 
    -
    18 
    -To install::
    19 
    -
    20 
    -   git clone https://gitlab.com/BuildGrid/buildgrid.git
    21 
    -   cd buildgrid
    22 
    -   pip3 install --user -e .
    23 
    -
    24 
    -This will install BuildGrid's python dependencies into your user’s homedir in ~/.local
    25 
    -and will run BuildGrid directly from the git checkout. It is recommended you adjust
    26 
    -your path with::
    27 
    -
    28 
    -  export PATH="${PATH}:${HOME}/.local/bin"
    29 
    -
    30 
    -Which you can add to the end of your `~/.bashrc`.
    31 
    -
    32 
    -Instructions for a Dummy Work
    33 
    -----------------------
    34 
    -
    35 
    -In one terminal, start a server::
    36 
    -
    37 
    -  bgd server start
    38 
    -
    39 
    -In another terminal, send a request for work::
    40 
    -
    41 
    -  bgd execute request-dummy
    42 
    -
    43 
    -The stage should show as `QUEUED` as it awaits a bot to pick up the work::
    44 
    -
    45 
    -  bgd execute list
    46 
    -
    47 
    -Create a bot session::
    48 
    -
    49 
    -  bgd bot dummy
    50 
    -
    51 
    -Show the work as completed::
    52 
    -
    53 
    -  bgd execute list
    54 
    -
    55 
    -Instructions for a Simple Build
    56 
    --------------------------------
    57 
    -
    58 
    -This example covers a simple build. The user will upload a directory containing a C file and a command to the CAS. The bot will then fetch the uploaded directory and command which will then be run inside a temporary directory. The result will then be uploaded to the CAS and downloaded by the user. This is an early demo and still lacks a few features such as symlink support and checking to see if files exist in the CAS before executing a command.
    59 
    -
    60 
    -Create a new directory called `test-buildgrid/` and place the following C file in it called `hello.c`::
    61 
    -
    62 
    -  #include <stdio.h>
    63 
    -  int main()
    64 
    -  {
    65 
    -   printf("Hello, World!\n");
    66 
    -   return 0;
    67 
    -  }
    20 
    +.. _Remote Execution API: https://github.com/bazelbuild/remote-apis
    21 
    +.. _Remote Workers API: https://docs.google.com/document/d/1s_AzRRD2mdyktKUj2HWBn99rMg_3tcPvdjx3MPbFidU/edit#heading=h.1u2taqr2h940
    22 
    +.. _BuildStream: https://wiki.gnome.org/Projects/BuildStream
    68 23
    69 
    -Now start a BuildGrid server, passing it a directory it can write a CAS to::
    70 24
    71 
    -  bgd server start --cas disk --cas-cache disk --cas-disk-directory /path/to/empty/directory
    25 
    +.. _getting-started:
    72 26
    73 
    -Start the following bot session::
    27 
    +Getting started
    28 
    +---------------
    74 29
    75 
    -  bgd bot temp-directory
    30 
    +Please refer to the `documentation`_ for `installation`_ and `usage`_
    31 
    +instructions.
    76 32
    77 
    -Upload the directory containing the C file::
    33 
    +.. _documentation: https://buildgrid.gitlab.io/buildgrid
    34 
    +.. _installation: https://buildgrid.gitlab.io/buildgrid/installation.html
    35 
    +.. _usage: https://buildgrid.gitlab.io/buildgrid/using.html
    78 36
    79 
    -  bgd cas upload-dir /path/to/test-buildgrid
    80 37
    81 
    -Now we send an execution request to the bot with the name of the epxected `output-file`, a boolean describing if it is executeable, the path to the directory we uploaded in order to calculate the digest and finally the command to run on the bot::
    38 
    +.. _about-resources:
    82 39
    83 
    -  bgd execute command --output-file hello True /path/to/test-buildgrid -- gcc -Wall hello.c -o hello
    40 
    +Resources
    41 
    +---------
    84 42
    85 
    -The resulting executeable should have returned to a new directory called `testing/`
    43 
    +- Homepage: https://buildgrid.build
    44 
    +- GitLab repository: https://gitlab.com/BuildGrid/buildgrid
    45 
    +- Bug tracking: https://gitlab.com/BuildGrid/buildgrid/issues
    46 
    +- Mailing list: https://lists.buildgrid.build/cgi-bin/mailman/listinfo/buildgrid
    47 
    +- IRC channel: irc://chat.freenode.net/#buildgrid

  • app/commands/cmd_bot.py
    ... ... @@ -36,10 +36,13 @@ from ..bots import buildbox, dummy, temp_directory
    36 36 
     from ..cli import pass_context
    37 37
    38 38
    39 
    -@click.group(short_help="Create a bot client")
    40 
    -@click.option('--parent', default='bgd_test')
    41 
    -@click.option('--port', default='50051')
    42 
    -@click.option('--host', default='localhost')
    39 
    +@click.group(name='bot', short_help="Create and register bot clients.")
    40 
    +@click.option('--parent', type=click.STRING, default='bgd_test', show_default=True,
    41 
    +              help="Targeted farm resource.")
    42 
    +@click.option('--port', type=click.INT, default='50051', show_default=True,
    43 
    +              help="Remote server's port number.")
    44 
    +@click.option('--host', type=click.STRING, default='localhost', show_default=True,
    45 
    +              help="Renote server's hostname.")
    43 46 
     @pass_context
    44 47 
     def cli(context, host, port, parent):
    45 48 
         channel = grpc.insecure_channel('{}:{}'.format(host, port))
    ... ... @@ -58,7 +61,7 @@ def cli(context, host, port, parent):
    58 61 
         context.bot_session = bot_session
    59 62
    60 63
    61 
    -@cli.command('dummy', short_help='Create a dummy bot session which just returns lease')
    64 
    +@cli.command('dummy', short_help="Run a dummy session simply returning leases.")
    62 65 
     @pass_context
    63 66 
     def run_dummy(context):
    64 67 
         """
    ... ... @@ -69,13 +72,13 @@ def run_dummy(context):
    69 72 
             b = bot.Bot(context.bot_session)
    70 73 
             b.session(dummy.work_dummy,
    71 74 
                       context)
    72 
    -
    73 75 
         except KeyboardInterrupt:
    74 76 
             pass
    75 77
    76 78
    77 
    -@cli.command('temp-directory', short_help='Runs commands in temp directory and uploads results')
    78 
    -@click.option('--instance-name', default='testing')
    79 
    +@cli.command('temp-directory', short_help="Runs commands in temp directory and uploads results.")
    80 
    +@click.option('--instance-name', type=click.STRING, default='testing', show_default=True,
    81 
    +              help="Targeted farm instance name.")
    79 82 
     @pass_context
    80 83 
     def run_temp_directory(context, instance_name):
    81 84 
         """ Downloads files and command from CAS and runs
    ... ... @@ -86,19 +89,25 @@ def run_temp_directory(context, instance_name):
    86 89 
             b = bot.Bot(context.bot_session)
    87 90 
             b.session(temp_directory.work_temp_directory,
    88 91 
                       context)
    89 
    -
    90 92 
         except KeyboardInterrupt:
    91 93 
             pass
    92 94
    93 95
    94 
    -@cli.command('buildbox', short_help="Create a bot session with busybox")
    95 
    -@click.option('--fuse-dir', show_default=True, default=str(PurePath(Path.home(), 'fuse')))
    96 
    -@click.option('--local-cas', show_default=True, default=str(PurePath(Path.home(), 'cas')))
    97 
    -@click.option('--client-cert', show_default=True, default=str(PurePath(Path.home(), 'client.crt')))
    98 
    -@click.option('--client-key', show_default=True, default=str(PurePath(Path.home(), 'client.key')))
    99 
    -@click.option('--server-cert', show_default=True, default=str(PurePath(Path.home(), 'server.crt')))
    100 
    -@click.option('--port', show_default=True, default=11001)
    101 
    -@click.option('--remote', show_default=True, default='localhost')
    96 
    +@cli.command('buildbox', short_help="Run commands using the BuildBox tool.")
    97 
    +@click.option('--fuse-dir', type=click.Path(readable=False), default=str(PurePath(Path.home(), 'fuse')),
    98 
    +              help="Main mount-point location.")
    99 
    +@click.option('--local-cas', type=click.Path(readable=False), default=str(PurePath(Path.home(), 'cas')),
    100 
    +              help="Local CAS cache directory.")
    101 
    +@click.option('--client-cert', type=click.Path(readable=False), default=str(PurePath(Path.home(), 'client.crt')),
    102 
    +              help="Public client certificate for TLS (PEM-encoded).")
    103 
    +@click.option('--client-key', type=click.Path(readable=False), default=str(PurePath(Path.home(), 'client.key')),
    104 
    +              help="Private client key for TLS (PEM-encoded).")
    105 
    +@click.option('--server-cert', type=click.Path(readable=False), default=str(PurePath(Path.home(), 'server.crt')),
    106 
    +              help="Public server certificate for TLS (PEM-encoded).")
    107 
    +@click.option('--port', type=click.INT, default=11001, show_default=True,
    108 
    +              help="Remote CAS server port.")
    109 
    +@click.option('--remote', type=click.STRING, default='localhost', show_default=True,
    110 
    +              help="Remote CAS server hostname.")
    102 111 
     @pass_context
    103 112 
     def run_buildbox(context, remote, port, server_cert, client_key, client_cert, local_cas, fuse_dir):
    104 113 
         """
    ... ... @@ -116,7 +125,6 @@ def run_buildbox(context, remote, port, server_cert, client_key, client_cert, lo
    116 125 
         context.fuse_dir = fuse_dir
    117 126
    118 127 
         try:
    119 
    -
    120 128 
             b = bot.Bot(context.bot_session)
    121 129 
             b.session(work=buildbox.work_buildbox,
    122 130 
                       context=context)

  • app/commands/cmd_cas.py
    ... ... @@ -30,9 +30,11 @@ from buildgrid._protos.build.bazel.remote.execution.v2 import remote_execution_p
    30 30 
     from ..cli import pass_context
    31 31
    32 32
    33 
    -@click.group(short_help='Interact with the CAS')
    34 
    -@click.option('--port', default='50051')
    35 
    -@click.option('--host', default='localhost')
    33 
    +@click.group(name='cas', short_help="Interact with the CAS server.")
    34 
    +@click.option('--port', type=click.INT, default='50051', show_default=True,
    35 
    +              help="Remote server's port number.")
    36 
    +@click.option('--host', type=click.STRING, default='localhost', show_default=True,
    37 
    +              help="Remote server's hostname.")
    36 38 
     @pass_context
    37 39 
     def cli(context, host, port):
    38 40 
         context.logger = logging.getLogger(__name__)
    ... ... @@ -42,9 +44,10 @@ def cli(context, host, port):
    42 44 
         context.port = port
    43 45
    44 46
    45 
    -@cli.command('upload-files', short_help='Upload files')
    46 
    -@click.argument('files', nargs=-1, type=click.File('rb'))
    47 
    -@click.option('--instance-name', default='testing')
    47 
    +@cli.command('upload-files', short_help="Upload files to the CAS server.")
    48 
    +@click.option('--instance-name', type=click.STRING, default='testing', show_default=True,
    49 
    +              help="Targeted farm instance name.")
    50 
    +@click.argument('files', nargs=-1, type=click.File('rb'), required=True)
    48 51 
     @pass_context
    49 52 
     def upload_files(context, files, instance_name):
    50 53 
         stub = remote_execution_pb2_grpc.ContentAddressableStorageStub(context.channel)
    ... ... @@ -63,9 +66,10 @@ def upload_files(context, files, instance_name):
    63 66 
         context.logger.info("Response: {}".format(response))
    64 67
    65 68
    66 
    -@cli.command('upload-dir', short_help='Upload files')
    67 
    -@click.argument('directory')
    68 
    -@click.option('--instance-name', default='testing')
    69 
    +@cli.command('upload-dir', short_help="Upload a directory to the CAS server.")
    70 
    +@click.option('--instance-name', type=click.STRING, default='testing', show_default=True,
    71 
    +              help="Targeted farm instance name.")
    72 
    +@click.argument('directory', nargs=1, type=click.Path(), required=True)
    69 73 
     @pass_context
    70 74 
     def upload_dir(context, directory, instance_name):
    71 75 
         context.logger.info("Uploading directory to cas")

  • app/commands/cmd_execute.py
    ... ... @@ -37,9 +37,11 @@ from buildgrid._protos.google.longrunning import operations_pb2, operations_pb2_
    37 37 
     from ..cli import pass_context
    38 38
    39 39
    40 
    -@click.group(short_help='Simple execute client')
    41 
    -@click.option('--port', default='50051')
    42 
    -@click.option('--host', default='localhost')
    40 
    +@click.group(name='execute', short_help="Execute simple operations.")
    41 
    +@click.option('--port', type=click.INT, default='50051', show_default=True,
    42 
    +              help="Remote server's port number.")
    43 
    +@click.option('--host', type=click.STRING, default='localhost', show_default=True,
    44 
    +              help="Remote server's hostname.")
    43 45 
     @pass_context
    44 46 
     def cli(context, host, port):
    45 47 
         context.logger = logging.getLogger(__name__)
    ... ... @@ -49,10 +51,13 @@ def cli(context, host, port):
    49 51 
         context.port = port
    50 52
    51 53
    52 
    -@cli.command('request-dummy', short_help='Send a dummy action')
    53 
    -@click.option('--number', default=1)
    54 
    -@click.option('--instance-name', default='testing')
    55 
    -@click.option('--wait-for-completion', is_flag=True, help='Stream updates until jobs are completed')
    54 
    +@cli.command('request-dummy', short_help="Send a dummy action.")
    55 
    +@click.option('--instance-name', type=click.STRING, default='testing', show_default=True,
    56 
    +              help="Targeted farm instance name.")
    57 
    +@click.option('--number', type=click.INT, default=1, show_default=True,
    58 
    +              help="Number of request to send.")
    59 
    +@click.option('--wait-for-completion', is_flag=True,
    60 
    +              help="Stream updates until jobs are completed.")
    56 61 
     @pass_context
    57 62 
     def request_dummy(context, number, instance_name, wait_for_completion):
    58 63 
         action_digest = remote_execution_pb2.Digest()
    ... ... @@ -76,8 +81,8 @@ def request_dummy(context, number, instance_name, wait_for_completion):
    76 81 
                 context.logger.info(next(response))
    77 82
    78 83
    79 
    -@cli.command('status', short_help='Get the status of an operation')
    80 
    -@click.argument('operation-name')
    84 
    +@cli.command('status', short_help="Get the status of an operation.")
    85 
    +@click.argument('operation-name', nargs=1, type=click.STRING, required=True)
    81 86 
     @pass_context
    82 87 
     def operation_status(context, operation_name):
    83 88 
         context.logger.info("Getting operation status...")
    ... ... @@ -89,7 +94,7 @@ def operation_status(context, operation_name):
    89 94 
         context.logger.info(response)
    90 95
    91 96
    92 
    -@cli.command('list', short_help='List operations')
    97 
    +@cli.command('list', short_help="List operations.")
    93 98 
     @pass_context
    94 99 
     def list_operations(context):
    95 100 
         context.logger.info("Getting list of operations")
    ... ... @@ -107,8 +112,8 @@ def list_operations(context):
    107 112 
             context.logger.info(op)
    108 113
    109 114
    110 
    -@cli.command('wait', short_help='Streams an operation until it is complete')
    111 
    -@click.argument('operation-name')
    115 
    +@cli.command('wait', short_help="Streams an operation until it is complete.")
    116 
    +@click.argument('operation-name', nargs=1, type=click.STRING, required=True)
    112 117 
     @pass_context
    113 118 
     def wait_execution(context, operation_name):
    114 119 
         stub = remote_execution_pb2_grpc.ExecutionStub(context.channel)
    ... ... @@ -120,13 +125,15 @@ def wait_execution(context, operation_name):
    120 125 
             context.logger.info(stream)
    121 126
    122 127
    123 
    -@cli.command('command', short_help='Send a command to be executed')
    124 
    -@click.argument('input-root')
    125 
    -@click.argument('commands', nargs=-1)
    126 
    -@click.option('--output-file', nargs=2, type=(str, bool), multiple=True,
    127 
    -              help='{Expected output file, is_executeable flag}')
    128 
    -@click.option('--output-directory', default='testing', help='Output directory for output files')
    129 
    -@click.option('--instance-name', default='testing')
    128 
    +@cli.command('command', short_help="Send a command to be executed.")
    129 
    +@click.option('--instance-name', type=click.STRING, default='testing', show_default=True,
    130 
    +              help="Targeted farm instance name.")
    131 
    +@click.option('--output-file', nargs=2, type=(click.STRING, click.BOOL), multiple=True,
    132 
    +              help="Tuple of expected output file and is-executeable flag.")
    133 
    +@click.option('--output-directory', default='testing', show_default=True,
    134 
    +              help="Output directory for the output files.")
    135 
    +@click.argument('input-root', nargs=1, type=click.Path(), required=True)
    136 
    +@click.argument('commands', nargs=-1, type=click.STRING, required=True)
    130 137 
     @pass_context
    131 138 
     def command(context, input_root, commands, output_file, output_directory, instance_name):
    132 139 
         stub = remote_execution_pb2_grpc.ExecutionStub(context.channel)

  • app/commands/cmd_server.py
    ... ... @@ -39,34 +39,34 @@ from ..cli import pass_context
    39 39 
     _SIZE_PREFIXES = {'k': 2 ** 10, 'm': 2 ** 20, 'g': 2 ** 30, 't': 2 ** 40}
    40 40
    41 41
    42 
    -@click.group(short_help="Start local server")
    42 
    +@click.group(name='server', short_help="Start a local server instance.")
    43 43 
     @pass_context
    44 44 
     def cli(context):
    45 45 
         context.logger = logging.getLogger(__name__)
    46 46 
         context.logger.info("BuildGrid server booting up")
    47 47
    48 48
    49 
    -@cli.command('start', short_help="Starts server")
    50 
    -@click.option('--port', default='50051')
    51 
    -@click.option('--max-cached-actions', type=int, default=50,
    49 
    +@cli.command('start', short_help="Setup a new server instance.")
    50 
    +@click.option('--port', type=click.INT, default='50051', show_default=True,
    51 
    +              help="The port number to be listened.")
    52 
    +@click.option('--max-cached-actions', type=click.INT, default=50, show_default=True,
    52 53 
                   help="Maximum number of actions to keep in the ActionCache.")
    53 54 
     @click.option('--allow-update-action-result/--forbid-update-action-result',
    54 
    -              'allow_uar', default=True,
    55 
    +              'allow_uar', default=True, show_default=True,
    55 56 
                   help="Whether or not to allow clients to manually edit the action cache.")
    56 
    -@click.option('--cas',
    57 
    -              type=click.Choice(('lru', 's3', 'disk', 'with-cache')),
    58 
    -              help="CAS storage type to use.")
    59 
    -@click.option('--cas-cache',
    60 
    -              type=click.Choice(('lru', 's3', 'disk')),
    57 
    +@click.option('--cas', type=click.Choice(('lru', 's3', 'disk', 'with-cache')),
    58 
    +              help="The CAS storage type to use.")
    59 
    +@click.option('--cas-cache', type=click.Choice(('lru', 's3', 'disk')),
    61 60 
                   help="For --cas=with-cache, the CAS storage to use as the cache.")
    62 
    -@click.option('--cas-fallback',
    63 
    -              type=click.Choice(('lru', 's3', 'disk')),
    61 
    +@click.option('--cas-fallback', type=click.Choice(('lru', 's3', 'disk')),
    64 62 
                   help="For --cas=with-cache, the CAS storage to use as the fallback.")
    65 
    -@click.option('--cas-lru-size', help="For --cas=lru, the LRU cache's memory limit.")
    66 
    -@click.option('--cas-s3-bucket', help="For --cas=s3, the bucket name.")
    67 
    -@click.option('--cas-s3-endpoint', help="For --cas=s3, the endpoint URI.")
    68 
    -@click.option('--cas-disk-directory',
    69 
    -              type=click.Path(file_okay=False, dir_okay=True, writable=True),
    63 
    +@click.option('--cas-lru-size', type=click.STRING,
    64 
    +              help="For --cas=lru, the LRU cache's memory limit.")
    65 
    +@click.option('--cas-s3-bucket', type=click.STRING,
    66 
    +              help="For --cas=s3, the bucket name.")
    67 
    +@click.option('--cas-s3-endpoint', type=click.STRING,
    68 
    +              help="For --cas=s3, the endpoint URI.")
    69 
    +@click.option('--cas-disk-directory', type=click.Path(file_okay=False, dir_okay=True, writable=True),
    70 70 
                   help="For --cas=disk, the folder to store CAS blobs in.")
    71 71 
     @pass_context
    72 72 
     def start(context, port, max_cached_actions, allow_uar, cas, **cas_args):
    ... ... @@ -96,7 +96,7 @@ def start(context, port, max_cached_actions, allow_uar, cas, **cas_args):
    96 96 
             loop.close()
    97 97
    98 98
    99 
    -@cli.command('stop', short_help="Stops server")
    99 
    +@cli.command('stop', short_help="Request a server to teardown.")
    100 100 
     @pass_context
    101 101 
     def stop(context):
    102 102 
         context.logger.error("Not implemented yet")

  • docs/source/about.rst
    1 
    +.. include:: ../../README.rst
    \ No newline at end of file

  • docs/source/contributing.rst
    1 
    +.. include:: ../../CONTRIBUTING.rst
    \ No newline at end of file

  • docs/source/index.rst
    ... ... @@ -3,19 +3,28 @@
    3 3 
        You can adapt this file completely to your liking, but it should at least
    4 4 
        contain the root `toctree` directive.
    5 5
    6 
    +
    6 7 
     BuildGrid's documentation
    7 8 
     =========================
    8 9
    10 
    +Remote execution service implementing Google's REAPI and RWAPI.
    11 
    +
    9 12 
     .. toctree::
    10 13 
        :maxdepth: 1
    11 14 
        :caption: Contents:
    12 15
    16 
    +   about
    17 
    +   installation
    18 
    +   using
    19 
    +   reference
    20 
    +   contributing
    21 
    +
    13 22
    14 23 
     Resources
    15 24 
     ---------
    16 25
    17 
    -* Homepage: https://buildgrid.build
    18 
    -* GitLab repository: https://gitlab.com/BuildGrid/buildgrid
    19 
    -* Bug Tracking: https://gitlab.com/BuildGrid/buildgrid/issues
    20 
    -* Mailing list: https://lists.buildgrid.build/cgi-bin/mailman/listinfo/buildgrid
    21 
    -* IRC Channel: irc://chat.freenode.net/#buildgrid
    26 
    +- Homepage: https://buildgrid.build
    27 
    +- GitLab repository: https://gitlab.com/BuildGrid/buildgrid
    28 
    +- Bug tracking: https://gitlab.com/BuildGrid/buildgrid/issues
    29 
    +- Mailing list: https://lists.buildgrid.build/cgi-bin/mailman/listinfo/buildgrid
    30 
    +- IRC channel: irc://chat.freenode.net/#buildgrid

  • docs/source/installation.rst
    1 
    +
    2 
    +.. _installation:
    3 
    +
    4 
    +Installation
    5 
    +============
    6 
    +
    7 
    +How to install BuildGrid onto your machine.
    8 
    +
    9 
    +.. note::
    10 
    +
    11 
    +   BuildGrid server currently only support *Linux*, *macOS* and *Windows*
    12 
    +   platforms are **not** supported.
    13 
    +
    14 
    +
    15 
    +.. _install-prerequisites:
    16 
    +
    17 
    +Prerequisites
    18 
    +-------------
    19 
    +
    20 
    +BuildGrid only supports ``python3 >= 3.5`` but has no system requirements. Main
    21 
    +Python dependencies, automatically handle during installation, includes:
    22 
    +
    23 
    +- `boto3`_: the Amazon Web Services (AWS) SDK for Python.
    24 
    +- `click`_: a Python composable command line library.
    25 
    +- `grpcio`_: Google's `gRPC`_ Python interface.
    26 
    +- `protobuf`_: Google's `protocol-buffers`_ Python interface.
    27 
    +
    28 
    +.. _boto3: https://pypi.org/project/boto3
    29 
    +.. _click: https://pypi.org/project/click
    30 
    +.. _grpcio: https://pypi.org/project/grpcio
    31 
    +.. _gRPC: https://grpc.io
    32 
    +.. _protobuf: https://pypi.org/project/protobuf
    33 
    +.. _protocol-buffers: https://developers.google.com/protocol-buffers
    34 
    +
    35 
    +
    36 
    +.. _source-install:
    37 
    +
    38 
    +Install from sources
    39 
    +--------------------
    40 
    +
    41 
    +BuildGrid has ``setuptools`` support. In order to install it to your home
    42 
    +directory, typically under ``~/.local``, simply run:
    43 
    +
    44 
    +.. code-block:: sh
    45 
    +
    46 
    +   git clone https://gitlab.com/BuildGrid/buildgrid.git && cd buildgrid
    47 
    +   pip3 install --user --editable .
    48 
    +
    49 
    +Additionally, and if your distribution does not already includes it, you may
    50 
    +have to adjust your ``PATH``, in ``~/.bashrc``, with:
    51 
    +
    52 
    +.. code-block:: sh
    53 
    +
    54 
    +   export PATH="${PATH}:${HOME}/.local/bin"
    55 
    +
    56 
    +.. note::
    57 
    +
    58 
    +   The ``setup.py`` script defines two extra targets, ``docs`` and ``tests``,
    59 
    +   that declare required dependency for, respectively, generating documentation
    60 
    +   and running unit-tests. They can be use as helpers for setting up a
    61 
    +   development environment. To use them simply run:
    62 
    +
    63 
    +   .. code-block:: sh
    64 
    +
    65 
    +      pip3 install --user --editable ".[docs,tests]"

  • docs/source/reference.rst
    1 
    +
    2 
    +.. _reference:
    3 
    +
    4 
    +Reference
    5 
    +=========
    6 
    +
    7 
    +This section contains BuildGrid API and CLI reference documentation.
    8 
    +
    9 
    +.. toctree::
    10 
    +   :maxdepth: 2
    11 
    +
    12 
    +   reference_api
    13 
    +   reference_cli

  • docs/source/reference_api.rst
    1 
    +
    2 
    +.. _api_reference:
    3 
    +
    4 
    +API reference
    5 
    +=============
    6 
    +
    7 
    +BuildGrid's Application Programming Interface (API) reference documentation.

  • docs/source/reference_cli.rst
    1 
    +
    2 
    +.. _cli_reference:
    3 
    +
    4 
    +CLI reference
    5 
    +=============
    6 
    +
    7 
    +BuildGrid's Command Line Interface (CLI) reference documentation.
    8 
    +
    9 
    +----
    10 
    +
    11 
    +.. _invoking_bgd:
    12 
    +
    13 
    +.. click:: app:cli
    14 
    +   :prog: bgd
    15 
    +
    16 
    +----
    17 
    +
    18 
    +.. _invoking_bgd_bot:
    19 
    +
    20 
    +.. click:: app.commands.cmd_bot:cli
    21 
    +   :prog: bgd bot
    22 
    +
    23 
    +----
    24 
    +
    25 
    +.. _invoking_bgd_bot_buildbox:
    26 
    +
    27 
    +.. click:: app.commands.cmd_bot:run_buildbox
    28 
    +   :prog: bgd bot buildbot
    29 
    +
    30 
    +----
    31 
    +
    32 
    +.. _invoking_bgd_bot_dummy:
    33 
    +
    34 
    +.. click:: app.commands.cmd_bot:run_dummy
    35 
    +   :prog: bgd bot dummy
    36 
    +
    37 
    +----
    38 
    +
    39 
    +.. _invoking_bgd_bot_temp_directory:
    40 
    +
    41 
    +.. click:: app.commands.cmd_bot:run_temp_directory
    42 
    +   :prog: bgd bot temp-directory
    43 
    +
    44 
    +----
    45 
    +
    46 
    +.. _invoking_bgd_cas:
    47 
    +
    48 
    +.. click:: app.commands.cmd_cas:cli
    49 
    +   :prog: bgd cas
    50 
    +
    51 
    +----
    52 
    +
    53 
    +.. _invoking_bgd_cas_upload_dir:
    54 
    +
    55 
    +.. click:: app.commands.cmd_cas:upload_dir
    56 
    +   :prog: bgd cas upload-dir
    57 
    +
    58 
    +----
    59 
    +
    60 
    +.. _invoking_bgd_cas_upload_files:
    61 
    +
    62 
    +.. click:: app.commands.cmd_cas:upload_files
    63 
    +   :prog: bgd cas upload-files
    64 
    +
    65 
    +----
    66 
    +
    67 
    +.. _invoking_bgd_execute:
    68 
    +
    69 
    +.. click:: app.commands.cmd_execute:cli
    70 
    +   :prog: bgd execute
    71 
    +
    72 
    +----
    73 
    +
    74 
    +.. _invoking_bgd_execute_command:
    75 
    +
    76 
    +.. click:: app.commands.cmd_execute:command
    77 
    +   :prog: bgd execute command
    78 
    +
    79 
    +----
    80 
    +
    81 
    +.. _invoking_bgd_execute_list:
    82 
    +
    83 
    +.. click:: app.commands.cmd_execute:list_operations
    84 
    +   :prog: bgd execute list
    85 
    +
    86 
    +----
    87 
    +
    88 
    +.. _invoking_bgd_execute_ request_dummy:
    89 
    +
    90 
    +.. click:: app.commands.cmd_execute:request_dummy
    91 
    +   :prog: bgd execute request-dummy
    92 
    +
    93 
    +----
    94 
    +
    95 
    +.. _invoking_bgd_execute_status:
    96 
    +
    97 
    +.. click:: app.commands.cmd_execute:operation_status
    98 
    +   :prog: bgd execute status
    99 
    +
    100 
    +----
    101 
    +
    102 
    +.. _invoking_bgd_execute_wait:
    103 
    +
    104 
    +.. click:: app.commands.cmd_execute:wait_execution
    105 
    +   :prog: bgd execute wait
    106 
    +
    107 
    +----
    108 
    +
    109 
    +.. _invoking_bgd_server:
    110 
    +
    111 
    +.. click:: app.commands.cmd_server:cli
    112 
    +   :prog: bgd server
    113 
    +
    114 
    +----
    115 
    +
    116 
    +.. _invoking_bgd_server_start:
    117 
    +
    118 
    +.. click:: app.commands.cmd_server:start
    119 
    +   :prog: bgd server start
    120 
    +
    121 
    +----
    122 
    +
    123 
    +.. _invoking_bgd_server_stop:
    124 
    +
    125 
    +.. click:: app.commands.cmd_server:stop
    126 
    +   :prog: bgd server stop

  • docs/source/using.rst
    1 
    +
    2 
    +.. _using:
    3 
    +
    4 
    +Using
    5 
    +=====
    6 
    +
    7 
    +This section covers how to run an use the BuildGrid build service.
    8 
    +
    9 
    +.. toctree::
    10 
    +   :maxdepth: 2
    11 
    +
    12 
    +   using_dummy_build
    13 
    +   using_simple_build

  • docs/source/using_dummy_build.rst
    1 
    +
    2 
    +.. _dummy-build:
    3 
    +
    4 
    +Dummy build
    5 
    +===========
    6 
    +
    7 
    +In one terminal, start a server:
    8 
    +
    9 
    +.. code-block:: sh
    10 
    +
    11 
    +   bgd server start
    12 
    +
    13 
    +In another terminal, send a request for work:
    14 
    +
    15 
    +.. code-block:: sh
    16 
    +
    17 
    +   bgd execute request-dummy
    18 
    +
    19 
    +The stage should show as ``QUEUED`` as it awaits a bot to pick up the work:
    20 
    +
    21 
    +.. code-block:: sh
    22 
    +
    23 
    +   bgd execute list
    24 
    +
    25 
    +Create a bot session:
    26 
    +
    27 
    +.. code-block:: sh
    28 
    +
    29 
    +   bgd bot dummy
    30 
    +
    31 
    +Show the work as completed:
    32 
    +
    33 
    +.. code-block:: sh
    34 
    +
    35 
    +   bgd execute list

  • docs/source/using_simple_build.rst
    1 
    +
    2 
    +.. _simple-build:
    3 
    +
    4 
    +Simple build
    5 
    +============
    6 
    +
    7 
    +This example covers a simple build. The user will upload a directory containing
    8 
    +a C file and a command to the CAS. The bot will then fetch the uploaded
    9 
    +directory and command which will then be run inside a temporary directory. The
    10 
    +result will then be uploaded to the CAS and downloaded by the user. This is an
    11 
    +early demo and still lacks a few features such as symlink support and checking
    12 
    +to see if files exist in the CAS before executing a command.
    13 
    +
    14 
    +Create a new directory called `test-buildgrid/` and place the following C file
    15 
    +in it called `hello.c`:
    16 
    +
    17 
    +.. code-block:: C
    18 
    +
    19 
    +   #include <stdio.h>
    20 
    +   int main()
    21 
    +   {
    22 
    +     printf("Hello, World!\n");
    23 
    +     return 0;
    24 
    +   }
    25 
    +
    26 
    +Now start a BuildGrid server, passing it a directory it can write a CAS to:
    27 
    +
    28 
    +.. code-block:: sh
    29 
    +
    30 
    +   bgd server start --cas disk --cas-cache disk --cas-disk-directory /path/to/empty/directory
    31 
    +
    32 
    +Start the following bot session:
    33 
    +
    34 
    +.. code-block:: sh
    35 
    +
    36 
    +   bgd bot temp-directory
    37 
    +
    38 
    +Upload the directory containing the C file:
    39 
    +
    40 
    +.. code-block:: sh
    41 
    +
    42 
    +   bgd cas upload-dir /path/to/test-buildgrid
    43 
    +
    44 
    +Now we send an execution request to the bot with the name of the epxected
    45 
    +``output-file``, a boolean describing if it is executeable, the path to the
    46 
    +directory we uploaded in order to calculate the digest and finally the command
    47 
    +to run on the bot:
    48 
    +
    49 
    +.. code-block:: sh
    50 
    +
    51 
    +   bgd execute command --output-file hello True /path/to/test-buildgrid -- gcc -Wall hello.c -o hello
    52 
    +
    53 
    +The resulting executeable should have returned to a new directory called
    54 
    +``testing``.

    • —
    View it on GitLab.
    You're receiving this email because of your account on gitlab.com. If you'd like to receive fewer emails, you can adjust your notification settings.

    [Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]