-
Notifications
You must be signed in to change notification settings - Fork 7.2k
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
[MM-17889] Implement validation of plugin API version comments #11941
[MM-17889] Implement validation of plugin API version comments #11941
Conversation
I am wondering about where to invoke this check from. Should it be part of the Another thought I had was that this could be put into a unit test so that it simply runs as part of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is terrific work, @pbitty! And welcome to the community!
I've left some thoughts below, with one major piece of feedback to converge on fmt/lint output semantics. I recently stumbled across the ability to write custom analyzers for go vet
, and think this script could make a worthy candidate (eliminating the need to do the manual AST processing). It's not necessary to go down the go vet
path for this pull request, but I do think we should aim for similar output semantics.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job, @pbitty! I agree and have nothing to add to the feedback from @lieut-data. Please re-add me as a reviewer when it's implemented.
I also agree that adding it as a go vet stage is a great idea, so probably best as a standalone executable, invoked right next to go vet
in the Makefile, for now?
This reverts commit d4f893a.
@lieut-data @levb , thanks for the feedback and your kind words. I believe I have addressed your comments. I took a look at the custom analyzers article. I would be happy submit a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This... is... AMAZING. Thank you @pbitty! I love open-source :)
@levb @lieut-data, you are very welcome! I took a look at the approach for implementing it as an "Analyzer" using The only potential catch I found is that the This means the checker code would have no knowledge of the go run plugin/checker/main.go github.com/mattermost/mattermost-server/plugin To me this sounds reasonable and still worth implementing. What do you think? |
@pbitty: I agree with your analysis and recommendation. Are you still interested in running with this change? Would it make sense just to do it in this PR? |
@lieut-data I've just pushed the change. There are a couple of little hacks I had to narrow it down to the file set that contains the Looking at #11912, some of this code can probably be refactored to help there. I've also gone ahead and vendored in the new dependencies, following the example of other PRs. |
The tests seem to be failing because of a package that was removed by |
@lieut-data, I took the liberty to go with my suggestion above. Let me know what you think and I can change it as needed. |
👍 thanks for the tests! Looks like it's now failing on
and then failing to find packages. I am not up to speed as to |
Properly reporting a non-existent package seems to require some very specific error parsing. The `Load` method already returns a number of import errors because it cannot find all of the dependencies of the `plugin` package. This makes it difficult to discern between a "cannot find package" error and the ignorable import errors that are regularly returned. Setting up the `Load` method to find all dependencies and load the package without import errors is not required for our use-case. The ability to report a build-stage error that is very rare and easy enough to troubleshoot, does not seem to warrant the added complexity that it would require.
@lieut-data , the tests have been consistently failing at this test:
The test seems to be failing because I introduced the |
… GH-11910_enforce_version_comments
I did a bit more digging and discovered that the output of You can reproduce it without running all the test with this command:
Pending a deeper fix, I think simply changing the key to something else should be enough for this PR. Let me know if you agree. |
@pbitty, sorry for the delay in responding -- I'm currently out-of-office running a team meetup and have been slow to respond. Winding the stack backwards, I think renaming the package to workaround the clash is fine. Thanks for digging into this! On the Let me know if you think we're good, and I'll go ahead and merge this :) |
@lieut-data , no problem at all. I think it's good to merge. Before your reply, I had already renamed the key in the |
Excellent! Looks good from my perspective -- @prapti, when you have a chance, can you give us guidance on whether we test before or after merging this feature? |
… GH-11910_enforce_version_comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR will be tested post merge.
Approving.
Removing QA Review label
Thank you very much for this awesome PR @pbitty 🕺 |
Test server destroyed |
This is to resolve issue #11910. All feedback is welcome.
MM-17889