tinuous


Nametinuous JSON
Version 0.6.1 PyPI version JSON
download
home_pagehttps://github.com/con/tinuous
SummaryDownload build logs from GitHub Actions, Travis, and Appveyor
upload_time2023-02-09 22:47:03
maintainerJohn T. Wodder II
docs_urlNone
authorCenter for Open Neuroscience
requires_python~=3.8
licenseMIT
keywords appveyor github actions travis ci continuous integration
VCS
bugtrack_url
requirements No requirements were recorded.
Travis-CI
coveralls test coverage No coveralls.
            .. image:: https://github.com/con/tinuous/workflows/Test/badge.svg?branch=master
    :target: https://github.com/con/tinuous/actions?workflow=Test
    :alt: GitHub Actions Status

.. image:: https://travis-ci.com/con/tinuous.svg?branch=master
    :target: https://travis-ci.com/con/tinuous
    :alt: Travis CI Status

.. image:: https://ci.appveyor.com/api/projects/status/github/con/tinuous?branch=master&svg=true
    :target: https://ci.appveyor.com/project/yarikoptic/tinuous/branch/master
    :alt: Appveyor Status

.. image:: https://img.shields.io/pypi/pyversions/tinuous.svg
    :target: https://pypi.org/project/tinuous/

.. image:: https://img.shields.io/conda/vn/conda-forge/tinuous.svg
    :target: https://anaconda.org/conda-forge/tinuous
    :alt: Conda Version

.. image:: https://img.shields.io/github/license/con/tinuous.svg
    :target: https://opensource.org/licenses/MIT
    :alt: MIT License

`GitHub <https://github.com/con/tinuous>`_
| `PyPI <https://pypi.org/project/tinuous/>`_
| `Anaconda <https://anaconda.org/conda-forge/tinuous>`_
| `Issues <https://github.com/con/tinuous/issues>`_
| `Changelog <https://github.com/con/tinuous/blob/master/CHANGELOG.md>`_

``tinuous`` is a command for downloading build logs and (for GitHub
only) artifacts & release assets for a GitHub repository from GitHub Actions,
Travis-CI.com, and/or Appveyor.

See <https://github.com/con/tinuous-inception> for an example setup that uses
``tinuous`` with GitHub Actions to fetch the CI logs for ``tinuous`` itself.

Installation
============
``tinuous`` requires Python 3.8 or higher.  Just use `pip
<https://pip.pypa.io>`_ for Python 3 (You have pip, right?) to install
``tinuous`` and its dependencies::

    python3 -m pip install tinuous

``tinuous`` can also optionally integrate with DataLad_.  To install DataLad
alongside ``tinuous``, specify the ``datalad`` extra::

    python3 -m pip install "tinuous[datalad]"

``tinuous`` is also available for conda!  To install, run::

    conda install -c conda-forge tinuous


Usage
=====

::

    tinuous [<global options>] <command> [<args> ...]


Global Options
--------------

-c FILE, --config FILE          Read configuration from the given file [default
                                value: ``tinuous.yaml``]

-E FILE, --env FILE             Load environment variables from the given
                                ``.env`` file.  By default, environment
                                variables are loaded from the first file named
                                "``.env``" found by searching from the current
                                directory upwards.

                                **Warning**: Care must be taken when this file
                                is located in a Git repository so as not to
                                publicly expose it: either list the file in
                                ``.gitignore`` or, if using DataLad or
                                git-annex, configure git-annex to prohibit
                                public sharing of the file.

-l LEVEL, --log-level LEVEL     Set the log level to the given value.  Possible
                                values are "``CRITICAL``", "``ERROR``",
                                "``WARNING``", "``INFO``", "``DEBUG``" (all
                                case-insensitive) and their Python integer
                                equivalents.  [default value: INFO]


``fetch`` Command
-----------------

::

    tinuous [<global options>] fetch [<options>]

``tinuous fetch`` reads a configuration file telling it what repository to
retrieve logs & artifacts for, where to retrieve them from, and where to save
them, and then it carries those steps out.

Options
~~~~~~~

--sanitize-secrets              Sanitize secrets from log files after
                                downloading

-S FILE, --state FILE           Store program state (e.g., timestamps before
                                which all asset are known to have been fetched)
                                in the given file [default value:
                                ``.tinuous.state.json``]

``sanitize`` Command
--------------------

::

    tinuous [<global options>] sanitize <path> ...

Sanitize the given files, replacing all strings matching a secret regex with a
series of asterisks.


Configuration
-------------

The configuration file is a YAML file containing a mapping with the following
keys:

``repo``
    *(required)* The GitHub repository to retrieve assets for, in the form ``OWNER/NAME``

``vars``
    A mapping defining custom path template placeholders.  Each key is the name
    of a custom placeholder, without enclosing braces, and the value is the
    string to substitute in its place.  Custom values may contain standard path
    template placeholders as well as other custom placeholders.

