Kubuntu/CI/Metadata: Difference between revisions

Latest revision as of 12:36, 29 April 2015

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/
- 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

@@ Line 2: / Line 2: @@
 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:<p>Single-line file containing the full upstream repository URL. May contain a final newline, scripts should strip accordingly when reading the file as a whole.</p>
+* () single-line:<p>Single-line file containing one data entry URL. May contain a final newline, scripts should strip accordingly when reading the file as a whole.</p>
+* () multi-line:<p>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.</p>
 * (.json) json:<p>Valid json data.</p>
 == Files ==
 * debian/meta/
-** repo<p>''single-line'' :: URL to upstream source repository.</p>
+** tarball<p>''single-line'' :: URL to upstream tarball (only useful for release branches - currently not used).</p><p>Fallback: uscan</p>
-** branch<p>''single-line'' :: URL to upstream source branch in repository.</p>
+** cmake-ignore<p>''multi-line'' :: An array of cmake-dependency identifiers to ignore when reported as missing.</p><p>Fallback: nil</p>
-** tarball<p>''single-line'' :: URL to upstream tarball (only useful for release branches - currently not used).</p>
-** cmake-ignore.json<p>''json'' :: An array of cmake-dependency identifiers to ignore when reported as missing.</p>