Возможно Yocto PREMIRROR / SOURCE_MIRROR_URL с аргументами url (SAS_TOKEN)?

#embedded-linux #yocto #azure-blob-storage #bitbake

#встроенный-linux #yocto #azure-blob-хранилище #bitbake

Вопрос:

Я успешно создал premirror для наших сборок yocto на большом двоичном объекте хранилища Azure, который работает, если я установил уровень доступа на «Большой двоичный объект (анонимное чтение) ..»

Теперь я хотел сохранить большой двоичный объект полностью закрытым и получить доступ только через токены SAS.

 SAS_TOKEN = "?sv=2019-12-12amp;ss=bfamp;srt=coamp;sp=rdlamp;se=2020-08-19T17:38:27Zamp;st=2020-08-19T09:38:27Zamp;spr=httpsamp;sig=abcdef_TEST"

INHERIT  = "own-mirrors"
SOURCE_MIRROR_URL = "https://somewhere.blob.core.windows.net/our-mirror/downloads/BASENAME${SAS_TOKEN}"

BB_FETCH_PREMIRRORONLY = "1"
  

В целом это работает, но yocto (или, если быть точным, модуль выборки bitbake) попытается затем выполнить выборку из https://somewhere.blob.core.windows.net/our-mirror/downloads/bash-5.0.tar.gz?sv=2019-12-12&ss=bf&srt=co&sp=rdl&se=2020-08-19T17:38:27Z&st=2020-08-19T09:38:27Z&spr=https&sig=abcdef_TEST/bash-5.0.tar.gz

Который также кодирует специальные символы для параметров и, конечно, завершается ошибкой выборки. Кто-нибудь уже решил эту или подобные проблемы?

Или возможно ли исправлять файлы внутри слоя poky (а именно в ./layers/poky/bitbake/lib/bb/fetch2 ) без их изменения, чтобы я мог запустить там свою encodeurl функцию включения?

Комментарии:

1. В наших пакетных сборках CI yocto на Azure решением было использовать хранилище больших двоичных объектов в качестве конфигурации монтирования, при этом SOURCE_MIRROR_URL может быть что-то вроде file://${AZ_BATCH_NODE_MOUNTS_DIR}/premirror