Add build info by hanzei · Pull Request #598 · mattermost/mattermost-plugin-github

hanzei · 2022-11-02T09:01:25Z

Summary

Make use of mattermost/mattermost-plugin-api#121.

Ticket Link

None

hanzei · 2022-11-02T09:02:35Z

    "icon_path": "assets/icon.svg",
    "version": "2.1.2",
-    "min_server_version": "6.5.0",
+    "min_server_version": "7.5.0",


On older versions, the plugin does fail to start due to mattermost/mattermost#21560.

@hanzei How does that make it fail to start? Can we instead set the OwnerId in this plugin? I don't like the situation that puts the plugin in, but it's backwards compatible and forwards compatible. The newer server will ignore any value passed in as expected, so it's not affected there.

Can we instead set the OwnerId in this plugin?

Yes, we can do that, but I'm hesitant to tinker around with "manual" changes like that. The API already set the OwnderId.

Do you mind the updated min_server_version?

Do you mind the updated min_server_version?

Yes, I would very much prefer keeping the server version lower. Having it this high will make it difficult to deliver bug fixes to (even slightly) older server versions. Any way around bumping the server version?

Sure, added a workaround with 470cb0f.

The packages that are commonly imported by plugins are model and plugin. Surely, we could release a separate modules file, but why?

This would also help with potential dependency bloat and dependency version management issues on the plugin project side.

I don't get that point. What bloat do you refer to? Currently, plugins import a single dependency: github.com/mattermost/mattermost-server/v6. What other issues are you referring to?

How much value are we gaining from these updates that require the newer server versions?

It's a necessity to continue using the pluginapi package. By it's nature, it stays up to date relatively well with the MM server. And plugins just have to follow the imported server version.

Ideally we would have an ESR process that spans out dot releases into older server versions, but we don't have that at the moment.

What is missing here in terms of process? If we found an bug as significant, that we would backport it to ESR, we can release of the latest release that is compatible with ESR.

What is missing here in terms of process? If we found an bug as significant, that we would backport it to ESR, we can release of the latest release that is compatible with ESR.

I meant having a separate ESR for plugin projects, but that would likely be too much overhead for the benefit it would bring. We do our best to deliver dot releases, but we don't necessarily take into account delivering those fixes to an older version of a plugin that has less minimum server version requirements.

I don't get that point. What bloat do you refer to? Currently, plugins import a single dependency: github.com/mattermost/mattermost-server/v6. What other issues are you referring to?

I meant the dependencies added to go.sum. Do these contribute to the bundle size of the plugin?

I meant the dependencies added to go.sum. Do these contribute to the bundle size of the plugin?

No, they don't. Only direct and indirect - i.e. transitive - dependencies increase the bundle size. E.g. github.com/mattermost/mattermost-server/v6/model imports github.com/mattermost/mattermost-server/v6/shared/ so that package also gets compiled. github.com/francoispqt/gojay is another example of a package that model imports. Packages that are not direct or indirect imports do not contribute to the bundle site. github.com/mattermost/morph gets imported by github.com/mattermost/mattermost-server/v6/store/sqlstore and is part of go.sum because the package github.com/mattermost/mattermost-server/v6/ includes it in it's go.mod. But it does not contribute to the bundle size as it's not an import.

If one wants to dig deeper: nm can be used to get the list of symbols from an object file, e.g. nm server/dist/plugin-linux-arm64. That list contains all the symbols that contribute to the bundle size. If we want to improve the bundle size, we need to find imports that could be avoided if packaged in a different way. github.com/mattermost/mattermost-server/v6/model imports github.com/mattermost/mattermost-server/v6/shared/markdown only to use it in RewriteImageURLs. Maybe RewriteImageURLs could be moved in github.com/mattermost/mattermost-server/v6/shared/markdown and the import could be avoided.

But these are small optimisation. In general, the compiler is smarter than the programmer 😉

codecov-commenter · 2022-11-02T09:08:27Z

Codecov Report