``ci``
    *(required)* A mapping from the names of the CI systems from which to
    retrieve assets to sub-mappings containing CI-specific configuration.
    Including a given CI system is optional; assets will only be fetched from a
    given system if it is listed in this mapping.

    The CI systems and their sub-mappings are as follows:

    ``github``
        Configuration for retrieving assets from GitHub Actions.  Subfields:

        ``paths``
            A mapping giving `template strings <Path Templates_>`_ for the
            paths at which to save various types of assets.  If this is empty
            or not present, no assets are retrieved.  Subfields:

            ``logs``
                A template string that will be instantiated for each workflow
                run to produce the path for the directory (relative to the
                current working directory) under which the run's build logs
                will be saved.  If this is not specified, no logs will be
                downloaded.

            ``artifacts``
                A template string that will be instantiated for each workflow
                run to produce the path for the directory (relative to the
                current working directory) under which the run's artifacts will
                be saved.  If this is not specified, no artifacts will be
                downloaded.

            ``releases``
                A template string that will be instantiated for each
                (non-draft, non-prerelease) GitHub release to produce the path
                for the directory (relative to the current working directory)
                under which the release's assets will be saved.  If this is not
                specified, no release assets will be downloaded.

        ``workflows``
            A specification of the workflows for which to retrieve assets.
            This can be either a list of workflow basenames, including the file
            extension (e.g., ``test.yml``, not ``.github/workflows/test.yml``)
            or a mapping containing the following fields:

            ``include``
                A list of workflows to retrieve assets for, given as either
                basenames or (when ``regex`` is true) `Python regular
                expressions`_ to match against basenames.  If ``include`` is
                omitted, it defaults to including all workflows.

            ``exclude``
                A list of workflows to not retrieve assets for, given as either
                basenames or (when ``regex`` is true) `Python regular
                expressions`_ to match against basenames.  If ``exclude`` is
                omitted, no workflows are excluded.  Workflows that match both
                ``include`` and ``exclude`` are excluded.

            ``regex``
                A boolean.  If true (default false), the elements of the
                ``include`` and ``exclude`` fields are treated as `Python
                regular expressions`_ that are matched (unanchored) against
                workflow basenames; if false, they are used as exact names

            When ``workflows`` is not specified, assets are retrieved for all
            workflows in the repository.

    ``travis``
        Configuration for retrieving logs from Travis-CI.com.  Subfield:

        ``paths``
            A mapping giving `template strings <Path Templates_>`_ for the
            paths at which to save various types of assets.  If this is empty
            or not present, no assets are retrieved.  Subfield:

            ``logs``
                A template string that will be instantiated for each job of
                each build to produce the path for the file (relative to the
                current working directory) in which the job's logs will be
                saved.  If this is not specified, no logs will be downloaded.

    ``appveyor``
        Configuration for retrieving logs from Appveyor.  Subfields:

        ``paths``
            A mapping giving `template strings <Path Templates_>`_ for the
            paths at which to save various types of assets.  If this is empty
            or not present, no assets are retrieved.  Subfield:

            ``logs``
                A template string that will be instantiated for each job of
                each build to produce the path for the file (relative to the
                current working directory) in which the job's logs will be
                saved.  If this is not specified, no logs will be downloaded.

        ``accountName``
            *(required)* The name of the Appveyor account to which the
            repository belongs on Appveyor

        ``projectSlug``
            The project slug for the repository on Appveyor; if not specified,
            it is assumed that the slug is the same as the repository name

``since``
    A timestamp (date, time, & timezone); only assets for builds started after
    the given point in time will be retrieved.  If not specified, the cutoff
    set by ``max-days-back`` will be used.

    As the script retrieves new build assets, it keeps track of their starting
    points.  Once the assets for all builds for the given CI system &
    configuration have been fetched up to a certain point, the timestamp for
    the latest such build is stored in the state file and used as the new
    ``since`` value for the respective CI system on subsequent runs.  If the
    ``since`` setting in the configuration file is then updated to a newer
    timestamp, the configuration will override the value in the state file, and
    the next ``tinuous`` run will only retrieve assets after the new setting.

``max-days-back``
    An integer specifying the maximum number of days back to look for builds;
    defaults to 30.

    If ``since`` is earlier than the date indicated by this value, and if the
    timestamp for a given CI system saved in the state file is either missing
    (i.e., if this is the first run of ``tinuous`` against the CI system) or
    older than ``since``, then ``tinuous`` will use the explicitly-specified
    ``since`` value as the cutoff and ignore ``max-days-back``.

``until``
    A timestamp (date, time, & timezone); only assets for builds started before
    the given point in time will be retrieved

``types``
    A list of build trigger event types; only assets for builds triggered by
    one of the given events will be retrieved.  If this is not specified,
    assets will be retrieved for all recognized event types.

    The recognized event types are:

    ``cron``
        A build run on a schedule

    ``manual``
        A build triggered manually by a human or through the CI system's API

    ``pr``
        A build in response to activity on a pull request

    ``push``
        A build in response to new commits

``secrets``
    A mapping from names (used in log messages) to `Python regular
    expressions`_ matching secrets to sanitize

``allow-secrets-regex``
    Any strings that match a ``secrets`` regex and also match this regex will
    not be sanitized.  Note that ``allow-secrets-regex`` is tested against just
    the substring that matched a ``secrets`` regex without any surrounding
    text, and so lookahead and lookbehind will not work in this regex.

``datalad``
    A sub-mapping describing integration of ``tinuous`` with DataLad_.
    Subfields:

    ``enabled``
        A boolean.  If true (default false), DataLad must be installed, the
        current directory will be converted into a DataLad dataset if it is not
        one already, the assets will optionally be divided up into subdatasets,
        and all new assets will be committed at the end of a run of ``tinuous
        fetch``.  ``path`` template strings may contain ``//`` separators
        indicating the boundaries of subdatasets.

    ``cfg_proc``
        Procedure to run on the dataset & subdatasets when creating them

    .. _DataLad: https://www.datalad.org

.. _Python regular expressions: https://docs.python.org/3/library/re.html
                                #regular-expression-syntax

A sample config file:

.. code:: yaml

    repo: datalad/datalad
    vars:
      path_prefix: '{year}//{month}//{day}/{ci}/{type}'
      build_prefix: '{path_prefix}/{type_id}/{build_commit[:7]}'
    ci:
      github:
        paths:
          logs: '{build_prefix}/{wf_name}/{number}/logs/'
          artifacts: '{build_prefix}/{wf_name}/{number}/artifacts/'
          releases: '{path_prefix}/{release_tag}/'
        workflows:
          - test_crippled.yml
          - test_extensions.yml
          - test_macos.yml
      travis:
        paths:
          logs: '{build_prefix}/{number}/{job}.txt'
      appveyor:
        paths:
          logs: '{build_prefix}/{number}/{job}.txt'
        accountName: mih
        projectSlug: datalad
    since: 2021-01-20T00:00:00Z
    max-days-back: 14
    types: [cron, manual, pr, push]
    secrets:
      github: '\bgh[a-z]_[A-Za-z0-9]{36,}\b'
      docker-hub: '\b[a-f0-9]{8}(?:-[a-f0-9]{4}){3}-[a-f0-9]{12}\b'
      appveyor: '\b(v2\.)?[a-z0-9]{20}\b'
      travis: '\b[a-zA-Z0-9]{22}\b'
      aws: '\b[a-zA-Z0-9+/]{40}\b'
    datalad:
      enabled: true
      cfg_proc: text2git


