TODO to fix in the documentation
Todo
Document (and possibly fix) what happens when workers are restarted while running a task.
Todo
We should have a simpler way to manage signing keys: perhaps they should be stored in artifacts and referenced using lookups.
Todo
Add new explanation pages to cover:
architecture (server, worker, client)
Todo
Add new reference pages to cover:
debusine-client configuration file
debusine-server configuration file
debusine-worker configuration file
Todo
We’ll eventually need to deal with removing private keys from the signing service when they’re no longer referenced by anything in the debusine database, but it’s not clear exactly what the lifetime rules should be. See https://salsa.debian.org/freexian-team/debusine/-/merge_requests/616#note_497019.
Todo
The definition of this category is not yet fully agreed. We’ll revisit it when we’re closer to being able to try out an implementation so that we can see how the lookup mechanisms will work.
Todo
The whole expiration point needs some redesign, tracked in issue #346
Todo
We will probably need the ability to control parameters such as
fail_on
in sub-workflows, but these are often quite
package-specific. This may need to be handled via pipeline instructions
rather than via this workflow’s task data.
Todo
This workflow does not currently handle checking for regressions against a base reference.
Todo
Implement a management command to rename a scope.
This is likely to be a simple management command that changes
Scope.name
, since only foreign keys to scope are used to refer to scope
at the database level.
Todo
Add a DEFAULT_SCOPE
(or TRANSITIONAL_DEFAULT_SCOPE
) setting
(defaulting to debusine
) to specify the name of the default scope to use
during the transitioning period where not all of Debusine is yet
scope-aware.
Todo
Design a way to set up a system of best-effort redirects.
Todo
Document a header in API calls used to select scope.
When the header is missing, use the fallback scope.
Add a configuration option in debusine-client
to select the default scope.
Add a command line option in debusine-client
to specify a different scope.
Make sure we have a scope-aware client in testing and stable-backports before we drop support for unscoped API calls.
Todo
Decide whether we want to support multiple configuration contexts? A task could return multiple contexts and typically the sbuild task could usefully have parameters related to the host_architecture and to the target suite, on top of parameters related to the source package.
It could be achieved with context values like suite=jessie
and
architecture=arm64
.
Todo
Specify how to configure keys to be used with a YubiKey.
Todo
Add more precise details of how this is recorded.
Todo
architectures
should be optional, but discovering the available
architectures without having to implement delicate GPG verification code
ourselves is hard; see message #49 in #848194.
Todo
Document exactly how transactional updates of collections work in general: tasks need to see a coherent state, and simple updates to collections can be done in a database transaction, but some longer update tasks where using a single database transaction is impractical may need more careful handling. See discussion in !517.
Todo
This will need additional parameters once we start supporting HSMs.
Todo
The selection of the host architecture for architecture-independent binary packages should be controlled by pipeline instructions. A similar mechanism might also control multiarch tests, such as testing i386 packages on an amd64 testbed.