Add support for choosing working directory

[AndyClifton]

I'm trying to implement an action to use pandoc on markdown files in my repository. The files are in subdirectories, e.g.,

. repo
  ├──seminar1
      ├──slides.md
  ├──seminar2
      ├── slides.md

I cannot figure out how to set the working directory for pandoc. Currently my action looks like this:

name: Make seminar slides from markdown

on: push
defaults:
  run:
    working-directory: seminar1

jobs:
  make_seminar1_slides:
    runs-on: ubuntu-18.04
    steps:
      - name: Get files
        uses: actions/checkout@v2
        with:
          ref: slides
          
      - name: Load pandoc
        uses: docker://pandoc/latex:2.9
        with:
          args: --from=gfm --to=beamer --resource-path=seminar1 --output=seminar1/slides.md.pdf seminar1/slides.md
          
      - name: Upload files
        uses: actions/upload-artifact@v2
        with:
          name: seminar-slides
          path: slides.md.pdf

Am I missing something? Is there a way to set a working directory for pandoc or in the action?

[AndyClifton]

This action seems to work if I modify the upload part of the action to explicitly include the directory information.

name: Make seminar slides from markdown

on: push
defaults:
  run:
    working-directory: seminar1

jobs:
  make_seminar1_slides:
    runs-on: ubuntu-18.04
    steps:
      - name: Get files
        uses: actions/checkout@v2
        with:
          ref: slides
          
      - name: Load pandoc
        uses: docker://pandoc/latex:2.9
        with:
          args: --from=markdown --to=beamer --resource-path=seminar1 --output=seminar1/slides.md.pdf seminar1/slides.md
          
      - name: Upload files
        uses: actions/upload-artifact@v2
        with:
          name: seminar-slides
          path: seminar1/slides.md.pdf

I'm not sure that there's a solution here that can be implemented by / using Pandoc; instead it looks like the uses action could do with some updating to get the working directory.

[bvanfleet]

Adding my support for this option into the mix. My organization uses a monorepo, with a subdirectory for our documentation. Unfortunately, unless I want to have to add environment variables to the project and prepend all files with a mix of variables (error prone) I'm finding it more difficult to use this action.

Having the option for setting the working directory would be very helpful, as we can then setup our jobs and steps to use the appropriate directories and also have our relative links work.

[alerque]

I think for the use-case you describe it would be easier to handle it yourself. The PR #11 shows an example of an alternate way to call action containers whereby you can actually run commands inside them by first opening a shell, then running more steps inside the action container. In this case you could use the Pandoc container with a shell entry point, then cd however you liked around your project and run pandoc from whatever point you liked.

It would of course be possible to add another input option to specify such a cd operation as part of the Action definition, but that's a pretty non-standard option as for as Actions go and I worry the proliferation of such options would just add clutter and make simple problems more complicated to solved than existing solutions.

Does it sound like the container approach would work for your use case?

[AndyClifton]

@alerque - thanks for this. I've also had an answer to my related question on Stackoverflow that seems to offer a way to do this.

I think it's reasonable to say that choosing the working directory is out of scope for your action if there are other ways to deal with this need. I'm still getting used to actions, so this was as much a plea for help, as an actual "issue"! I'd be OK with closing this issue now.

It would be really helpful to include the relevant bits of PR #11 in the readme.md (or other documentation) to show the working / compilation directory being chosen / set and an arbitrary .tex file being compiled.

Not sure if it helps @bvanfleet's challenge, though?