PyBOMBS (Python Build Overlay Managed Bundle System) is the GNU Radio install management system for resolving dependencies and pulling in out-of-tree projects.
GitLab has the concept of deploy tokens which are essentially limited-scope credentials for very specific actions such as read-only pulling a repository.
I have a few custom recipes in a protected GitLab repository, and created a "read_repository" deploy token for it. URLs using deploy tokens take the form https://<username>:<deploytoken>@server/repo.git. While this is a fairly standard URL format, pybombs recipes add <recipe-alias> https://<username>:<deploytoken>@server/repo.git fails with
fatal: unable to access 'https://<username>:<deploytoken>/': URL using bad/illegal format or missing URL
error: Could not fetch <recipe-alias>
I know that the access token works because a simple git clone https://<username>:<deploytoken>@server/repo.git works just fine.
The incorrect way the URL is broken down suggests that the root cause is somewhere in the URL parsing/preprocessing, but I have not investigated it yet.
I realize this is a strange edge case with low priority but I think this should be fixed to facilitate private recipe repos.
Full trace:
root@0d91f141555f:/# pybombs recipes add recipe-alias https://tokenname:token@myserver.tld/myrepo.git
[INFO] Prefix Python version is: 3.8.5
[INFO] PyBOMBS Version 2.3.4
fatal: unable to access 'https://tokenname:token/': URL using bad/illegal format or missing URL
error: Could not fetch snout-recipes
Traceback (most recent call last):
File "/usr/local/bin/pybombs", line 8, in <module>
sys.exit(main())
File "/usr/local/lib/python3.8/dist-packages/pybombs/main.py", line 32, in main
return dispatch() or 0
File "/usr/local/lib/python3.8/dist-packages/pybombs/commands/base.py", line 195, in dispatch
return get_cmd_dict(cmd_list)[args.command](cmd=args.command, args=args).run()
File "/usr/local/lib/python3.8/dist-packages/pybombs/commands/base.py", line 120, in run
return self.subcommands[self.args.sub_command]['run'](self)()
File "/usr/local/lib/python3.8/dist-packages/pybombs/commands/recipes.py", line 172, in run_add
if not self.add_recipe_dir(alias, uri):
File "/usr/local/lib/python3.8/dist-packages/pybombs/commands/recipes.py", line 347, in add_recipe_dir
Fetcher().fetch_url(uri, recipe_cache_top_level, alias, {}) # No args
File "/usr/local/lib/python3.8/dist-packages/pybombs/fetcher.py", line 73, in fetch_url
result = fetcher.fetch_url(url, dest, dirname, args)
File "/usr/local/lib/python3.8/dist-packages/pybombs/fetchers/git.py", line 92, in fetch_url
gcm.add_remote(dirname, url, True)
File "/usr/local/lib/python3.8/dist-packages/pybombs/gitcache_manager.py", line 80, in add_remote
self.run_git_command(['remote', 'update', name])
File "/usr/local/lib/python3.8/dist-packages/pybombs/gitcache_manager.py", line 43, in run_git_command
output = subproc.check_output(git_cmd)
File "/usr/local/lib/python3.8/dist-packages/pybombs/utils/subproc.py", line 50, in check_output
return subprocess.check_output(*args, **kwargs).decode('utf-8')
File "/usr/lib/python3.8/subprocess.py", line 411, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/lib/python3.8/subprocess.py", line 512, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['git', 'remote', 'update', 'snout-recipes']' returned non-zero exit status 1.
GitLab has the concept of deploy tokens which are essentially limited-scope credentials for very specific actions such as read-only pulling a repository.
I have a few custom recipes in a protected GitLab repository, and created a "read_repository" deploy token for it. URLs using deploy tokens take the form
https://<username>:<deploytoken>@server/repo.git
. While this is a fairly standard URL format,pybombs recipes add <recipe-alias> https://<username>:<deploytoken>@server/repo.git
fails withI know that the access token works because a simple
git clone https://<username>:<deploytoken>@server/repo.git
works just fine. The incorrect way the URL is broken down suggests that the root cause is somewhere in the URL parsing/preprocessing, but I have not investigated it yet.I realize this is a strange edge case with low priority but I think this should be fixed to facilitate private recipe repos.
Full trace: