Replies: 6 comments 10 replies
-
I understand that all current plugins don't have a prefix right now, but I have the impression that would be nice to have a prefix/suffix on the repositories names so we can easily distinguish what are plugins and what are misc repositories (i.e:
Besides a better organization, another advantage of this split is to keep Avocado main repository as clean as possible, including dependencies. So if some would like to try a basic Avocado without additional plugins, the installation process would be easier. Dependencies for the plugin would be on the plugin repository (as you did with jinja2). Because of that, IMO we should try to follow this rule not only for users, during the installation process, but also for development. If I'm hacking Avocado, Would be nice if wouldn't need to install dependencies from all plugins. However, it is still important to know if I'm breaking the compatibility with those plugins, during CI stages. I remember discussing with @clebergnu something like this: https://blog.marcnuri.com/triggering-github-actions-across-different-repositories/ What do you think about this approach? |
Beta Was this translation helpful? Give feedback.
-
In the meantime, I have started working in the first option and improving checks.py to exclude plugins, see #4761 |
Beta Was this translation helpful? Give feedback.
-
A summary of what I remember from our live discussion today. I'm ignoring all the part related the internal CI pipelines - because GitHub Actions are very flexible and will allow a lot of options. Discussed possibilitiesSplit every plugin in their own repository (avocado-plugin-foo), with their own separate RPM source package.Pros:
Cons:
Split every plugin in their own repository (avocado-plugin-foo), all plugins are packaged together in the same source package.Similar to the previous option but packaging is relatively easier: all the plugins are released together with the same version number. Split all the plugins in the same repository (avocado-optional-plugins) and package all the plugins from the same source package.Pros:
Cons:
Not splitting them.Pros:
Cons:
(Biased) Big picture summarySplitting the plugins won't have any advantage for users of the packages. Rather, they'll sometimes find themselves having to check if avocado-plugin-foo version 0.90 is compatible with avocado version 0.95. For users of git/pip, we can invest the time in making the current process easier and handle dependencies better. This still would be less of the time we'd need to invest to split the plugins out and further time invested in release work. |
Beta Was this translation helpful? Give feedback.
-
I'll look into the Avocado utils split then. Will open another discussion when I have some plan to share! |
Beta Was this translation helpful? Give feedback.
-
A new idea appeared while discussing with @beraldoleal. This would be removing entirely the concept of optional plugins and making plugins either a core plugin or an extra plugin. In practice, this would mean:
If any of the extra plugins ends up having very big requirements (such as a database) then yes, it's the time to split it. Please, beraldo, leave a comment if I remember this wrong. |
Beta Was this translation helpful? Give feedback.
-
This PR #4941 contains important context about the tests of the plugins and what steps would need to be done in case of a split. |
Beta Was this translation helpful? Give feedback.
-
After reading previous PR/issues, I have made a first approach for splitting the plugins. Starting only with the HTML plugin, I split out the plugin in this (test) repository: https://github.com/avocado-framework/avocado-result-html
(Please, take a quick look because we need to agree on the name of the tags and branches)
I made a first PR/commit with the github actions. You can see the result at https://github.com/avocado-framework/avocado-result-html/actions/runs/987162409
There are only GitHub Actions, do we need to add more? It won't be so easy to combine the two repositories with Travis or Cirrus.
Finally, what is still missing is the spec file for packaging the plugin independently. More about this below.
With respect the avocado repository, I made a draft PR at #4755
In this draft PR, I removed the plugin, update GHA, cirrus and travis. I tried updating the packaging part but that proved tricky. After removing all the packaging bits of the HTML plugin, there are still the checks that are hard to avoid. I added
--disable-plugin-checks=html
but it doesn't work as it does with the robot plugin.I don't know what's the best option now:
Comments welcome!
References: #4389 #4608
Beta Was this translation helpful? Give feedback.
All reactions