Path Templates
--------------

The path at which assets for a given workflow run, build job, or release are
saved is determined by instantiating the appropriate path template string given
in the configuration file for the corresponding CI system.  A template string
is a filepath containing placeholders of the form ``{field}``, where the
available placeholders are:

======================  =======================================================
Placeholder             Definition
======================  =======================================================
``{year}``              The four-digit year in which the build was started or
                        the release was published
``{month}``             The two-digit month in which the build was started or
                        the release was published
``{day}``               The two-digit day in which the build was started or the
                        release was published
``{hour}``              The two-digit hour at which the build was started or
                        the release was published
``{minute}``            The two-digit minute at which the build was started or
                        the release was published
``{second}``            The two-digit second at which the build was started or
                        the release was published
``{timestamp}``         The date & time at which the build was started or the
                        release was published.  This is a Python datetime_
                        value; it can be formatted with a `strftime()`_ format
                        string by writing ``{timestamp:FORMAT}``, e.g.,
                        ``{timestamp:%Y-%b-%d}`` will produce a string of the
                        form "2021-Jun-14".  If written as just
                        ``{timestamp}``, the date & time will be formatted in
                        ISO 8601 format.
``{timestamp_local}``   The date & time at which the build was started or the
                        release was published, in the local system timezone.
                        This is formatted in the same way as ``{timestamp}``.
``{ci}``                The name of the CI system (``github``, ``travis``, or
                        ``appveyor``)
``{type}``              The event type that triggered the build (``cron``,
                        ``manual``, ``pr``, or ``push``), or ``release`` for
                        GitHub releases
``{type_id}``           Further information on the triggering event; for
                        ``cron`` and ``manual``, this is a timestamp for the
                        start of the build; for ``pr``, this is the number of
                        the associated pull request, or ``UNK`` if it cannot be
                        determined; for ``push``, this is the escaped [1]_ name
                        of the branch to which the push was made (or possibly
                        the tag that was pushed, if using Appveyor) [2]_
``{release_tag}``       *(``releases_path`` only)* The release tag
``{build_commit}``      The hash of the commit the build ran against or that
                        was tagged for the release.  Note that, for PR builds
                        on Travis and Appveyor, this is the hash of an
                        autogenerated merge commit.
``{commit}``            The hash of the original commit that triggered the
                        build or that was tagged for the release.  For pull
                        request builds, this is the head of the PR branch, or
                        ``UNK`` if it cannot be determined.  For other builds
                        (along with PR builds on GitHub Actions), this is
                        always the same as ``{build_commit}``.
``{number}``            The run number of the workflow run (GitHub) or the
                        build number (Travis and Appveyor) [2]_
``{status}``            The success status of the workflow run (GitHub) or job
                        (Travis and Appveyor); the exact strings used depend on
                        the CI system [2]_
``{common_status}``     The success status of the workflow run or job,
                        normalized into one of ``success``, ``failed``,
                        ``errored``, or ``incomplete`` [2]_
``{wf_name}``           *(GitHub only)* The escaped [1]_ name of the workflow
                        [2]_
``{wf_file}``           *(GitHub only)* The basename of the workflow file
                        (including the file extension) [2]_
``{run_id}``            *(GitHub only)* The unique ID of the workflow run [2]_
``{job}``               *(Travis and Appveyor only)* The number of the job,
                        without the build number prefix (Travis) or the job ID
                        string (Appveyor) [2]_
``{job_index}``         *(Travis and Appveyor only)* The index of the job in
                        the list returned by the API, starting from 1 [2]_
``{job_env}``           *(Appveyor only)* The escaped [1]_ environment
                        variables specific to the job [2]_
``{job_env_hash}``      *(Appveyor only)* The SHA1 hash of ``{job_env}`` before
                        escaping [2]_
======================  =======================================================

.. _datetime: https://docs.python.org/3/library/datetime.html#datetime-objects
.. _strftime(): https://docs.python.org/3/library/datetime.html
                #strftime-and-strptime-format-codes

.. [1] Escaping consists of percent-encoding the characters ``\/<>:|"?*%`` and
       replacing each whitespace character with a space.

.. [2] These placeholders are only available for ``path`` and
       ``artifacts_path``, not ``releases_path``

A placeholder's value may be truncated to the first ``n`` characters by writing
``{placeholder[:n]}``, e.g., ``{commit[:7]}``.

All timestamps and timestamp components (other than ``{timestamp_local}``) are
in UTC.

Path templates may also contain custom placeholders defined in the top-level
``vars`` mapping of the configuration.

Authentication
--------------

Note that environment variables can be loaded from a ``.env`` file as an
alternative to setting them directly in the environment.

GitHub
~~~~~~

In order to retrieve assets from GitHub, a GitHub OAuth token must be specified
either via the ``GITHUB_TOKEN`` environment variable or as the value of the
``hub.oauthtoken`` Git config option.

Travis
~~~~~~

In order to retrieve logs from Travis, a Travis API access token must be either
specified via the ``TRAVIS_TOKEN`` environment variable or be retrievable by
running ``travis token --com --no-interactive``.

A Travis API access token can be acquired as follows:

- Install the `Travis command line client
  <https://github.com/travis-ci/travis.rb>`_.

- Run ``travis login --com`` to authenticate.

  - If your Travis account is linked to your GitHub account, you can
    authenticate by running ``travis login --com --github-token
    $GITHUB_TOKEN``.

- If the script will be run on the same machine that the above steps are
  carried out on, you can stop here, and the script will retrieve the token
  directly from the ``travis`` command.

