publishRenameConcurrency (publish_rename_concurrency in YAML) sets how
many index files RenameFiles renames at once. It defaults to 4, the
value that was hard-coded, and 1 renames them one at a time. Values
below 1 are treated as 1, since a semaphore with no capacity would
never admit a rename.
The setting is global rather than per publishing endpoint because the
renames run against every storage backend, not only S3.
gpg_keys was missing from debian/aptly.conf, and the man page had no
entry for ppaBaseURL, enablePprofEndpoint or gpgKeys. The wording
follows the existing template comments where there is one.
debian/aptly.conf spelled dep_follow_all_variants as
dep_follow_allvariants and dep_verboseresolve as dep_verbose_resolve.
The YAML loader ignores unknown keys, so setting either to true in a
config written from this template had no effect.
Same reason as the JSON one: ConfigShowYAMLTest snapshots `aptly config
show` in YAML form. Checked all three gold files under t02_config this
time rather than the one CI named. CreateConfigTest_gold is a commented
template rather than struct output, so it is unaffected, and it passes.
ConfigShowTest snapshots the output of `aptly config show`, which now
carries acquireByHashAlgorithms with its default. The other three system
files mentioning "architectures" are inputs rather than expected output,
which is why only this one test failed.
* load data inside background tasks
Perform collection.LoadComplete inside maybeRunTaskInBackground
Have tasks use a fresh copy of taskCollectionFactory, taskCollection
* use uuids, since names can be renamed
* remove useless resource lock
Resource locks need to be before the background task. creating same publish endpoint at the same time is unlikely...
* load data inside background tasks
This fixes a flaw in async apis, which loaded the published repo from the DB and mutated it outside the task closure, before the task lock was acquired.
Perform collection.LoadComplete inside maybeRunTaskInBackground and have tasks use a fresh copy of taskCollectionFactory, taskCollection
* lock source repos/snapshots for publish operations
Concurrent tasks were not properly locking their resources, leading to inconsistent published indexes:
SourceLocalRepo: iterate published.Sources (component -> source UUID), look up each local repo via localRepoCollection.ByUUID and append string(repo.Key()) to resources
SourceSnapshot: iterate b.Snapshots,look up each snapshot via snapshotCollection.ByName and append string(snapshot.ResourceKey()) to resources.
* lock pool on non MultiDist publish
* revert mutex on LinkFromPool
* use uuids, since names can be renamed
* add test for MultiDist change
Both the external GPG signer (--faked-system-time) and internal Go
OpenPGP signer (signerConfig.Time) now honor SOURCE_DATE_EPOCH,
producing reproducible signatures alongside the plain Release file dates.
Adds system tests for both signer backends verifying byte-identical
Release, Release.gpg and InRelease across repeated publishes.
The signer tests (PublishRepo3[78]Test) are using an ed25519 key because
ed25519 signatures are deterministic by design. The Go openpgp library
uses a random nonce for DSA/ECDSA (see signature.go Sign calls using
config.Random() link below) so those signatures vary across runs
even with a fixed timestamp, making byte-identical verification impossible.
In addition to 49f342878a
Ref: https://github.com/aptly-dev/aptly/pull/1537
Ref: https://github.com/ProtonMail/go-crypto/blob/v1.4.0/openpgp/packet/signature.go#L945-L979
Hansjoerg Maurer
Rascalov
Martin Simon
André Roth
Luan Dang
James Munson
Eleni Michalaki
KereMath
Pierig Le Saux
Philip Cramer
Tim Foerster
tom
dependabot[bot]
Zhang Xiao