Jump to content

Kubuntu/CI/Metadata: Difference between revisions

From KDE Community Wiki
No edit summary
No edit summary
Line 14: Line 14:
== Files ==
== Files ==
* debian/meta/
* debian/meta/
** repo<p>''single-line'' :: URL to upstream source repository.</p><p>Fallback: anongit.kde.org/SOURCENAME</p>
** upstream_scm.json<p>''json'' :: And upstream SCM object with properties 'type', 'url', and 'branch' (where appropriate).</p><p>Fallback: git + anongit + master</p>
** repo-type<p>''single-line'' :: An identifier for the repo type. The identifier is always the central CLI program (e.g. git for git or hg for mecurial).</p><p>Fallback: git</p>
** branch<p>''single-line'' :: URL to upstream source branch in repository.</p><p>Fallback: master</p>
** tarball<p>''single-line'' :: URL to upstream tarball (only useful for release branches - currently not used).</p><p>Fallback: uscan</p>
** tarball<p>''single-line'' :: URL to upstream tarball (only useful for release branches - currently not used).</p><p>Fallback: uscan</p>
** cmake-ignore<p>''multi-line'' :: An array of cmake-dependency identifiers to ignore when reported as missing.</p><p>Fallback: nil</p>
** cmake-ignore<p>''multi-line'' :: An array of cmake-dependency identifiers to ignore when reported as missing.</p><p>Fallback: nil</p>
** qml-ignore.json<p>TBD</p>
** qml-ignore.json<p>TBD</p>

Revision as of 12:05, 10 November 2014

This page outlines the debian/meta/ directory contents used by CI systems to create builds. The foremost reason the metadata is stored in debian/, and thus in a branch dependent manner, is because data might be different on a per-branch basis.

debian/meta/ can be present and useful for release branches if they are also subject to automation.

If a file is not present suitable fallback values should be used.

Format Types

File suffix always indicates the format used! The file format usually depends on the primary use language the file would be used in. If data is useful in a number of different languages with different builtin parsing capabilities (e.g. presence of json support) it will usually be using single-line format. For advanced matters we always assume json support and as such json is the preferred data format for constructs that cannot easily be expressed in single-line.

  • () single-line:

    Single-line file containing one data entry URL. May contain a final newline, scripts should strip accordingly when reading the file as a whole.

  • () multi-line:

    Multi-line file containing many different data lines. This roughly translates to an array of data. May contain a final newline, scripts should strip accordingly when reading the file as a whole.

  • (.json) json:

    Valid json data.

Files

  • debian/meta/
    • upstream_scm.json

      json :: And upstream SCM object with properties 'type', 'url', and 'branch' (where appropriate).

      Fallback: git + anongit + master

    • tarball

      single-line :: URL to upstream tarball (only useful for release branches - currently not used).

      Fallback: uscan

    • cmake-ignore

      multi-line :: An array of cmake-dependency identifiers to ignore when reported as missing.

      Fallback: nil

    • qml-ignore.json

      TBD