- Run ``travis token --com`` to retrieve the API access token.

The Travis integration also requires a GitHub OAuth token in order to look up
information on pull requests that the Travis API does not report; this token
must be specified in the same way as for the GitHub integration.

Appveyor
~~~~~~~~

In order to retrieve logs from Appveyor, an Appveyor API key (for either all
accessible accounts or just the specific account associated with the
repository) must be specified via the ``APPVEYOR_TOKEN`` environment variable.
Such a key can be obtained at <https://ci.appveyor.com/api-keys>.


Cron Integration
================

If you want to set up scheduled runs of ``tinuous`` on a Linux server, one way
is as follows:

1. Create a new directory and ``cd`` into it.

2. Create a file named ``tinuous.yaml`` in this directory `as described above
   <Configuration_>`_

3. Create a file named ``.env`` in this directory containing any needed
   authentication tokens.  Entries are of the form ``NAME=value``, e.g.::

        GITHUB_TOKEN=ghp_abcdef0123456789
        TRAVIS_TOKEN=asdfghjkl
        APPVEYOR_TOKEN=v2.qwertyuiop

4. Create a Python virtualenv_ to provide an isolated environment to install
   ``tinuous`` into::

        python3 -m venv venv

5. Install ``tinuous`` inside the virtualenv::

        venv/bin/pip install tinuous

   If you want to use DataLad with ``tinuous``, you need to install it as well,
   even if it's already installed outside the virtualenv::

        venv/bin/pip install datalad

6. Run ``tinuous`` to fetch your first logs and test your configuration::

        venv/bin/tinuous fetch

7. Once you're satisfied with your ``tinuous`` config, set up scheduled runs by
   creating a cronjob of the form::

        0 0 * * * cd /path/to/directory && chronic flock -n -E 0 .tinuous.lock venv/bin/tinuous fetch

   This job runs once a day at midnight; adjust the cron expression to taste.
   We use ``chronic`` (from moreutils_) to suppress output unless the command
   fails, thus preventing e-mails full of log messages for every run.
   ``flock`` is used to ensure that no more than one instance of ``tinuous`` is
   running at a time.

8. If you want to commit your logs to a Git repository, first make sure that
   ``.env``, ``venv/``, and ``.tinuous.lock`` are included in the repository's
   ``.gitignore``.  Consider setting up the repository with DataLad_; when the
   DataLad integration is enabled, ``tinuous`` will automatically commit any
   new logs at the end of a run.

   If you're using a regular Git repository instead, you can commit any new
   logs at the end of a run by adding the following script to your ``tinuous``
   directory:

   .. code:: bash

       #!/bin/bash
       set -ex
       venv/bin/tinuous fetch
       git add --all
       if ! git diff --cached --quiet
       then git commit -m "Ran tinuous"
            # Uncomment if you want to push the commits to a remote repository:
            #git push
       fi

   and changing your cronjob to::

        0 0 * * * cd /path/to/directory && chronic flock -n -E 0 .tinuous.lock bash name-of-script.sh

9. If you ever need to upgrade ``tinuous``, run the following command inside
   your ``tinuous`` directory::

        venv/bin/pip install --upgrade tinuous

10. Enjoy your collection of logs, build artifacts, and/or release assets!

.. _virtualenv: https://packaging.python.org/guides/installing-using-pip-and
                -virtual-environments/

.. _moreutils: https://joeyh.name/code/moreutils/

            

