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

Allow overriding a Pulumi.yamls entrypoint #575

Closed
joeduffy opened this issue Nov 15, 2017 · 2 comments · Fixed by #582
Closed

Allow overriding a Pulumi.yamls entrypoint #575

joeduffy opened this issue Nov 15, 2017 · 2 comments · Fixed by #582
Assignees
Labels
area/cli UX of using the CLI (args, output, logs)
Milestone

Comments

@joeduffy
Copy link
Member

In some cases, we want to let the Pulumi.yaml file choose a different entrypoint. This will let you locate your Pulumi project file in a different location than the program assets.

@joeduffy joeduffy added the area/cli UX of using the CLI (args, output, logs) label Nov 15, 2017
@joeduffy joeduffy added this to the 0.9 milestone Nov 15, 2017
@joeduffy joeduffy self-assigned this Nov 15, 2017
joeduffy added a commit that referenced this issue Nov 16, 2017
Because the Pulumi.yaml file demarcates the boundary used when
uploading a program to the Pulumi.com service at the moment, we
have trouble when a Pulumi program uses "up and over" references.
For instance, our customer wants to build a Dockerfile located
in some relative path, such as `../../elsewhere/`.

To support this, we will allow the Pulumi.yaml file to live
somewhere other than the main Pulumi entrypoint.  For example,
it can live at the root of the repo, while the Pulumi program
lives in, say, `infra/`:

    Pulumi.yaml:
    name: as-before
    main: infra/

This fixes #575.  Further work can be done here to
provide even more flexibility; see #574.
joeduffy added a commit that referenced this issue Nov 16, 2017
Because the Pulumi.yaml file demarcates the boundary used when
uploading a program to the Pulumi.com service at the moment, we
have trouble when a Pulumi program uses "up and over" references.
For instance, our customer wants to build a Dockerfile located
in some relative path, such as `../../elsewhere/`.

To support this, we will allow the Pulumi.yaml file to live
somewhere other than the main Pulumi entrypoint.  For example,
it can live at the root of the repo, while the Pulumi program
lives in, say, `infra/`:

    Pulumi.yaml:
    name: as-before
    main: infra/

This fixes #575.  Further work can be done here to
provide even more flexibility; see #574.
@chrsmith
Copy link
Contributor

Just to make sure I understand how this was implemented in 98ef0c4, we added a new main attribute to Pulumi.yaml. If set, when the Pulumi program executes it will start based on that relative path. (And not in the same directory as Pulumi.yaml as before.)

So with main: foo/bar, the package.json file would be in foo/bar relative to Pulumi.yaml. Right?

That all seems reasonable, but if the main attribute is in a parent directory, the Pulumi program will fail in hosted scenarios because we only upload files "below" the Pulumi.yaml. So just thinking aloud, it seems like this feature would need to be coupled with #574 somehow?

e.g. "if main is in a parent folder, we need to implicitly set the build context to that parent folder".

@joeduffy
Copy link
Member Author

joeduffy commented Nov 16, 2017

Correct, if main was ../etc, it will fail in hosted scenarios. #574 will be needed for ultimate flexibility -- e.g., you want to actually include the parent directory in the context to share source assets amongst multiple Pulumi projects -- but I expect the main directive to be the simpler, more common case, and it unblocks the LM scenario. Plus it encourages putting Pulumi.yaml in the root of the repo, which I actually quite like (Dockerfile is a similarly nice advertisement).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/cli UX of using the CLI (args, output, logs)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants