pulumi

History

Matt Ellis c924c18d2c Do not make errors during plugin discovery fatal The plugin host can ask the language host to provide a list of resource plugins that it thinks will be nessecary for use at deployment time, so they can be eagerly loaded. In NodeJS (the only language host that implements this RPC) This works by walking the directory tree rooted at the CWD of the project, looking for package.json files, parsing them and seeing it they have some marker property set. If they do, we add information about them which we return at the end of our walk. If there is any error, the entire operation fails. We've seen a bunch of cases where this happens: - Broken symlinks written by some editors as part of autosave. - Access denied errors when part of the tree is unwalkable (Eric ran into this on Windows when he had a Pulumi program at the root of his file system. - Recusive symlinks leading to errors when trying to walk down the infinite chain. (See #1634 for one such example). The very frustrating thing about this is that when you hit an error its not clear what is going on and fixing it can be non-trivial. Even worse, in the normal case, all of these plugins are already installed and could be loaded by the host (in the common case, plugins are installed as a post install step when you run `npm install`) so if we simply didn't do this check at all, things would work great. This change does two things: 1. It does not stop at the first error we hit when discovering plugins, instead we just record the error and continue. 2. Does not fail the overall operation if there was an error. Instead, we return to the host what we have, which may be an incomplete view of the world. We glog the errors we did discover for diagnostics if we ever need them. I believe that long term most of this code gets deleted anyway. I expect we will move to a model long term where the engine faults in the plugin (downloading it if needed) when a request for the plugin arrives. But for now, we shouldn't block normal operations just because we couldn't answer a question with full fidelity. Fixes #1478	2018-08-20 15:39:39 -07:00
..
main.go	Do not make errors during plugin discovery fatal	2018-08-20 15:39:39 -07:00
main_test.go	Add license headers	2018-05-22 15:02:47 -07:00

Matt Ellis c924c18d2c Do not make errors during plugin discovery fatal

The plugin host can ask the language host to provide a list of
resource plugins that it thinks will be nessecary for use at
deployment time, so they can be eagerly loaded.

In NodeJS (the only language host that implements this RPC) This works
by walking the directory tree rooted at the CWD of the project,
looking for package.json files, parsing them and seeing it they have
some marker property set. If they do, we add information about them
which we return at the end of our walk.

If there is *any* error, the entire operation fails. We've seen a
bunch of cases where this happens:

- Broken symlinks written by some editors as part of autosave.
- Access denied errors when part of the tree is unwalkable (Eric ran
  into this on Windows when he had a Pulumi program at the root of his
  file system.
- Recusive symlinks leading to errors when trying to walk down the
  infinite chain. (See #1634 for one such example).

The very frustrating thing about this is that when you hit an error
its not clear what is going on and fixing it can be non-trivial. Even
worse, in the normal case, all of these plugins are already installed
and could be loaded by the host (in the common case, plugins are
installed as a post install step when you run `npm install`) so if we
simply didn't do this check at all, things would work great.

This change does two things:

1. It does not stop at the first error we hit when discovering
   plugins, instead we just record the error and continue.

2. Does not fail the overall operation if there was an error. Instead,
   we return to the host what we have, which may be an incomplete view
   of the world. We glog the errors we did discover for diagnostics if
   we ever need them.

I believe that long term most of this code gets deleted anyway. I
expect we will move to a model long term where the engine faults in
the plugin (downloading it if needed) when a request for the plugin
arrives. But for now, we shouldn't block normal operations just
because we couldn't answer a question with full fidelity.

Fixes #1478

2018-08-20 15:39:39 -07:00

main.go

Do not make errors during plugin discovery fatal

2018-08-20 15:39:39 -07:00

main_test.go

Add license headers

2018-05-22 15:02:47 -07:00