TODO to fix in the documentation

Todo

Document (and possibly fix) what happens when workers are restarted while running a task.

original entry

Todo

We should have a simpler way to manage signing keys: perhaps they should be stored in artifacts and referenced using lookups.

original entry

Todo

Add new explanation pages to cover:

  • architecture (server, worker, client)

original entry

Todo

Add new reference pages to cover:

  • debusine-client configuration file

  • debusine-server configuration file

  • debusine-worker configuration file

original entry

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.

original entry

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.

original entry

Todo

The whole expiration point needs some redesign, tracked in issue #346

original entry

Todo

Include here documentation about the various configuration files.

original entry

Todo

Check whether it’s feasible to implement this in debusine itself as a server-side task. If not, we’ll need to make it a worker task and consider what environment it should run in.

original entry

Todo

Define the output. It should probably be a new artifact category, produced only if the task fails, containing the list of newly-uninstallable packages.

original entry

Todo

We will probably need the ability to control parameters such as fail_on in sub-workflows, but these are often quite package-specific.

original entry

Todo

This workflow does not currently handle checking for regressions against a base reference.

original entry

Todo

Design a way to set up a system of best-effort redirects.

original entry

Todo

Document a header in API calls used to select scope.

When the header is missing, use the fallback scope.

Make sure we have a scope-aware client in testing and stable-backports before we drop support for unscoped API calls.

original entry

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.

original entry

Todo

Specify how to configure keys to be used with a YubiKey.

original entry

Todo

Add more precise details of how this is recorded.

original entry

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.

original entry

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.

original entry

Todo

This will need additional parameters once we start supporting HSMs.

original entry

Todo

It would be useful to have a mechanism to control multiarch tests, such as testing i386 packages on an amd64 testbed.

original entry

Todo

Not implemented: enable_check_installability, check_installability_suite, enable_reverse_dependencies_autopkgtest, reverse_dependencies_autopkgtest_suite and enable_confirmation. See the relevant blueprints for task installability, reverse dependencies autopkgtest or enable confirmation.

original entry

Todo

There should also be an option to add the results to a debian:suite collection rather than uploading it to an external queue. However, this isn’t very useful until debusine has its own repository hosting, and once it does, we’ll need to be able to apply consistency checks to uploads rather than just adding them to suites in an unconstrained way. This will probably involve a new workflow yet to be designed.

original entry

Todo

The pipeline should also include the ability to schedule a debdiff against a baseline suite (either directly or in a sub-workflow).

original entry

Todo

We may need to use different keys for different architectures. For example, a UEFI signing key is only useful on architectures that use UEFI, and some architectures have other firmware signing arrangements.

original entry

Todo

Permission checks for this workflow are not yet implemented.

original entry

Todo

Copying into debusine:task-history still needs to be added once that collection is fully implemented.

original entry

Todo

It would be useful to have a mechanism to control multiarch tests, such as testing i386 packages on an amd64 testbed.

original entry

Todo

It would be useful to be able to set base_tgz separately from environment.

original entry

Todo

Not implemented: enable_check_installability, check_installability_suite, enable_reverse_dependencies_autopkgtest and reverse_dependencies_autopkgtest_suite.

original entry