Skip to content
Snippets Groups Projects
Commit c28f614c authored by David Boddie's avatar David Boddie :speech_balloon:
Browse files

Add more information about parameters, note order of entries

parent 70ff12b3
No related branches found
No related tags found
1 merge request!296Resolve "Package-build infrastructure needs documentation"
Pipeline #19820 passed
......@@ -39,7 +39,7 @@ Only the ``url`` parameter is required, but the ``branch`` parameter should also
Parameters other than ``url``, ``archs``, ``branch`` and ``dists`` can also be used to configure the build process for a component. The following list describes some of the parameters currently in use:
``archs``
The architectures the component will be built for, specified as a Python-style list. |br|
The architectures the component will be built for, specified as a Python-style list. It is useful to restrict this choice if building a component that is only suitable for a particular architecture. |br|
Default value: ``['aarch64', 'armhf', 'amd64']``
``branch``
The branch in the git repository to use when building. The default value is based on the operating system and distribution being built for. It is better to explicitly specify a branch such as ``master`` than to rely on the default value.
......@@ -47,6 +47,9 @@ Parameters other than ``url``, ``archs``, ``branch`` and ``dists`` can also be u
Options for the ``DEB_BUILD_OPTIONS`` environment variable, specified as a Python-style list. These are passed to the ``gdp`` tool when a package is built. |br| No default value.
``deb_build_profiles``
Options for the ``DEB_BUILD_PROFILES`` environment variable, specified as a Python-style list. These are passed to the ``gdp`` tool when a package is built. |br| No default value.
``dists``
The distributions to build the package for, specified as a Python-style list. Generally, you should choose the same distribution as the core components. |br|
Default value: ``['buster']``
``repo``
Name of the aptly repository used to host the build artifacts. |br|
Default value: ``scratch``
......@@ -67,7 +70,7 @@ To add a new component, follow these steps:
* Clone your new fork locally.
* Make a feature branch that is a pristine copy of the default branch that is checked out after cloning; e.g. with ``git checkout -b add-component-name``
* Add metadata to the ``jobs.yml`` file for the new component, including the relevant fields described in the previous section. Note that the jobs are listed in alphabetical order, so find the appropriate place to insert the new job.
* Add metadata to the ``jobs.yml`` file for the new component, including the relevant fields described in the previous section. Note that the components are listed in alphabetical order, so ensure that the new component maintains the correct order.
* Commit the changes to your branch.
* Test the changes locally -- see :ref:`contributing_testing`.
* When you are ready for the changes to be merged back into the production repository, push your branch back to your fork on the server.
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment