Skip to content
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

Add lens:// protocol handling with a routing mechanism #1949

Merged
merged 40 commits into from
Feb 25, 2021

Conversation

Nokel81
Copy link
Collaborator

@Nokel81 Nokel81 commented Jan 12, 2021

Things that still need to be done:

  • Testing on linux
  • Testing on windows
  • Add markdown docs

Signed-off-by: Sebastian Malton [email protected]

fixes #1288

Copy link
Contributor

@jakolehm jakolehm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good already 👍 Could we add integration tests for protocol handler?

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Jan 14, 2021

I will write some integration tests.

@Nokel81 Nokel81 force-pushed the feature/protocol-handler branch from e601ffa to f663b82 Compare January 14, 2021 18:06
@stefcameron
Copy link
Contributor

Great to see this going in! @Nokel81 are there any changes from the original implementation?

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Jan 15, 2021

Great to see this going in! @Nokel81 are there any changes from the original implementation?

From a users perspective no. So your extension technically doesn't have to be even updated. However, from an implementation standpoint. This now supports handlers from both renderer and main. Our hackweek version only supported renderer handlers.

@stefcameron
Copy link
Contributor

Great to see this going in! @Nokel81 are there any changes from the original implementation?

From a users perspective no. So your extension technically doesn't have to be even updated. However, from an implementation standpoint. This now supports handlers from both renderer and main. Our hackweek version only supported renderer handlers.

That's cool! I remember you wanted to add support to main as well but didn't have time then. As far as the API goes, though, no changes?

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Jan 15, 2021

Great to see this going in! @Nokel81 are there any changes from the original implementation?

From a users perspective no. So your extension technically doesn't have to be even updated. However, from an implementation standpoint. This now supports handlers from both renderer and main. Our hackweek version only supported renderer handlers.

That's cool! I remember you wanted to add support to main as well but didn't have time then. As far as the API goes, though, no changes?

None, the method on LensRendererExtension (and LensMainExtension for that matter) is still onProtocolRequest.

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Jan 15, 2021

I even checked what your extension was expecting to make sure I didn't change anything 😉

@stefcameron
Copy link
Contributor

I even checked what your extension was expecting to make sure I didn't change anything ;)

Fantastic! Thanks for testing it out. 😄

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Jan 15, 2021

@nevalla any ideas about why the integration tests for mac and linux are not being reported as failing in the CI, even though if you look at the logs there are failed tests?

@jim-docker
Copy link
Contributor

@nevalla any ideas about why the integration tests for mac and linux are not being reported as failing in the CI, even though if you look at the logs there are failed tests?

For this PR the only failed test I see for windows and mac is the protocol app start test. There's no minikube set up on Windows or mac so those tests are skipped. Or do you see other failures for other builds?

@jim-docker
Copy link
Contributor

@nevalla any ideas about why the integration tests for mac and linux are not being reported as failing in the CI, even though if you look at the logs there are failed tests?

For this PR the only failed test I see for windows and mac is the protocol app start test. There's no minikube set up on Windows or mac so those tests are skipped. Or do you see other failures for other builds?

Oh, but the CI reports success. Ruh Roh.

@lensapp lensapp deleted a comment Jan 18, 2021
@nevalla
Copy link
Contributor

nevalla commented Jan 18, 2021

@nevalla any ideas about why the integration tests for mac and linux are not being reported as failing in the CI, even though if you look at the logs there are failed tests?

Yes those should have been reported as failed. Hard to say why it's not the case here, need to investigate further.

@nevalla
Copy link
Contributor

nevalla commented Jan 18, 2021

Okay...I think I got it. We are running git checkout as the last step and exit code of that command is returned:

 - bash: |
      rm -rf extensions/telemetry
      make integration-win
      git checkout extensions/telemetry
    displayName: Run integration tests

We might want to return the exit code from make integration-* command.

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Jan 18, 2021

Okay...I think I got it. We are running git checkout as the last step and exit code of that command is returned:

 - bash: |
      rm -rf extensions/telemetry
      make integration-win
      git checkout extensions/telemetry
    displayName: Run integration tests

We might want to return the exit code from make integration-* command.

Thanks will fix that.

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Jan 18, 2021

@stefcameron I didn't test your extension. I only made sure that the API was compatible.

@stefcameron
Copy link
Contributor

@stefcameron I didn't test your extension. I only made sure that the API was compatible.

Oh, thanks for clarifying that. I'll git it a try against this branch then to make sure it still works.

@jim-docker
Copy link
Contributor

jim-docker commented Jan 18, 2021

I think the protocol name shoud be something less generic than lens, like k8slens, since it is global (lens protocol could already be in use somewhere?)

@Nokel81
Copy link
Collaborator Author

Nokel81 commented Jan 18, 2021

I think the protocol name shoud be something less generic than lens, like k8slens, since it is global (lens protocol could already be in use somewhere?)

As seen on slack, it has been decided to keep it as lens

Signed-off-by: Sebastian Malton <[email protected]>
jim-docker
jim-docker previously approved these changes Feb 4, 2021
jakolehm
jakolehm previously approved these changes Feb 8, 2021
jim-docker
jim-docker previously approved these changes Feb 8, 2021
@Nokel81 Nokel81 dismissed stale reviews from jim-docker and jakolehm via 42928a8 February 9, 2021 16:09
Sebastian Malton and others added 6 commits February 9, 2021 11:12
@Nokel81 Nokel81 force-pushed the feature/protocol-handler branch from a77c07b to 270d0f7 Compare February 10, 2021 18:51
@@ -26,7 +27,7 @@ function handleAutoUpdateBackChannel(event: Electron.IpcMainEvent, ...[arg]: Upd
* starts the automatic update checking
* @param interval milliseconds between interval to check on, defaults to 24h
*/
export function startUpdateChecking(interval = 1000 * 60 * 60 * 24): void {
export const startUpdateChecking = once(function (interval = 1000 * 60 * 60 * 24): void {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this fix an unrelated issue? Or just refactoring while accommodating protocol handling?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was fixing an issue due to the changes related to src/main/index.ts:158. Namely, if "renderer:loaded" gets called multiple times startUpdateChecking shouldn't be called on the subsequent events.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I figured, but is it still a bug otherwise? If so, shouldn't it really be in its own PR?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I figured that I should fix it in this PR since it was in this PR that I changed how the renderer lets main know it has been loaded.

@@ -37,30 +38,54 @@ let windowManager: WindowManager;

app.setName(appName);

logger.info("📟 Setting as Lens as protocol client for lens://");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
logger.info("📟 Setting as Lens as protocol client for lens://");
logger.info("📟 Setting Lens as protocol client for lens://");

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, though I will do that in a follow up PR so as to not need new approves.

@stefcameron
Copy link
Contributor

🎉 It's finally GREEN!!! 💚

Copy link
Contributor

@jakolehm jakolehm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Let's keep improving this in follow-up PRs.

@Nokel81 Nokel81 merged commit 1470103 into master Feb 25, 2021
@Nokel81 Nokel81 deleted the feature/protocol-handler branch February 25, 2021 14:32
@Nokel81 Nokel81 added this to the 4.2.0 milestone Mar 5, 2021
This was referenced Mar 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add a special "lens" native OS protocol handler to enable additional extension use cases
5 participants