debusine (0.8.1) [PTS] [DDPO]

COMMITS: VCS has seen 21 commits since the 0.8.1 tag

Git: https://salsa.debian.org/freexian-team/debusine.git
JSON
Enter a full Vcs-* header, supported schemes are: Vcs-Bzr, Vcs-Cvs, Vcs-Darcs, Vcs-Git, Vcs-Hg, Vcs-Mtn, Vcs-Svn.
For Vcs-Git append -b branch to select the branch name; append [subdir] if the debian/ directory is not in the repository root.
The next upload will reset the information from the source package headers.
Branch: devel
Path: debian/changelog
Repo size: 12009472
Browser: https://salsa.debian.org/freexian-team/debusine
Last scan: 2025-01-15 15:19:23+00
Next scan: 2025-01-22 16:22:00+00
Open issues: 195
Merge requests: 9
CI pipeline status: success

Debian changelog in Git:

debusine (0.8.1) unstable; urgency=medium

  * New release.
    - Use an in-memory channel layer for tests, rather than Redis (closes:
      #1092587).

 -- Colin Watson <cjwatson@debian.org>  Mon, 13 Jan 2025 16:29:22 +0000

This branch is 21 commits ahead of tag 0.8.1

Git log:

commit 8c98f3f82af6a5106acc1fe52b3b75de44f4213a
Merge: 3977c350 c34e87e5
Author: Colin Watson <cjwatson@debian.org>
Date:   Wed Jan 15 14:32:39 2025 +0000

    Merge branch 'output-data-runtime-statistics' into 'devel'
    
    Record runtime statistics in output_data
    
    See merge request freexian-team/debusine!1562

commit c34e87e52e3efb43c98601fd98a1eb6a46c2cee9
Author: Colin Watson <cjwatson@debian.org>
Date:   Tue Jan 14 12:38:23 2025 +0000

    Record runtime statistics in output_data
    
    Part of #510.

commit 3977c35055950befbb48b42d92a70a8f5b96c32a
Merge: 496adcd0 b79344b2
Author: Colin Watson <cjwatson@debian.org>
Date:   Wed Jan 15 11:33:14 2025 +0000

    Merge branch 'worker-async-fixes' into 'devel'
    
    Fix various worker asyncio issues
    
    See merge request freexian-team/debusine!1564

commit b79344b201bd351233b7e5ca8c1c89e7f13f6f71
Author: Colin Watson <cjwatson@debian.org>
Date:   Tue Jan 14 22:27:28 2025 +0000

    Move Worker._send_task_result to asyncio event loop thread
    
    While debugging an occasional test failure in !1562, I ran into some
    awkward problems caused by `Worker._send_task_result` running in a
    thread and thus not being able to use `asyncio` normally.  I think it
    makes more sense to call it from the event loop, and then its
    environment is more consistent with that of the rest of the worker.

commit ee28ba10293946f18c018330947e136dc6c05190
Author: Colin Watson <cjwatson@debian.org>
Date:   Tue Jan 14 22:18:37 2025 +0000

    Run work_request_completed_update in a separate thread on the worker
    
    We shouldn't be doing blocking I/O in the asyncio event loop thread.

commit eef83bece8066193843896933dec7bcf3f70f27b
Author: Colin Watson <cjwatson@debian.org>
Date:   Tue Jan 14 22:10:48 2025 +0000

    Don't exit worker when reporting completion fails
    
    Since commit e5349048994c32cb3bb175c6cd06340d4a46c4a4, this is no longer
    necessary: the server will retry the running work request when its
    worker next manages to connect and requests a new work request to run,
    so we don't need to worry about leaving the work request stuck in the
    Running state any more.

commit 00168c56b64217945922fa5f9c7d49f5b4ea4638
Author: Colin Watson <cjwatson@debian.org>
Date:   Tue Jan 14 19:11:11 2025 +0000

    Test Worker._reset_state in more situations

commit 8478a5c43c21cfc2f6fc1c874ccd66f992bfc612
Author: Colin Watson <cjwatson@debian.org>
Date:   Tue Jan 14 19:07:04 2025 +0000

    Fix spelling of PYTHONASYNCIODEBUG
    
    As far as I can tell, this environment variable has never been spelled
    `PYTHONASYNCDEBUG`, but always `PYTHONASYNCIODEBUG`.  See
    https://docs.python.org/3/using/cmdline.html#envvar-PYTHONASYNCIODEBUG.

commit 496adcd0333ac42474915f9e8d6d14228fca8e01
Merge: f7a182d1 1ec08a52
Author: Colin Watson <cjwatson@debian.org>
Date:   Tue Jan 14 13:44:59 2025 +0000

    Merge branch 'task-history-collection' into 'devel'
    
    Implement debusine:task-history collection
    
    See merge request freexian-team/debusine!1542

commit 1ec08a529084beeea25f0925e5954fe2a0a13dbf
Author: Colin Watson <cjwatson@debian.org>
Date:   Tue Jan 7 14:40:02 2025 +0000

    Implement debusine:task-history collection
    
    Part of #510.

commit f7a182d1bd3bc8fbecfd3a17b7fec9cb49ae8114
Merge: 91d5905a ac479242
Author: Colin Watson <cjwatson@debian.org>
Date:   Mon Jan 13 17:28:13 2025 +0000

    Merge branch 'extend-task-database-interface' into 'devel'
    
    Extend TaskDatabaseInterface to include artifact category and data
    
    See merge request freexian-team/debusine!1558

commit 91d5905ac5cbd3c96ba4540c3a52caf259bab6bd
Merge: 3c6713c5 1c858f7e
Author: Colin Watson <cjwatson@debian.org>
Date:   Mon Jan 13 17:27:14 2025 +0000

    Merge branch 'fix-lintian-label' into 'devel'
    
    Handle empty Lintian artifacts
    
    Closes #677
    
    See merge request freexian-team/debusine!1559

commit 6374da33085271feb543a7fb949be6aac39f9f8b
Author: Colin Watson <cjwatson@debian.org>
Date:   Tue Jan 7 14:24:13 2025 +0000

    Clarify semantics of old_items_to_keep
    
    I found the previous text a little unclear when trying to implement it.
    This tightens up the wording with my best guess as to what we meant when
    designing this.

commit 51b5f53e5e2e967b6311f1969e3c6b1bb84b9ba5
Author: Colin Watson <cjwatson@debian.org>
Date:   Tue Jan 7 14:21:54 2025 +0000

    work_request_id/result are required for all task history items
    
    `work_request_id` is needed to construct the item name, and `result` is
    useful so that lookups don't always have to join with `WorkRequest`.

commit d68b59b5726b8b699906d6e3ed7e921873ec6c6a
Author: Colin Watson <cjwatson@debian.org>
Date:   Tue Jan 7 14:20:05 2025 +0000

    Improve ergonomics of creating bare data items
    
    Having the option to pass a pydantic model rather than a dictionary
    helps to avoid typos.

commit fa14529a27416a8f230b2df6c52a36320ddbfdb4
Author: Colin Watson <cjwatson@debian.org>
Date:   Tue Jan 7 13:35:51 2025 +0000

    Move RuntimeStatistics to debusine.artifacts.models
    
    I'm about to want to use it in the model for
    `debusine:historical-task-run` bare data items.

commit b3a5f0dde2abdc1f605f0c53c13c9fb8cd742516
Author: Colin Watson <cjwatson@debian.org>
Date:   Tue Jan 7 13:24:39 2025 +0000

    Add explicit cast to build log lookup filtering
    
    This makes the query slightly more accurate
    (`(("db_collectionitem"."data" -> work_request_id))::integer IN (1)`
    instead of `("db_collectionitem"."data" -> work_request_id) IN ('1')`).
    It doesn't seem to make a practical difference in this case, but this
    pattern works better when the right-hand side of the `IN` is something
    more complicated such as a subquery.

commit 1c858f7e9dc30d195a00333c79cfe61656845afa
Author: Colin Watson <cjwatson@debian.org>
Date:   Mon Jan 13 12:29:31 2025 +0000

    Handle empty Lintian artifacts
    
    By default, the Lintian task creates an analysis artifact for each of
    source, binary-all, and binary-any; the binary-all and binary-any
    artifacts can be effectively empty if there are no binary packages of
    the corresponding type.
    
    I think reducing Lintian artifacts to the shortest-length package name
    they contain for the purposes of generating labels is a bit _too_
    abbreviated and quite confusing, so I reworked this to include all the
    package names in sorted order, as well as handling the empty case.
    
    Fixes: #677

commit ac4792423975589beaf8a8dd13e90f0a4b6159fc
Author: Colin Watson <cjwatson@debian.org>
Date:   Mon Jan 13 12:04:56 2025 +0000

    Introduce MultipleArtifactInfo
    
    This gives us somewhere to put helper methods.

commit b62a57e98f16b5d9084aa1325bcdffc276b733fd
Author: Colin Watson <cjwatson@debian.org>
Date:   Mon Jan 13 10:58:34 2025 +0000

    Expand TaskDatabase docstrings

commit 64a6afe744ce9cca958bf22682fc920ed53e37ce
Author: Colin Watson <cjwatson@debian.org>
Date:   Sun Jan 12 17:52:44 2025 +0000

    Extend TaskDatabaseInterface to include artifact category and data
    
    This will allow tasks to include more useful information in dynamic data
    that they can't do using only artifact IDs.
    
    Doing this does mean that artifact data is now validated in more places,
    so it's possible for this to result in new failures for old artifacts.
    In practice this should mostly affect tests (and indeed I had to fix
    several of those) since production code normally already goes through
    some kind of validation of artifact data; if we encounter failures on
    production then we can decide whether to fix artifacts or relax
    validation.
    
    Part of #510.