Comment 3 for bug 1885164

The limit is 3 hours now rather than 2, but it sounds like that still isn't enough for everything.

The timeout is an anti-abuse mechanism, so I'm not comfortable with continuing to raise it arbitrarily across the board. I think we're going to have to come up with a way to set this on a per-snap-recipe basis (which won't help "snapcraft remote-build", but it will at least allow us to configure this for persistent snap recipes).

Unfortunately this is complicated somewhat by the design of rutabaga (the component which issues authentication tokens for the builder proxy and tracks their validity): rather than setting the expiry when issuing a token, it computes it based on the issuing time when checking whether the token is still valid. This design can only cope with a single lifetime for all tokens, and will need a schema change to be more flexible. However, rutabaga's database has never had a schema change and in fact has no infrastructure for making them, so we're going to have to fix that first. (Maybe we should convert it from SQLite to PostgreSQL while we're there, since we're a lot more used to managing PostgreSQL instances; that would allow us to deploy multiple rutabaga units and so remove a single point of failure.)

Once rutabaga can take an expiry time when issuing a token, it's fairly easy to add a column to the `Snap` table in Launchpad, editable by admins, to let us configure this differently for different snap recipes. But it's going to take a little while to get to that point!