-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement publishing workflow for standalone plugins that aren't modules #935
Comments
@joemcgill @swissspidy @westonruter (cc. @felixarntz when you're back), While working on the issue, I noticed that we missed specifying the version for plugins in #934. The issue requirements state that "plugins should have an array of plugin slugs," but we didn't mention the version for the plugins. When updating the So, we must add the version for plugins as well. Could we use the same data structure as we use for
Could you please review and share your thoughts so I can adjust the code and raise a PR for this issue? |
Sure yeah submit a PR 👍 |
I think this is only necessary if we're planning on having the deployment process be responsible for handling version bumps for standalone plugins like we're currently doing for modules. The assumptions for this task were that we would not need a build process for deploying plugins, so we may need to modify the deployment script for standalone plugins instead. |
@thelovekesh great point. We should probably prioritize merging #1011 first some can simplify things by eliminating the logic for modules entirely. |
@mukeshpanchal27 Replying to your question in #935 (comment), the reason this was defined as a list of plugin slugs is that the plugins would already be built, as @joemcgill mentioned. That means they already include their version in the plugin and readme headers. Therefore to avoid (even more) duplication of the version number, I think it would be simpler to extract the version from the plugin or readme file rather than having to put it into |
@thelovekesh Regarding your question in #935 (comment), this depends on whether we want to retain the ability to publish new features as modules first before publishing them as plugins or whether we're confident/comfortable with always publishing new features as plugins right away. Additional discussion is required to make a decision on that question, so let's not change this yet until such a decision has been made. cc @westonruter |
Fixed via #1000 🎉 |
This issue is part 2/2 for setting up the new infrastructure for developing standalone plugins.
Requirements
This work should be implemented against a new
feature/modules-to-plugins
feature branch.After #934 has been completed:
php-test-standalone-plugins.yml
anddeploy-standalone-plugins.yml
workflows should be enhanced to also cover plugins found in theplugins
directory (additionally to plugins in themodules
directory, which need to be built first).plugins
folder can be assumed to truly be plugins (not modules). So they don't require a build process (at least not for now).build
, while plugins can be deployed directly from their folder withinplugins
.plugins.json
.npm run test-plugins
command will likely need to be expanded to also cover plugins in theplugins
folder (but only those that are inplugins.json
).The text was updated successfully, but these errors were encountered: