Repo path should be resolved relatively to current working directory

[MadsNielsen]

We want to be able to resolve the repo from current working directory. This makes it hard to use outside the docker image

ruby /here/lies/pac/pac.rb --setings=...

Reported by @Sharor

Should use relative path based on current working directory, regardless of where settings file is.

[buep]

This makes it hard to use outside the docker image

What do you mean with hard to use outside the docker image? It is hard to use now as a script, or will it be hard to use after you implement the feature?

[Sharor]

He meant hard to use as a script -

If you call it from a relative path, it fails silently. The thing I was trying to do, was package release notes inside a docker image to serve it.

I was running pac relatively, from the folder my repository was cloned into, which caused PAC to fail :)

[buep]

Okay, should fail silently of course.

[MichaelDepner]

@Sharor I'm not entirely sure what path should be relative. Could you provide an example of a command that you would expect to work?

[Sharor]

@michaelmadsen I took the docker image, cloned a repository inside and ran pac.rb from inside the repo - this causes pac.rb to fail :)

The idea was to be able to point to fx /pac.rb and /pac/templates and run it from /mypath/repository and produce release notes somewhere :)

[buep]

You're not supposed to do anything inside the docker container, so if that is the case we can close this issue.

[Sharor]

It matters for automation purposes in Concourse pipelines going forward. You can avoid Docker inside Docker if you're allowed to do things arbitrarily - and I do not see why you would lock down the container and disallow doing it inside the container? :)

[buep]

Okay, can you provide the series of commands and output the reproduces the issue?

I would like to se them to consider the solution, as the image was not designed for this purpose and usually you don't exec into a container.
If you use it as a build environment, I think another design, or new image is needed.

[Sharor]

Concourse does the following:

Downloads and runs container, exec in with "get" resources mounted (think cloned repositories) to a tmp path (ie /build/tmp/buildcontext/somesha/myclonedrepo) which is randomized for every build (new sha)

It then gives you full control of the container image, and allows you to execute commands from the build job (typically shell). The 'normal' way to use PAC would be to know where your repository is, but it then gets very messy unless I move the git repository out of my path to a 'known' location.

My thought was to create release notes in the build context, by just running pac where I stood in each git repo and then output my release with the notes, so they are in the correct context as the repository/repositories pass along the pipeline :)

It's not an unsolvable problem (I can just dump repos in a known location as said) - I just figured the silent bit was a problem either way 😉

[buep]

Okay, think we need to groom this issue further.

[buep]

I now tried it, things works exactly as I would expect.

I find some git repository I have. It contains a settingsfile for pac and one file README where some commits are done.

$ cd temp/idReportTestRepository/
$ ls
default_settings.yml  README.md

I can now start a pac container, it is latest version 2.1.1-9 (b29acba) by the way, and overwrite entrypoint to allow me to step into it using bash. I mount in my git repository above, into an "arbitrary" path so /data inside the container equals my repository mentioned earlier.

$ docker run -it --entrypoint "/bin/bash" -v $(pwd):/data praqma/pac
root@c7165022f033:/data# pwd
/data
root@c7165022f033:/data# ls
default_settings.yml  README.md

I can now run pac. The pac command is on my PATH inside the container, so I can run it from anywhere:

root@c7165022f033:/data# pac -s f9a66ca6d2e6
[PAC] Warning: Using deprecated method call. Use --from instead
root@c7165022f033:/data# ls
default.html  default.md  default.pdf  default_settings.yml  ids.md  README.md
root@c7165022f033:/data# rm default.* ids.md 

I can also give it my settingsfile:

root@c7165022f033:/data# pac -s f9a66ca6d2e6 --settings=default_settings.yml 
[PAC] Warning: Using deprecated method call. Use --from instead
root@c7165022f033:/data# ls
default.html  default.md  default.pdf  default_settings.yml  ids.md  README.md

The settings file should obviously be in the repository itself where it belongs.

The settings file above, contain among other things, the following relevant settings:

:templates:
  - { location: /usr/src/app/templates/default_id_report.md, output: ids.md }
  - { location: /usr/src/app/templates/default.md, output: default.md }
  - { location: /usr/src/app/templates/default_html.html, pdf: true, output: default.html }

Those are references to the default supplied PAC templates, that are distributed with the PAC image on that path.
If you want to use your own templates, they should your repository with the settings file, or mounted into the container on a path if you have common templates for many projects.

:vcs:
  :type: git
  :repo_location: '.'

That setting tells PAC that the repository location, is in the same path as the settings file, which is pretty basic.

So how would you use it differently? Can you give me the same set of commands? Or post your configuration files?

Please notice you should never need to call pac.rb inside the container, just call pac.

By the way for the silent failing issues I created #96 so we handle that separately.

[Sharor]

I think that is exactly right :) the silent failing being another issue, I reckon this is a closed one! 😉

[lakruzz]

if this is marked "won't have" then I would expect it to be closes as well - any particular reason why it's still around? Forget it! I don't make sense here!!!

@buep