Deploying Python GitHub Actions to Marketplace | by Kaustubh Gupta | Towards Data Science

Check out the action developed here:
github.com
I am using GitHub actions for quite some time and I believe that it has a lot more potential than the current usage. I have seen a lot of use cases of GitHub actions to automate tasks but one noticeable thing was that the actions were mainly made using Javascript and Dockers. If you search for the term “GitHub Action” in GitHub, then you will see a long list of repositories using or made the action. In terms of the programming language chosen, here are the results:
These numbers clearly show that there are very few repositories using Python. The major reason for this is that GitHub officially supports Docker and Javascript while building the action for the marketplace.
It does not mean that other languages are not supported but the workaround for them is complicated. One needs to have a good understanding of Dockers and if the action is using files from the current repo, then how to manage the paths of action.
In this article, I will show you the best way to publish your Python-based GitHub actions without Dockers!
The GitHub action I am building in this article is for updating the GitHub profile README files with information about projects hosted/pushed by users on their GitHub accounts. This special Readme, which gets displayed on the public profiles has become a trend and everyone is trying to make it as appealing as possible. GitHub Stats, latest blog posts display, or commit activity over time are some of the famous types of workflows users have integrated into their profiles.
I wanted to create a similar action that updates user’s project information such as stars, any change in description, or any other new project addition. Let’s see how I made the basic workflow.
The logic is pretty simple. As one cannot determine which of the following repositories from the stack of 100’s are eligible to be displayed on the profile section, this work has to be done manually by the user. The work is to add the “project” topic to every repository that hosts any of their project files. This labeling will help me filter out the repositories which will be included in the project section.
Next, I needed to come up with the logic that every time the action is triggered, only a particular section of the readme is modified and not the whole file. For this, I took reference from this readme workflow. I modified the logic for general usage. Also, one more thing which was missed in my previous project was that the commit should only happen when there is a change in content. This part took a series of hits and trials to come up with a solution. The whole script didn’t take much time to code and here is what the code looks like:
I am taking 4 inputs from the user: GitHub access token, name of the readme file, path to checked out repository (I will discuss this in detail below), and the maximum characters for repository description. All these inputs are taken from the command-line. The next and final step is to run the script as an action in a workflow.
I had described the differences between action and workflow in one of my previous articles so I will give a brief here. Actions are the tasks that can be part of any bigger tasks known as workflows. Practically, a profile readme can have a workflow with multiple actions to update different sections. The script I showed above is actually an action that can be part of any workflow after it’s public.
GitHub has made a process for making an action to be used by other users. One has to create a file called action.yml file in the root of the action repository which contains all the input-output of the action. Also, it defines where the action will be run, the environment. This is where Python scripts need an extra step.
In the runs parameter, we need to use the composite. The composite takes the mandatory steps parameter and the steps parameter takes in two compulsory parameters: run and shell. The best part of YAML files is that they are hierarchical in nature and indentation defines the level of that parameter. Here is how I defined my action.yml runs parameter:
Important thing: Whenever you make the action public, the path of the files will not be the same. To get the exact path of the files while the action is in the run, you can use github.action_path variable. These variables are called context information and GitHub provides a large number of context variables that can be used while running the actions. Check out this documentation for the full list.
I have used the action_path and workspace paths because both serve different purposes. The action path is where the action files are stored. They are stored in:
/home/runner/work/_actions/{git_username}/{action_repo}/master/
And the workspace path is where the current repository where this action has been triggered is checked out (call it cloned).
/home/runner/work/{checked_repo_name}/{checked_repo_name}/
Now that the action is public, we can use it in any profile. This action requires you to have a special comment in your README file:
<!-- PROJECTS START --><!-- PROJECTS END -->
Next, create a directory:
.github/workflows/<any_name>.yml
and paste this starter code:
Now that particular section will be updated with your project information!
There are a lot of things that can be implemented using Github actions, context variables, and triggers. This particular action is inspired by the blog-post-workflow.
You can connect with me on Linkedin and GitHub.
Check out my other Python centered articles: