Unite fork with base repo

[mu88]

This is more a general idea: since the forked repository matkoch/resharper-testlinker is already archived, it does not make a lot of sense to me to keep the fork and it's base repo longer separate. Instead, the fork should be the only source of truth - of course by honoring @matkoch for his tremendous work.

I therefore want to bring up the following idea:

• Talk to @matkoch whether his repo could be reactivated and updated with the newly created code of this repo. Maybe it's also worth to discuss whether taking the maintenance of the original repo is an option. @vladyslav-burylov I'm interested in supporting you with the plugin if that is an option for you.
• Rename this Plugin from Test Linker 2 to Test Linker. The normie Rider user does not care about the plugin's history. Therefore the suffix 2 just seems confusing and superfluous.

@matkoch, @vladyslav-burylov: what do you think about this?

[mu88]

@vladyslav-burylov any thoughts about this?

[vladyslav-burylov]

Hi @mu88, I am sorry for late response.

It all makes sense to me - initially I have renamed plugin just to make sure it’s clear that ownership has changed (which might be important for security-focused people). Today, it seems to be OK to use old name just because of timeline.

Also, I am still busy with personal arrangements and cannot commit for keeping plugin updated in advance/before official rider releases, thus your help will be really appreciated.

I will try to add you to maintainers of the code base/plugin releases a bit later to make sure you can update/release it without any approvals from my side.

Thanks - I am really glad to have your input on this!

[vladyslav-burylov]

Alright - @mu88 - I granted you management access to the repo (pls let me know if you don't have it), however it seems I cannot grant you access to JetBrains account - I don't see any option to share plugin with anybody else inside the management page. Nevertheless, I am OK to commit for updates uploading to jetBrains assuming there are binaries uploaded to this repo - it's much easier for me as I won't need to build anything myself.

Also - if you know how to share access to plugin management within JetBrains - pls let me know :)

[matkoch]

Quick info from my side, I also suggest keeping the released plugin separated because there's the situation of the former plugin being published by me (working at JetBrains), and some may not notice the transition. I'm happy to help whenever it's necessary though.

One more note: I'm still planning to bring this directly into ReSharper and Rider, but haven't got around since then. Last action I did in the plugin was switching the approach of finding linked tests, which turned out to perform worse than the original. Hence I stopped maintaining it.

[vladyslav-burylov]

@matkoch - got it, thanks! it would be really great to have it as part of original rider distribution - it really seems to be missing there :)

[mu88]

@vladyslav-burylov I'd really appreciate to support you in keeping this great plugin alive! Thank you for granting me access to the repo. Is there anything I should know about your habits of maintaining this repo? Any tasks/to-dos/nice-to-knows 🙃? As far as I understand, I can update the code whenever a new Rider-SDK gets published. Did you compile the binaries on your machine and created a GitHub release manually?

@matkoch Thank you for getting into this discussion! I can only agree with Vladyslav: it would be awesome if that could be an built-in feature of Rider. But I think, at the moment we are happy with all the work that you already did 👍🏻 Can you answer Vladyslav's question about sharing access to the plugin portal of JetBrains?

[vladyslav-burylov]

Hi @mu88 - don't worry and just go ahead and change something if you think it would be useful. As of build - yes, I building it locally, you may move it to GitHub actions if you wish. Local building is a sort of technical dept.

[mu88]

Hi @vladyslav-burylov - I've introduced two new GitHub Actions:

• CI.yml → will be triggered on every commit in master branch and builds the plugin.
• Release.yml → will be triggered on all tagged commits, builds the plugin and tries to publish it to the JetBrains Plugin Gallery. That frees you from all the hassle of manually uploading a new plugin version to JetBrains. To make this work, you would have to create a GitHub secret called JetBrainsPublishToken (see here) which contains your JetBrains API key.

Unfortunately. I cannot see the GitHub Actions 🤔 maybe you can give me access somewhere in the repo settings?

[vladyslav-burylov]

Hi @mu88 - thank you very much!

Although I don't have time to test it today, I have enabled actions and configured JETBRAINSPUBLISHTOKEN secret (it was made uppercase by GitHub automatically, not sure if it's case-sensitive).

Thanks!

p.s. I wish I can grant you access to repo settings, however it seems to be impossible. Hopefully, we'll be able to complete repo configuration which requires GitHub settings modification soon.

[mu88]

Hey @vladyslav-burylov 👋🏻

I made a couple of tests with the GitHub Actions (sorry if you got spammed!) and so far it looks pretty good.

A regular CI / non-release build works (see here).

A dummy release build seems to pull the publish token (see here). I didn't want to upload a version to JetBrains, therefore the build itself failed.
But I'm pretty confident that we're done for the moment. We can check the release pipeline hopefully quite soon when JetBrains releases the new version of Rider 🙏🏻

Regarding the repo settings: I've also checked the GitHub docs and I came to the same conclusion. To grant me access to the repo settings, we'd have to move the repo into a GitHub organization. At the moment, that seems a bit of overkill to me 🙂

If you agree with me that we're done for the moment, we could close this issue.

[vladyslav-burylov]

Great - thank you!

I’m cool to close this one and verify plugin publish / update name during the next Rider release.