porter install --file fails with path to file outside pwd

[simongdavies]

Describe the bug

Executing porter install with --file specifying a manifest in a directory outside the current working directory fails.

To Reproduce

Steps to reproduce the behavior:

1. create a directory a
2. place any valid porter.yaml file in this directory
3. Run this porter command porter install --file a\porter.yaml
4. See error

Expected behavior

Bundle should be built and installed

Porter Command and Output

$ porter install -f tests/testdata/porter.yaml
 Building bundle ===>
Error: unable to generate manifest: could not read the manifest at "porter.yaml": open /home/simon/github/simongdavies/kubernetes-plugins/porter.yaml: no such file or directory

Version

porter v0.33.0 (991a5a2)

[carolynvs]

@vdice and I were talking about the --file parameter and how it's something we originally added but at this point it isn't something that is supported well enough in the code to be usable. I think we ran into this when Vaughn added support for --registry to porter publish and we assume that the file we are building from is always porter.yaml. The other piece of it is that Porter was written with the understanding that it is always run from within the bundle directory.

Before 1.0 we need to decide if we are going to do the work to support file (and cnab-file) flags or if they should be removed.

[carolynvs]

@vdice Do you think that your fix from earlier, allowing people to specify a build context directory, fixes this?

[vdice]

@carolynvs yes. Perhaps we can check in with @simongdavies to be sure we've covered the intended use cases, but porter build supports an alternate build context dir and/or porter.yaml filepath. Note that the action commands porter install, etc., only support the latter, however.

[carolynvs]

@simongdavies Can you try building the bundle using the --dir (works the same way as the docker build context in conjunction with --file) and let us know if that fixed the problem? e.g.

porter build --dir a

[carolynvs]

This isn't quite working the way we want it to yet. In the example below, I want porter build --dir fa to default the file to DIR/porter.yaml but it defaults to PWD/porter.yaml. So one more fix is needed.

$ mkdir fa && cd fa && porter create
creating porter configuration in the current directory

$ cd ..

$ porter build --dir fa
Error: unable to generate manifest: could not read the manifest at "": read /Users/carolynvs/demo/install/fa: is a directory

$ porter build --dir fa --file porter.yaml
Error: unable to access --file porter.yaml: stat /Users/carolynvs/demo/install/porter.yaml: no such file or directory

$ porter build --dir fa --file fa/porter.yaml
Copying porter runtime ===>
Copying mixins ===>

[joshuabezaleel]

@carolynvs Since both --dir and --file flag will be in the form of path to point the location of the .yaml file and the target file is assumed to always be porter.yaml file, wouldn't it be redundant to have both flag?

[carolynvs]

--dir should indicate the base directory to use as the docker context. It lets people put porter's files in a subdirectory and be able to access files from parent directories during porter build. For example:

repo/
  /porter/
    porter.yaml
  /bin/
    myapp

porter build --dir repo --file porter/porter.yaml

--file allows for people to use a filename other than porter.yaml. For example they could have variations of a bundle and put them into aws.porter.yaml and azyre.porter.yaml.

[VinozzZ]

currently, -f uses the pwd() as the current working directory if a relative path is provided even when -d is specified with a different value.
However, when a fully resolved path is provided, -f is able to figure out where the porter file is

[carolynvs]

Thanks for narrowing down where the bug is hiding! I'm going to assign this to you since I think you are pretty close to getting it fixed.

[github-actions]

Closed by #2142.