aptly publish API concurrency

26 views
Skip to first unread message

Stefan E. Funk

unread,
Nov 24, 2022, 12:04:52 PM11/24/22
to aptly-discuss
Hi @all!

Nice to be a member now :-)

I did not find any hint on this on doc and on this list, so my question is the following:

We are building four DEB packages and then upload and publish them simultaneously in one Gitlab CI stage (deploy) to our aptly service using the aptly file and publish API with different filenames and different pathes:

  1. curl -X POST --header "Content-Type:multipart/form-data" -F file=@./tgcrud-webapp/target/tgcrud-webapp_11.7.4~20221124172753_all.deb https://ci.de.dariah.eu/aptlyAPI/files/tgcrud-webapp-11.7.4-SNAPSHOT.deb
  2. curl -X POST https://ci.de.dariah.eu/aptlyAPI/repos/indy-snapshots/file/tgcrud-webapp-11.7.4-SNAPSHOT.deb
  3. curl -X PUT -H "Content-Type:application/json" --data "{}" https://ci.de.dariah.eu/aptlyAPI/publish/:./indy

The publish call is not working out in most of the cases, and fails with something like:

{"error":"unable to update: unable to rename: rename /mnt/nfs/aptly2/.aptly/public/dists/indy/releases/Contents-i386.tmp.gz /mnt/nfs/aptly2/.aptly/public/dists/indy/releases/Contents-i386.gz: no such file or directory"}
or
{"error":"unable to update: unable to rename: rename /mnt/nfs/aptly2/.aptly/public/dists/indy/snapshots/binary-amd64/Release.tmp /mnt/nfs/aptly2/.aptly/public/dists/indy/snapshots/binary-amd64/Release: no such file or directory"}
or
{"error":"unable to update: unable to rename: rename /mnt/nfs/aptly2/.aptly/public/dists/indy/snapshots/binary-amd64/Packages.tmp /mnt/nfs/aptly2/.aptly/public/dists/indy/snapshots/binary-amd64/Packages: no such file or directory"}

(You can find our pipeline here…)

I suppose the problem is, that the publish call can not be assigned to ONE package, and publish always publishes (or tries to) everything contained in the upload folder, ready uploaded or not.

Is there a solution for this? How is it supposed to work? Putting the publish call in a next CI stage would of course work, at least for one project. But we deploy more projects at a time sometimes, so that would not be a good solution.

Thanks a lot for every insight and hint on this and all the best!
––Stefan
Reply all
Reply to author
Forward
0 new messages