Ideas towards reusable python actions

[sburns]

👋

At first, I was writing actions with Dockerfiles that didn't do much except define the FROM. What I like to do in a CI context is run simple shell commands. Install dependencies along with make and run a make command. But I need a good python install.

Obviously the python docker images are great for 1) locking to a python version 2) on a known base OS. The only issue with the python images is that the entry point drops into the interpreter and rarely am I looking to run python code in CI. I'll execute shell commands to execute it, but I feel abstracting that into portable shell commands is just better.

So to me, something useful that I've duplicated in a few repos at this point is an action using a generic image like docker://python:3.6-alpine but overrides the entrypoint with a dumb runner script that just executes a list of shell commands in args.

Positives

• No extraneous Dockerfiles in my repo to maintain.
• Relatively easy to follow actions in main.workflow E.g.

action "python commands" {
    uses = "docker://python:3.6-alpine"
    runs = "./runner.sh"
    args = [
        "apk add make",
        "pip install...",
        "make test"
    ]
}

• reuse of the runner.sh script. Because the actions "business logic" is now specified in args.

Negatives

• the commands in args are not cached in an image layer. if it takes a while to install dependencies, this won't be ideal. A lot of libs are on wheels these days but not every thing obviously.
• needing to duplicate that runner script in all the repos.

But I feel like we could remove that list point if we could write an action like this

action "python commands" {
    uses = "jefftriplett/python-actions/3.6@master"
    args = [
        "apk add make",
        "pip install...",
        "make test"
    ]
}

We'd have to make choices about the images to use (I'd probably lean toward slim).

What do you think?

[sburns]

Also thinking about where pip should install. If it installs into /usr/local....site-packages in a build step, that will not exist in a subsequent container hoping to run tests. But installing into a virtual environment in /github/workspace will persist across different actions.

[jefftriplett]

This is great and I will free up more time to digest and try out what you have proposed. I stubbornly am curious what the build/execution time would be like for pytest using the GITHUB_WORKSPACE setting along with making the pip action respect it. That said, I think you are right and this approach is probably a dead end.

I think that your proposed "python commands" action/workflow is most likely the best path forward and would take care of all the pain points that my experiment created.

[sburns]

I'm likely just a few days ahead of you in understanding and our future selves will think we're both being dummies. I too am trying to find some time to apply more actions to more work repos (both public and private). I think that's likely the best way to learn right now, see what works and what doesn't and slowly build up the pile of ideas that don't work.

[jefftriplett]

@sburns I refactored everything over lunch, but github's cache is stuck (or I did something dumb that I can't see). Check out https://raw.githubusercontent.com/jefftriplett/example-python-actions/master/.github/main.workflow and what I changed here.

Hopefully it works itself out in the next few hours.

[jefftriplett]

I spoke too soon. I'm running black over the entire python code base which does in fact, error.