How to publish to specific local endpoint ?
EvoXCX opened this issue · 4 comments
Hello,
I need to setup some repositories, but for some reason I need to publish by example docker mirrors, like this:
aptly publish -gpg-key="<GPG_KEY_IDENTIFIER>" snapshot docker-bookworm-<date> docker/bookworm
aptly publish -gpg-key="<GPG_KEY_IDENTIFIER>" snapshot docker-bullseye-<date> docker/bullseye
Note
Because component stable is in snapshots docker-bookworm
and docker-bullseye
, is it considered as duplicate for some packages identically. (Idk why)
There is no documentation for the project or to be more precise since docs.adfinis-sygroup.ch stopped, probably.
Can you port documentation on Github ?
Or please, can you help me to configure the local publish endpoint ?
[publish]
# Bookworm
[[publish.bookworm-main]]
gpg-key = "<GPG_KEY>"
skip-contents = true
automatic-update = true
components = "main"
distribution = "bookworm"
[[publish.bookworm.snapshots]]
name = "bookworm-main-%T"
timestamp = "current"
archive-on-update = "archived-bookworm-main-%T"
[[publish.bookworm-updates]]
gpg-key = "<GPG_KEY>"
automatic-update = true
components = "main"
distribution = "bookworm-updates"
[[publish.bookworm-updates.snapshots]]
name = "bookworm-updates-%T"
timestamp = "current"
archive-on-update = "archived-bookworm-updates-%T"
[[publish.bookworm-security]]
gpg-key = "<GPG_KEY>"
automatic-update = true
components = "main"
distribution = "bookworm-security"
[[publish.bookworm-security.snapshots]]
name = "bookworm-security-%T"
timestamp = "current"
archive-on-update = "archived-bookworm-security-%T"
[[publish.docker-bookworm]]
gpg-key = "<GPG_KEY>"
automatic-update = true
components = "stable"
distribution = "bookworm"
[[publish.docker-bookworm.snapshots]]
name = "docker-bookworm-%T"
timestamp = "current"
archive-on-update = "archived-docker-bookworm-%T"
[[publish.php-bookworm]]
gpg-key = "<GPG_KEY>"
automatic-update = true
components = "main"
distribution = "bookworm"
[[publish.php-bookworm.snapshots]]
name = "php-bookworm-%T"
timestamp = "current"
archive-on-update = "archived-php-bookworm-%T"
[[publish.postgres-bookworm]]
gpg-key = "<GPG_KEY>"
automatic-update = true
components = "main"
distribution = "bookworm-pgdg"
[[publish.postgres-bookworm.snapshots]]
name = "postgres-bookworm-%T"
timestamp = "current"
archive-on-update = "archived-postgres-bookworm-%T"
# Bullseye
[[publish.bullseye-main]]
gpg-key = "<GPG_KEY>"
skip-contents = true
automatic-update = true
components = "main"
distribution = "bullseye"
[[publish.bullseye.snapshots]]
name = "bullseye-main-%T"
timestamp = "current"
archive-on-update = "archived-bullseye-main-%T"
[[publish.bullseye-updates]]
gpg-key = "<GPG_KEY>"
automatic-update = true
components = "main"
distribution = "bullseye-updates"
[[publish.bullseye-updates.snapshots]]
name = "bullseye-updates-%T"
timestamp = "current"
archive-on-update = "archived-bullseye-updates-%T"
[[publish.bullseye-security]]
gpg-key = "<GPG_KEY>"
automatic-update = true
components = "main"
distribution = "bullseye-security"
[[publish.bullseye-security.snapshots]]
name = "bullseye-security-%T"
timestamp = "current"
archive-on-update = "archived-bullseye-security-%T"
[[publish.docker-bullseye]]
gpg-key = "<GPG_KEY>"
automatic-update = true
components = "stable"
distribution = "bullseye"
[[publish.docker-bullseye.snapshots]]
name = "docker-bullseye-%T"
timestamp = "current"
archive-on-update = "archived-docker-bullseye-%T"
[[publish.php-bullseye]]
gpg-key = "<GPG_KEY>"
automatic-update = true
components = "main"
distribution = "bullseye"
[[publish.php-bullseye.snapshots]]
name = "php-bullseye-%T"
timestamp = "current"
archive-on-update = "archived-php-bullseye-%T"
[[publish.postgres-bullseye]]
gpg-key = "<GPG_KEY>"
automatic-update = true
components = "main"
distribution = "bullseye-pgdg"
[[publish.postgres-bullseye.snapshots]]
name = "postgres-bullseye-%T"
timestamp = "current"
archive-on-update = "archived-postgres-bullseye-%T"
We're still in a "rebuild" phase (the project was mostly abandoned for the last few years) and documentation is therefore yet to come.
(For context and future reference: You would find the docs in the code as it was/will be mostly a generated documentation but it's not very trivially understandable right now. I opened up a PR to add a Tutorial (current version), but from your configuration example it seems like you already understand it.)
What you probably want is something along the following:
[[publish."docker/bookworm"]]
gpg-key = "<GPG_KEY>"
skip-contents = true
automatic-update = true
components = "main"
distribution = "bookworm"
[[publish."docker/bookworm".snapshots]]
name = "bookworm-main-%T"
timestamp = "current"
archive-on-update = "archived-bookworm-main-%T"
From what I've seen in the codebase (still getting into it) pyaptly doesn't understand/differentiate endpoint/prefix. It just handles it as a string.
EDIT: It might be helpful - when snapshots, etc. are already there - to run pyaptly publish config.toml create --info --pretend
. This will show you the exact pyaptly commands that would be run without actually running them (but be aware that --pretend
currently doesn't work with mirror updates).
Hello @Melkor333,
Thanks for your quick response :)
Maybe adding endpoint =
option in future release can help to better understand this.
Have a good day !
@EvoXCX @Melkor333 I am really rusty with aptly, so I read the pyaptly code and we just statically put publish_name
into endpoints
. As long moving out endpoint
doesn't break the unique-constraint of publish_name
we can do that. If swift:myrepo
and s3:myrepo
can exist we have a problem with the config-structure. Since we can't have two keys called myrepo
. Maybe aptly doesn't support that either, so we have no problem. Otherwise the user has to resolve unique constraint by calling the repos: swift:swift-myrepo
and s3:s3-myrepo
. If I am saying something stupid, I currently can't even imagine how this non-local endpoints work.
Maybe good documentation would be better?
Actually I confused it. Simply speaking It's just a prefix containing a /
. The endpoint would be seperated by a :
!
Yeah therefore better documentation is the way to go! :)