-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Conversation
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.
Looks pretty good already 👍 Could we add integration tests for protocol handler?
I will write some integration tests. |
e601ffa
to
f663b82
Compare
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 |
That's cool! I remember you wanted to add support to |
None, the method on |
I even checked what your extension was expecting to make sure I didn't change anything 😉 |
Fantastic! Thanks for testing it out. 😄 |
@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. |
Yes those should have been reported as failed. Hard to say why it's not the case here, need to investigate further. |
Okay...I think I got it. We are running
We might want to return the exit code from |
Thanks will fix that. |
@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. |
I think the protocol name shoud be something less generic than |
As seen on slack, it has been decided to keep it as |
Signed-off-by: Sebastian Malton <[email protected]>
Signed-off-by: Sebastian Malton <[email protected]>
Signed-off-by: Sebastian Malton <[email protected]>
Signed-off-by: Sebastian Malton <[email protected]>
…l-handler Signed-off-by: Sebastian Malton <[email protected]>
…l-handler Signed-off-by: Sebastian Malton <[email protected]>
…n tests Signed-off-by: Sebastian Malton <[email protected]>
Signed-off-by: Sebastian Malton <[email protected]>
Signed-off-by: Sebastian Malton <[email protected]>
Signed-off-by: Sebastian Malton <[email protected]>
Signed-off-by: Sebastian Malton <[email protected]>
Signed-off-by: Sebastian Malton <[email protected]>
a77c07b
to
270d0f7
Compare
…l-handler Signed-off-by: Sebastian Malton <[email protected]>
Signed-off-by: Sebastian Malton <[email protected]>
Signed-off-by: Sebastian Malton <[email protected]>
@@ -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 { |
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.
Does this fix an unrelated issue? Or just refactoring while accommodating protocol handling?
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.
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.
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.
I figured, but is it still a bug otherwise? If so, shouldn't it really be in its own PR?
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.
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://"); |
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.
logger.info("📟 Setting as Lens as protocol client for lens://"); | |
logger.info("📟 Setting Lens as protocol client for lens://"); |
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.
Good catch, though I will do that in a follow up PR so as to not need new approves.
🎉 It's finally GREEN!!! 💚 |
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.
LGTM. Let's keep improving this in follow-up PRs.
Things that still need to be done:
Signed-off-by: Sebastian Malton [email protected]
fixes #1288