Base: 15.67% // Head: 15.63% // Decreases project coverage by -0.04% ⚠️

Coverage data is based on head (bee4b04) compared to base (79e2b7a).
Patch coverage: 0.00% of modified lines in pull request are covered.

❗ Current head bee4b04 differs from pull request most recent head 41e221d. Consider uploading reports for the commit 41e221d to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #598      +/-   ##
==========================================
- Coverage   15.67%   15.63%   -0.05%     
==========================================
  Files          15       15              
  Lines        5231     5245      +14     
==========================================
  Hits          820      820              
- Misses       4368     4382      +14     
  Partials       43       43

Impacted Files	Coverage Δ
server/plugin/command.go	`8.15% <0.00%> (-0.17%)`	⬇️
server/plugin/plugin.go	`3.69% <0.00%> (-0.01%)`	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

javaguirre

LGTM!

hanzei · 2022-12-08T16:08:59Z

@mickmister This PR is ready for another review

mickmister · 2022-12-08T16:36:44Z

+		return &model.CommandResponse{}, nil
+	}
+
+	if action == "about" {


We usually name this command info like /github info. I'm thinking we should be consistent and continue to use this pattern cc @levb

I went back and forth and ended with about as that is a common term used in software to show build information.

Since info is already used in other plugin projects, and has been used as a tool with the support team to gather information plugin installations, 2/5 I'm thinking we should use info here

has been used as a tool with the support team to gather information plugin installations,

The only plugin used in production that uses an info command is Jira, right? Even that command works slightly differently. I would like for the about command to not include any confidential information, so it can be used for debugging without manual cleanup.

@mickmister What do you think about my comment?

spirosoik · 2023-01-10T09:31:06Z

/update-branch

hanzei added 2 commits November 2, 2022 09:59

Add build info

21484ca

Update min_server_version

be0661e

hanzei added the 2: Dev Review Requires review by a core committer label Nov 2, 2022

hanzei requested review from javaguirre and mickmister November 2, 2022 09:01

hanzei commented Nov 2, 2022

View reviewed changes

javaguirre approved these changes Nov 2, 2022

View reviewed changes

Update version

e755171

hanzei added this to the v2.2.0 milestone Nov 14, 2022

hanzei added 4 commits December 7, 2022 21:33

Support older plugin version

470cb0f

Update to github.com/mattermost/mattermost-server/v6@v7.5.0

c74e1ac

Bump min server version to 7.1

8152503

Update list of available commands and ordering

4e850b8

mickmister reviewed Dec 8, 2022

View reviewed changes

trigger CI

a9b2065

Merge branch 'master' into build-info

bee4b04

hanzei requested a review from mickmister January 12, 2023 10:05

Empty commit to trigger CI

41e221d

mickmister approved these changes Feb 8, 2023

View reviewed changes

hanzei added 4: Reviews Complete All reviewers have approved the pull request and removed 2: Dev Review Requires review by a core committer labels Feb 17, 2023

hanzei merged commit 9d6cb4b into master Feb 17, 2023

hanzei deleted the build-info branch February 17, 2023 06:37

This was referenced Feb 17, 2023

Add build info mattermost/mattermost-plugin-gitlab#362

Merged

Add built info via /jira about mattermost/mattermost-plugin-jira#916

Merged

mickmister mentioned this pull request Mar 20, 2023

Release bump v2.2.0 #583

Closed

mickmister mentioned this pull request Sep 15, 2023

Mattermost Github Plugin will not start #698

Closed

avas27JTG mentioned this pull request Nov 9, 2023

Bump version to 2.2.0. #709

Merged

Uh oh!

Conversation

hanzei commented Nov 2, 2022

Summary

Ticket Link

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mickmister Dec 9, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codecov-commenter commented Nov 2, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

javaguirre left a comment

Choose a reason for hiding this comment

Uh oh!

hanzei commented Dec 8, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spirosoik commented Jan 10, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

mickmister Dec 9, 2022 •

edited

Loading

codecov-commenter commented Nov 2, 2022 •

edited

Loading