Raw data

            {
    "_id": null,
    "home_page": "https://github.com/con/tinuous",
    "name": "tinuous",
    "maintainer": "John T. Wodder II",
    "docs_url": null,
    "requires_python": "~=3.8",
    "maintainer_email": "tinuous@varonathe.org",
    "keywords": "Appveyor,GitHub Actions,Travis CI,continuous integration",
    "author": "Center for Open Neuroscience",
    "author_email": "debian@onerussian.com",
    "download_url": "https://files.pythonhosted.org/packages/9b/c0/de2c925c765eae01884854d77c61a142eab1dcf0dd63bbd679b21e5ca624/tinuous-0.6.1.tar.gz",
    "platform": null,
    "description": ".. image:: https://github.com/con/tinuous/workflows/Test/badge.svg?branch=master\n    :target: https://github.com/con/tinuous/actions?workflow=Test\n    :alt: GitHub Actions Status\n\n.. image:: https://travis-ci.com/con/tinuous.svg?branch=master\n    :target: https://travis-ci.com/con/tinuous\n    :alt: Travis CI Status\n\n.. image:: https://ci.appveyor.com/api/projects/status/github/con/tinuous?branch=master&svg=true\n    :target: https://ci.appveyor.com/project/yarikoptic/tinuous/branch/master\n    :alt: Appveyor Status\n\n.. image:: https://img.shields.io/pypi/pyversions/tinuous.svg\n    :target: https://pypi.org/project/tinuous/\n\n.. image:: https://img.shields.io/conda/vn/conda-forge/tinuous.svg\n    :target: https://anaconda.org/conda-forge/tinuous\n    :alt: Conda Version\n\n.. image:: https://img.shields.io/github/license/con/tinuous.svg\n    :target: https://opensource.org/licenses/MIT\n    :alt: MIT License\n\n`GitHub <https://github.com/con/tinuous>`_\n| `PyPI <https://pypi.org/project/tinuous/>`_\n| `Anaconda <https://anaconda.org/conda-forge/tinuous>`_\n| `Issues <https://github.com/con/tinuous/issues>`_\n| `Changelog <https://github.com/con/tinuous/blob/master/CHANGELOG.md>`_\n\n``tinuous`` is a command for downloading build logs and (for GitHub\nonly) artifacts & release assets for a GitHub repository from GitHub Actions,\nTravis-CI.com, and/or Appveyor.\n\nSee <https://github.com/con/tinuous-inception> for an example setup that uses\n``tinuous`` with GitHub Actions to fetch the CI logs for ``tinuous`` itself.\n\nInstallation\n============\n``tinuous`` requires Python 3.8 or higher.  Just use `pip\n<https://pip.pypa.io>`_ for Python 3 (You have pip, right?) to install\n``tinuous`` and its dependencies::\n\n    python3 -m pip install tinuous\n\n``tinuous`` can also optionally integrate with DataLad_.  To install DataLad\nalongside ``tinuous``, specify the ``datalad`` extra::\n\n    python3 -m pip install \"tinuous[datalad]\"\n\n``tinuous`` is also available for conda!  To install, run::\n\n    conda install -c conda-forge tinuous\n\n\nUsage\n=====\n\n::\n\n    tinuous [<global options>] <command> [<args> ...]\n\n\nGlobal Options\n--------------\n\n-c FILE, --config FILE          Read configuration from the given file [default\n                                value: ``tinuous.yaml``]\n\n-E FILE, --env FILE             Load environment variables from the given\n                                ``.env`` file.  By default, environment\n                                variables are loaded from the first file named\n                                \"``.env``\" found by searching from the current\n                                directory upwards.\n\n                                **Warning**: Care must be taken when this file\n                                is located in a Git repository so as not to\n                                publicly expose it: either list the file in\n                                ``.gitignore`` or, if using DataLad or\n                                git-annex, configure git-annex to prohibit\n                                public sharing of the file.\n\n-l LEVEL, --log-level LEVEL     Set the log level to the given value.  Possible\n                                values are \"``CRITICAL``\", \"``ERROR``\",\n                                \"``WARNING``\", \"``INFO``\", \"``DEBUG``\" (all\n                                case-insensitive) and their Python integer\n                                equivalents.  [default value: INFO]\n\n\n``fetch`` Command\n-----------------\n\n::\n\n    tinuous [<global options>] fetch [<options>]\n\n``tinuous fetch`` reads a configuration file telling it what repository to\nretrieve logs & artifacts for, where to retrieve them from, and where to save\nthem, and then it carries those steps out.\n\nOptions\n~~~~~~~\n\n--sanitize-secrets              Sanitize secrets from log files after\n                                downloading\n\n-S FILE, --state FILE           Store program state (e.g., timestamps before\n                                which all asset are known to have been fetched)\n                                in the given file [default value:\n                                ``.tinuous.state.json``]\n\n``sanitize`` Command\n--------------------\n\n::\n\n    tinuous [<global options>] sanitize <path> ...\n\nSanitize the given files, replacing all strings matching a secret regex with a\nseries of asterisks.\n\n\nConfiguration\n-------------\n\nThe configuration file is a YAML file containing a mapping with the following\nkeys:\n\n``repo``\n    *(required)* The GitHub repository to retrieve assets for, in the form ``OWNER/NAME``\n\n``vars``\n    A mapping defining custom path template placeholders.  Each key is the name\n    of a custom placeholder, without enclosing braces, and the value is the\n    string to substitute in its place.  Custom values may contain standard path\n    template placeholders as well as other custom placeholders.\n\n``ci``\n    *(required)* A mapping from the names of the CI systems from which to\n    retrieve assets to sub-mappings containing CI-specific configuration.\n    Including a given CI system is optional; assets will only be fetched from a\n    given system if it is listed in this mapping.\n\n    The CI systems and their sub-mappings are as follows:\n\n    ``github``\n        Configuration for retrieving assets from GitHub Actions.  Subfields:\n\n        ``paths``\n            A mapping giving `template strings <Path Templates_>`_ for the\n            paths at which to save various types of assets.  If this is empty\n            or not present, no assets are retrieved.  Subfields:\n\n            ``logs``\n                A template string that will be instantiated for each workflow\n                run to produce the path for the directory (relative to the\n                current working directory) under which the run's build logs\n                will be saved.  If this is not specified, no logs will be\n                downloaded.\n\n            ``artifacts``\n                A template string that will be instantiated for each workflow\n                run to produce the path for the directory (relative to the\n                current working directory) under which the run's artifacts will\n                be saved.  If this is not specified, no artifacts will be\n                downloaded.\n\n            ``releases``\n                A template string that will be instantiated for each\n                (non-draft, non-prerelease) GitHub release to produce the path\n                for the directory (relative to the current working directory)\n                under which the release's assets will be saved.  If this is not\n                specified, no release assets will be downloaded.\n\n        ``workflows``\n            A specification of the workflows for which to retrieve assets.\n            This can be either a list of workflow basenames, including the file\n            extension (e.g., ``test.yml``, not ``.github/workflows/test.yml``)\n            or a mapping containing the following fields:\n\n            ``include``\n                A list of workflows to retrieve assets for, given as either\n                basenames or (when ``regex`` is true) `Python regular\n                expressions`_ to match against basenames.  If ``include`` is\n                omitted, it defaults to including all workflows.\n\n            ``exclude``\n                A list of workflows to not retrieve assets for, given as either\n                basenames or (when ``regex`` is true) `Python regular\n                expressions`_ to match against basenames.  If ``exclude`` is\n                omitted, no workflows are excluded.  Workflows that match both\n                ``include`` and ``exclude`` are excluded.\n\n            ``regex``\n                A boolean.  If true (default false), the elements of the\n                ``include`` and ``exclude`` fields are treated as `Python\n                regular expressions`_ that are matched (unanchored) against\n                workflow basenames; if false, they are used as exact names\n\n            When ``workflows`` is not specified, assets are retrieved for all\n            workflows in the repository.\n\n    ``travis``\n        Configuration for retrieving logs from Travis-CI.com.  Subfield:\n\n        ``paths``\n            A mapping giving `template strings <Path Templates_>`_ for the\n            paths at which to save various types of assets.  If this is empty\n            or not present, no assets are retrieved.  Subfield:\n\n            ``logs``\n                A template string that will be instantiated for each job of\n                each build to produce the path for the file (relative to the\n                current working directory) in which the job's logs will be\n                saved.  If this is not specified, no logs will be downloaded.\n\n    ``appveyor``\n        Configuration for retrieving logs from Appveyor.  Subfields:\n\n        ``paths``\n            A mapping giving `template strings <Path Templates_>`_ for the\n            paths at which to save various types of assets.  If this is empty\n            or not present, no assets are retrieved.  Subfield:\n\n            ``logs``\n                A template string that will be instantiated for each job of\n                each build to produce the path for the file (relative to the\n                current working directory) in which the job's logs will be\n                saved.  If this is not specified, no logs will be downloaded.\n\n        ``accountName``\n            *(required)* The name of the Appveyor account to which the\n            repository belongs on Appveyor\n\n        ``projectSlug``\n            The project slug for the repository on Appveyor; if not specified,\n            it is assumed that the slug is the same as the repository name\n\n``since``\n    A timestamp (date, time, & timezone); only assets for builds started after\n    the given point in time will be retrieved.  If not specified, the cutoff\n    set by ``max-days-back`` will be used.\n\n    As the script retrieves new build assets, it keeps track of their starting\n    points.  Once the assets for all builds for the given CI system &\n    configuration have been fetched up to a certain point, the timestamp for\n    the latest such build is stored in the state file and used as the new\n    ``since`` value for the respective CI system on subsequent runs.  If the\n    ``since`` setting in the configuration file is then updated to a newer\n    timestamp, the configuration will override the value in the state file, and\n    the next ``tinuous`` run will only retrieve assets after the new setting.\n\n``max-days-back``\n    An integer specifying the maximum number of days back to look for builds;\n    defaults to 30.\n\n    If ``since`` is earlier than the date indicated by this value, and if the\n    timestamp for a given CI system saved in the state file is either missing\n    (i.e., if this is the first run of ``tinuous`` against the CI system) or\n    older than ``since``, then ``tinuous`` will use the explicitly-specified\n    ``since`` value as the cutoff and ignore ``max-days-back``.\n\n``until``\n    A timestamp (date, time, & timezone); only assets for builds started before\n    the given point in time will be retrieved\n\n``types``\n    A list of build trigger event types; only assets for builds triggered by\n    one of the given events will be retrieved.  If this is not specified,\n    assets will be retrieved for all recognized event types.\n\n    The recognized event types are:\n\n    ``cron``\n        A build run on a schedule\n\n    ``manual``\n        A build triggered manually by a human or through the CI system's API\n\n    ``pr``\n        A build in response to activity on a pull request\n\n    ``push``\n        A build in response to new commits\n\n``secrets``\n    A mapping from names (used in log messages) to `Python regular\n    expressions`_ matching secrets to sanitize\n\n``allow-secrets-regex``\n    Any strings that match a ``secrets`` regex and also match this regex will\n    not be sanitized.  Note that ``allow-secrets-regex`` is tested against just\n    the substring that matched a ``secrets`` regex without any surrounding\n    text, and so lookahead and lookbehind will not work in this regex.\n\n``datalad``\n    A sub-mapping describing integration of ``tinuous`` with DataLad_.\n    Subfields:\n\n    ``enabled``\n        A boolean.  If true (default false), DataLad must be installed, the\n        current directory will be converted into a DataLad dataset if it is not\n        one already, the assets will optionally be divided up into subdatasets,\n        and all new assets will be committed at the end of a run of ``tinuous\n        fetch``.  ``path`` template strings may contain ``//`` separators\n        indicating the boundaries of subdatasets.\n\n    ``cfg_proc``\n        Procedure to run on the dataset & subdatasets when creating them\n\n    .. _DataLad: https://www.datalad.org\n\n.. _Python regular expressions: https://docs.python.org/3/library/re.html\n                                #regular-expression-syntax\n\nA sample config file:\n\n.. code:: yaml\n\n    repo: datalad/datalad\n    vars:\n      path_prefix: '{year}//{month}//{day}/{ci}/{type}'\n      build_prefix: '{path_prefix}/{type_id}/{build_commit[:7]}'\n    ci:\n      github:\n        paths:\n          logs: '{build_prefix}/{wf_name}/{number}/logs/'\n          artifacts: '{build_prefix}/{wf_name}/{number}/artifacts/'\n          releases: '{path_prefix}/{release_tag}/'\n        workflows:\n          - test_crippled.yml\n          - test_extensions.yml\n          - test_macos.yml\n      travis:\n        paths:\n          logs: '{build_prefix}/{number}/{job}.txt'\n      appveyor:\n        paths:\n          logs: '{build_prefix}/{number}/{job}.txt'\n        accountName: mih\n        projectSlug: datalad\n    since: 2021-01-20T00:00:00Z\n    max-days-back: 14\n    types: [cron, manual, pr, push]\n    secrets:\n      github: '\\bgh[a-z]_[A-Za-z0-9]{36,}\\b'\n      docker-hub: '\\b[a-f0-9]{8}(?:-[a-f0-9]{4}){3}-[a-f0-9]{12}\\b'\n      appveyor: '\\b(v2\\.)?[a-z0-9]{20}\\b'\n      travis: '\\b[a-zA-Z0-9]{22}\\b'\n      aws: '\\b[a-zA-Z0-9+/]{40}\\b'\n    datalad:\n      enabled: true\n      cfg_proc: text2git\n\n\nPath Templates\n--------------\n\nThe path at which assets for a given workflow run, build job, or release are\nsaved is determined by instantiating the appropriate path template string given\nin the configuration file for the corresponding CI system.  A template string\nis a filepath containing placeholders of the form ``{field}``, where the\navailable placeholders are:\n\n======================  =======================================================\nPlaceholder             Definition\n======================  =======================================================\n``{year}``              The four-digit year in which the build was started or\n                        the release was published\n``{month}``             The two-digit month in which the build was started or\n                        the release was published\n``{day}``               The two-digit day in which the build was started or the\n                        release was published\n``{hour}``              The two-digit hour at which the build was started or\n                        the release was published\n``{minute}``            The two-digit minute at which the build was started or\n                        the release was published\n``{second}``            The two-digit second at which the build was started or\n                        the release was published\n``{timestamp}``         The date & time at which the build was started or the\n                        release was published.  This is a Python datetime_\n                        value; it can be formatted with a `strftime()`_ format\n                        string by writing ``{timestamp:FORMAT}``, e.g.,\n                        ``{timestamp:%Y-%b-%d}`` will produce a string of the\n                        form \"2021-Jun-14\".  If written as just\n                        ``{timestamp}``, the date & time will be formatted in\n                        ISO 8601 format.\n``{timestamp_local}``   The date & time at which the build was started or the\n                        release was published, in the local system timezone.\n                        This is formatted in the same way as ``{timestamp}``.\n``{ci}``                The name of the CI system (``github``, ``travis``, or\n                        ``appveyor``)\n``{type}``              The event type that triggered the build (``cron``,\n                        ``manual``, ``pr``, or ``push``), or ``release`` for\n                        GitHub releases\n``{type_id}``           Further information on the triggering event; for\n                        ``cron`` and ``manual``, this is a timestamp for the\n                        start of the build; for ``pr``, this is the number of\n                        the associated pull request, or ``UNK`` if it cannot be\n                        determined; for ``push``, this is the escaped [1]_ name\n                        of the branch to which the push was made (or possibly\n                        the tag that was pushed, if using Appveyor) [2]_\n``{release_tag}``       *(``releases_path`` only)* The release tag\n``{build_commit}``      The hash of the commit the build ran against or that\n                        was tagged for the release.  Note that, for PR builds\n                        on Travis and Appveyor, this is the hash of an\n                        autogenerated merge commit.\n``{commit}``            The hash of the original commit that triggered the\n                        build or that was tagged for the release.  For pull\n                        request builds, this is the head of the PR branch, or\n                        ``UNK`` if it cannot be determined.  For other builds\n                        (along with PR builds on GitHub Actions), this is\n                        always the same as ``{build_commit}``.\n``{number}``            The run number of the workflow run (GitHub) or the\n                        build number (Travis and Appveyor) [2]_\n``{status}``            The success status of the workflow run (GitHub) or job\n                        (Travis and Appveyor); the exact strings used depend on\n                        the CI system [2]_\n``{common_status}``     The success status of the workflow run or job,\n                        normalized into one of ``success``, ``failed``,\n                        ``errored``, or ``incomplete`` [2]_\n``{wf_name}``           *(GitHub only)* The escaped [1]_ name of the workflow\n                        [2]_\n``{wf_file}``           *(GitHub only)* The basename of the workflow file\n                        (including the file extension) [2]_\n``{run_id}``            *(GitHub only)* The unique ID of the workflow run [2]_\n``{job}``               *(Travis and Appveyor only)* The number of the job,\n                        without the build number prefix (Travis) or the job ID\n                        string (Appveyor) [2]_\n``{job_index}``         *(Travis and Appveyor only)* The index of the job in\n                        the list returned by the API, starting from 1 [2]_\n``{job_env}``           *(Appveyor only)* The escaped [1]_ environment\n                        variables specific to the job [2]_\n``{job_env_hash}``      *(Appveyor only)* The SHA1 hash of ``{job_env}`` before\n                        escaping [2]_\n======================  =======================================================\n\n.. _datetime: https://docs.python.org/3/library/datetime.html#datetime-objects\n.. _strftime(): https://docs.python.org/3/library/datetime.html\n                #strftime-and-strptime-format-codes\n\n.. [1] Escaping consists of percent-encoding the characters ``\\/<>:|\"?*%`` and\n       replacing each whitespace character with a space.\n\n.. [2] These placeholders are only available for ``path`` and\n       ``artifacts_path``, not ``releases_path``\n\nA placeholder's value may be truncated to the first ``n`` characters by writing\n``{placeholder[:n]}``, e.g., ``{commit[:7]}``.\n\nAll timestamps and timestamp components (other than ``{timestamp_local}``) are\nin UTC.\n\nPath templates may also contain custom placeholders defined in the top-level\n``vars`` mapping of the configuration.\n\nAuthentication\n--------------\n\nNote that environment variables can be loaded from a ``.env`` file as an\nalternative to setting them directly in the environment.\n\nGitHub\n~~~~~~\n\nIn order to retrieve assets from GitHub, a GitHub OAuth token must be specified\neither via the ``GITHUB_TOKEN`` environment variable or as the value of the\n``hub.oauthtoken`` Git config option.\n\nTravis\n~~~~~~\n\nIn order to retrieve logs from Travis, a Travis API access token must be either\nspecified via the ``TRAVIS_TOKEN`` environment variable or be retrievable by\nrunning ``travis token --com --no-interactive``.\n\nA Travis API access token can be acquired as follows:\n\n- Install the `Travis command line client\n  <https://github.com/travis-ci/travis.rb>`_.\n\n- Run ``travis login --com`` to authenticate.\n\n  - If your Travis account is linked to your GitHub account, you can\n    authenticate by running ``travis login --com --github-token\n    $GITHUB_TOKEN``.\n\n- If the script will be run on the same machine that the above steps are\n  carried out on, you can stop here, and the script will retrieve the token\n  directly from the ``travis`` command.\n\n- Run ``travis token --com`` to retrieve the API access token.\n\nThe Travis integration also requires a GitHub OAuth token in order to look up\ninformation on pull requests that the Travis API does not report; this token\nmust be specified in the same way as for the GitHub integration.\n\nAppveyor\n~~~~~~~~\n\nIn order to retrieve logs from Appveyor, an Appveyor API key (for either all\naccessible accounts or just the specific account associated with the\nrepository) must be specified via the ``APPVEYOR_TOKEN`` environment variable.\nSuch a key can be obtained at <https://ci.appveyor.com/api-keys>.\n\n\nCron Integration\n================\n\nIf you want to set up scheduled runs of ``tinuous`` on a Linux server, one way\nis as follows:\n\n1. Create a new directory and ``cd`` into it.\n\n2. Create a file named ``tinuous.yaml`` in this directory `as described above\n   <Configuration_>`_\n\n3. Create a file named ``.env`` in this directory containing any needed\n   authentication tokens.  Entries are of the form ``NAME=value``, e.g.::\n\n        GITHUB_TOKEN=ghp_abcdef0123456789\n        TRAVIS_TOKEN=asdfghjkl\n        APPVEYOR_TOKEN=v2.qwertyuiop\n\n4. Create a Python virtualenv_ to provide an isolated environment to install\n   ``tinuous`` into::\n\n        python3 -m venv venv\n\n5. Install ``tinuous`` inside the virtualenv::\n\n        venv/bin/pip install tinuous\n\n   If you want to use DataLad with ``tinuous``, you need to install it as well,\n   even if it's already installed outside the virtualenv::\n\n        venv/bin/pip install datalad\n\n6. Run ``tinuous`` to fetch your first logs and test your configuration::\n\n        venv/bin/tinuous fetch\n\n7. Once you're satisfied with your ``tinuous`` config, set up scheduled runs by\n   creating a cronjob of the form::\n\n        0 0 * * * cd /path/to/directory && chronic flock -n -E 0 .tinuous.lock venv/bin/tinuous fetch\n\n   This job runs once a day at midnight; adjust the cron expression to taste.\n   We use ``chronic`` (from moreutils_) to suppress output unless the command\n   fails, thus preventing e-mails full of log messages for every run.\n   ``flock`` is used to ensure that no more than one instance of ``tinuous`` is\n   running at a time.\n\n8. If you want to commit your logs to a Git repository, first make sure that\n   ``.env``, ``venv/``, and ``.tinuous.lock`` are included in the repository's\n   ``.gitignore``.  Consider setting up the repository with DataLad_; when the\n   DataLad integration is enabled, ``tinuous`` will automatically commit any\n   new logs at the end of a run.\n\n   If you're using a regular Git repository instead, you can commit any new\n   logs at the end of a run by adding the following script to your ``tinuous``\n   directory:\n\n   .. code:: bash\n\n       #!/bin/bash\n       set -ex\n       venv/bin/tinuous fetch\n       git add --all\n       if ! git diff --cached --quiet\n       then git commit -m \"Ran tinuous\"\n            # Uncomment if you want to push the commits to a remote repository:\n            #git push\n       fi\n\n   and changing your cronjob to::\n\n        0 0 * * * cd /path/to/directory && chronic flock -n -E 0 .tinuous.lock bash name-of-script.sh\n\n9. If you ever need to upgrade ``tinuous``, run the following command inside\n   your ``tinuous`` directory::\n\n        venv/bin/pip install --upgrade tinuous\n\n10. Enjoy your collection of logs, build artifacts, and/or release assets!\n\n.. _virtualenv: https://packaging.python.org/guides/installing-using-pip-and\n                -virtual-environments/\n\n.. _moreutils: https://joeyh.name/code/moreutils/\n",
    "bugtrack_url": null,
    "license": "MIT",
    "summary": "Download build logs from GitHub Actions, Travis, and Appveyor",
    "version": "0.6.1",
    "split_keywords": [
        "appveyor",
        "github actions",
        "travis ci",
        "continuous integration"
    ],
    "urls": [
        {
            "comment_text": "",
            "digests": {
                "blake2b_256": "f7d2fcaaedc3ed27b6f841177433fe50c808fd07895a42a1eb1ca2156b1b1aa8",
                "md5": "cea5d736e9dc5464f7f67856f1f2e64d",
                "sha256": "49640b089ce18d741b690936fb5c08efb2d3b3edc3bdf58fe80aee7706b0203e"
            },
            "downloads": -1,
            "filename": "tinuous-0.6.1-py3-none-any.whl",
            "has_sig": false,
            "md5_digest": "cea5d736e9dc5464f7f67856f1f2e64d",
            "packagetype": "bdist_wheel",
            "python_version": "py3",
            "requires_python": "~=3.8",
            "size": 29703,
            "upload_time": "2023-02-09T22:47:01",
            "upload_time_iso_8601": "2023-02-09T22:47:01.454911Z",
            "url": "https://files.pythonhosted.org/packages/f7/d2/fcaaedc3ed27b6f841177433fe50c808fd07895a42a1eb1ca2156b1b1aa8/tinuous-0.6.1-py3-none-any.whl",
            "yanked": false,
            "yanked_reason": null
        },
        {
            "comment_text": "",
            "digests": {
                "blake2b_256": "9bc0de2c925c765eae01884854d77c61a142eab1dcf0dd63bbd679b21e5ca624",
                "md5": "c6a180a93f0e8e314f9d3ce4a81a147d",
                "sha256": "5c0ac2907cadff890338c271be31fa59cb291f02f9879e18a0fa43be62da447b"
            },
            "downloads": -1,
            "filename": "tinuous-0.6.1.tar.gz",
            "has_sig": false,
            "md5_digest": "c6a180a93f0e8e314f9d3ce4a81a147d",
            "packagetype": "sdist",
            "python_version": "source",
            "requires_python": "~=3.8",
            "size": 55100,
            "upload_time": "2023-02-09T22:47:03",
            "upload_time_iso_8601": "2023-02-09T22:47:03.463853Z",
            "url": "https://files.pythonhosted.org/packages/9b/c0/de2c925c765eae01884854d77c61a142eab1dcf0dd63bbd679b21e5ca624/tinuous-0.6.1.tar.gz",
            "yanked": false,
            "yanked_reason": null
        }
    ],
    "upload_time": "2023-02-09 22:47:03",
    "github": true,
    "gitlab": false,
    "bitbucket": false,
    "github_user": "con",
    "github_project": "tinuous",
    "travis_ci": true,
    "coveralls": false,
    "github_actions": true,
    "appveyor": true,
    "circle": true,
    "tox": true,
    "lcname": "tinuous"
}
        
Elapsed time: 0.04176s