Plan a custom action

- [Instructor] Let's make a plan for our custom action with a checklist. We'll need a few things. An objective, a repository, a dockerfile, a script, and a README file. Before we start coding, we need a solid objective. This will help us figure out exactly what our action will do. We can start by asking ourselves, what problem will this action solve? We can also ask if the action will be parameterized. If we parameterize the action, we'll be able to use it for more than one purpose. We could probably ask more questions to figure out the requirements for our action but this should give us a good start. Next, we'll need a new public repository. Keeping our action code in its own repository will help with managing and versioning the code. If there are problems with our action code, for example, we won't have to sort through unrelated files to figure out what's causing the problem. Also, we'll be able to version the action code independently of any workflows or applications that use the action. Also, keeping the repository public will make the action easier to share with other developers and easier for us to use in our other projects. Actions stored in private repositories can only be used in the repository where the action is stored. Once the repo is in place, we'll need a dockerfile. All actions require a dockerfile to define the container environment that runs the action. We'll provide the commands needed to install libraries or any requirements that our action needs to complete its task. We'll also use the dockerfile to interact with the visual workflow editor to do things like add icons, set the action's name, and provide metadata like a home page or a link to the action's repo. And if our action needs a script, the dockerfile makes sure the script is run properly. We'll also need a script. The script is what makes our action actually do something. It lists the commands that the action will perform and any logic associated with those commands. Our script will also let us work with environment variables, event data, secrets, and any other information needed to complete the task. As long as we configure our dockerfile properly, we can code our script in just about any language. We could consider using Python, Ruby, or even Java or C#. As long as our container is running right, any scripting or programming language is fair game. To keep things simple though, we should try to use a shell interpreter like the default system shell for an operating system. Every well-written action should include a README file at the top level of the repository. The README file provides all the details and information on what an action does. It can also explain any optional or required environment variables and secrets that need to be defined for the action to operate successfully. Additionally, the README file can explain any arguments that need to be defined when the action is called. In my opinion, the most important thing our action's README file can do is provide an example showing exactly how to use it. We should include some code or maybe some images to show what the proper use of our action looks like. You should also know that README files for GitHub are written in Markdown format. Markdown is a formatting syntax that let's us add style to documents and save them as plain text. As we develop our action, we should save the README file for last so, if anything changes during development, we won't have to worry about missing an update in our README file. If you need any tips on using Markdown, GitHub has a great article on Getting Started With Markdown along with how to use GitHub's specific styling. Okay, now that we have a plan let's make a custom action.