juergbi commented on code in PR #1890:
URL: https://github.com/apache/buildstream/pull/1890#discussion_r1526119859
##########
tests/frontend/mirror.py:
##########
@@ -807,3 +807,93 @@ def test_mirror_expand_project_and_toplevel_root(cli,
tmpdir):
# Success if the expanded %{project-root} is found
assert foo_str in contents
assert bar_str in contents
+
+
+# Test a simple SourceMirror implementation which reads
+# plugin configuration and behaves in the same way as default
+# mirrors but using data in the plugin configuration instead.
+#
[email protected](DATA_DIR)
[email protected]("datafiles")
+def test_source_mirror_plugin(cli, tmpdir):
+ output_file = os.path.join(str(tmpdir), "output.txt")
+ project_dir = str(tmpdir)
+ element_dir = os.path.join(project_dir, "elements")
+ os.makedirs(element_dir, exist_ok=True)
+ element_name = "test.bst"
+ element_path = os.path.join(element_dir, element_name)
+ element = generate_element(output_file)
+ _yaml.roundtrip_dump(element, element_path)
+
+ project_file = os.path.join(project_dir, "project.conf")
+ project = {
+ "name": "test",
+ "min-version": "2.0",
+ "element-path": "elements",
+ "aliases": {
+ "foo": "FOO/",
+ "bar": "BAR/",
+ },
+ "mirrors": [
+ {
+ "name": "middle-earth",
+ "kind": "mirror",
+ "aliases": {
+ "foo": ["<invalid>"],
Review Comment:
For mirror plugins where a single string is sufficient for per-alias
configuration, the plugin wouldn't need to define its own `aliases` dict in its
`config` section and could use meaningful values in the main `aliases` dict
instead of "\<invalid>". E.g., the test plugin also works with the following
changes: https://gist.github.com/juergbi/1c57fc0a5c0d512ef7f51654f0f0b26d (I
understand that the current test is better for validation purposes, this is
just for illustration).
I assume that potential future support for mirror plugins without specifying
aliases will anyway require opt-in from the plugin. Do you think it won't be
possible to extend the proposed plugin mirror API to allow opt-in of such a
feature? Or was your concern only the need for "\<invalid>" values, which I've
addressed in the first paragraph?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]