There’s not necessarily a “right” or a “wrong” way to make these decisions. My personal opinion on the subjects:

• args should be used to customize the behavior of an Action from one run to another
  • So if you have an Action that does something but you need it done two different ways in two separate Workflows, then an argument is probably the right choice
• env should be used to create named values (that don’t need to be secure) that might be shared between Actions
  • Like if multiple Actions need to know where the DOCS_DIR is, this might be a valid use for an environment variable
• If the code in an Action requires some tool or even fixed dependencies to do its job, I would typically build that into the Docker image as a RUN step so that the code in entrypoint.sh is, as much as possible, performing the Action’s designed task
• Much like the Unix philosophy for command-line tools, each Action should do one thing well and Workflows should be used to chain multiple Actions together

But these are only my personal thoughts on it from my meager experience so far and, much like designing command-line tools, there are a bunch of different ways to achieve the same ends.

You can see how I’ve designed one Action for a recent project of mine in https://github.com/lee-dohm/generate-elixir-docs. I’ll probably move these lines into the Dockerfile eventually, because they can be installed in the image and cached. But this line needs to remain in the entrypoint.sh because the definition of the dependencies is stored in the repository itself and may change from one invocation of the Action to the next.

Again, there’s no hard and fast right or wrong answer to any of these questions. It mostly depends on how you’re intending the Action to be used: only for the one specific project or more generally across multiple projects.

I hope that helps!