Run pandoc command in a shell?

[kwsp]

Would it be possible to call the pandoc command from a shell? I have a build script written in python that calls pandoc over some files through the subprocess module.

[alerque]

To do that via docker-run steps in an actions workflow you would either need to install Python into the Pandoc image or Pandoc into some image of your own. Personally I'd suggest a 3rd route of just making your own image with your own tools and using that as your runner.

For example you could do this with Nix:

shell.nix: (in your project's root)

with import <nixpkgs> {};
mkShell {
  nativeBuildInputs = [ python pandoc ];
}

.github/workflow/build.yml: (step)

- name: Run builder in nix
  uses: docker://nixos/nix
  run: |
    nix-shell --run ./build.py

Similar things could be done with almost any Linux distro base image of your choice (that happens to have Pandoc and Python packages).

[kwsp]

I found a better way to do this. Github Action actually lets you run jobs inside docker containers, rather simply using the entrypoint's of a given container (which is currently the only version specified in the README). This is done by specifying the container value of a job. For example,

name: Build
on: push

jobs:
  convert_via_pandoc:
    runs-on: ubuntu-20.04
    container: 
      image: pandoc/core:2.9

    steps:
      - uses: actions/checkout@v2
 
      - run: pandoc README.md -o README.html

This way, it's a lot easier to build custom images with custom dependencies, specifying the container value, then having access to all those executables in your PATH in the rest of the job script. For example, I built a custom image that adds the python3 dependency: tigernie/pandoc-python3,

Should we add this to the README for when people come to this repo from search with this use case in mind?

[alerque]

We already have a PR mentioning the parent container method, see #11. Note this does have a downside of not being able to run other Action tooling via uses: as easily because many of them depend on the tooling in the Ubuntu base images.

That aside, the container trick in itself doesn't answer your original question because it doesn't have the other tooling you need in the Pandoc image. Making your own image with your own tools is certainly viable (and what I recommended above) but I'm not sure how best to document that as there are so many possible variants of that with different distros, places to keep sources or images, etc. It can be done via external images as you've done or even in the same project (you can use a Dockerfile from the current repo to run containers in CI).