Launchpad itself

In charmed deployments configured with `set_role_after_connecting:
True`, we execute a `SET ROLE` command immediately after connecting to
the database. However, according to
https://www.postgresql.org/docs/10/sql-set.html which is referenced by
https://www.postgresql.org/docs/10/sql-set-role.html, the effects of the
`SET` command disappear if the transaction is rolled back. We must
therefore commit the transaction to ensure that the effects persist
until the end of the session.

I strongly suspect that this is why we've been seeing `buildd-manager`
sometimes running as the wrong database role: it's to be expected that
Launchpad code will roll back transactions sometimes, for example as
part of handling an exception, and if that happened to be one of the
first things that `buildd-manager` did then we'd see this effect.

539bd1d... by Colin Watson on 2023-08-04

charm: Fix final part name

Merged from https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/448498

a53ab5b... by Guruprasad on 2023-08-04

charm/launchpad-scripts-bzrsyncd: Add missing config to the celerybeat service

Merged from https://code.launchpad.net/~lgp171188/launchpad/+git/launchpad/+merge/448475

b78d4de... by Colin Watson on 2023-08-04

charm: Fix final part name

The example in
https://juju.is/docs/sdk/charmcraft-yaml#heading--the-reactive-plugin
calls the final (and in that case only) part "charm". I'd thought that
was just an example. However, as of
https://github.com/canonical/charmcraft/commit/35adadf42c625c5ee5ed6d611c9bdec10413ae59
in charmcraft 2.4.0, calling the final part anything else causes charms
to be misbuilt; they end up containing unmodified copies of the
top-level `actions.yaml`, `config.yaml`, and `metadata.yaml` files
rather than merging the information provided by each layer.

Launchpad itself

~pelpsi/launchpad:differentiate-git-push-message-if-mp-exists

Branch merges

Related source package recipes

Related snap packages

Related charm recipes

Branch information

Recent commits