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 and a script. And we'll also need an actions.yml file for GitHub along with 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 can be parameterized. If we parameterize the action, we'll be able to use it for more than just one purpose. We could probably ask more questions to figure out the requirements for our actions, 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 might be 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. 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 with the Dockerfile. And if our action needs a script, the Dockerfile make sure the script is run properly. Next, we 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 set up properly, 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. Our action requires a file named actions.yml for sharing metadata with GitHub. The metadata file will define the inputs, outputs, main entry point for our action, and other details like the name of the action, a description for the action, and the name of the person who wrote the action. In case you didn't know, that's probably you. We'll also use the actions.yml file for branding our action in marketplace with an icon and colors. 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 actions README file can do is provide an example, showing exactly how to use it. We should include some code and 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 lets 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 specific styling. Okay, now that we have a plan, let's make a custom action.