Streamlining Development with GitHub Actions

GitHub Actions was initially introduced for PR Lint test purposes, but as improvement points such as Runner setup, duplicate executions, and unnecessary triggers became apparent, its use expanded into broader automation. Here's a summary of workflows and action use cases that improved development efficiency after applying it for about 6 months.

GitHub Actions is a platform that lets you complete CI/CD within GitHub. When an event occurs in a repository, a workflow runs on a Runner, and the execution environment is divided into GitHub-hosted Runner and Self-hosted Runner. In environments where code exposure is sensitive, such as internal company repositories, a Self-hosted Runner is needed for security reasons, but if external exposure isn't a problem, the GitHub-hosted Runner can be used conveniently.

The core of writing a workflow is name, on, jobs, and steps. With on, you can finely control triggers such as push, pull_request, schedule, and workflow_dispatch, and even specify branch filters and event types. For example, you can run only when a PR is opened, reopened, synchronize, or ready_for_review, run a task at a specific time every week via cron, or trigger execution manually with a button.

Using GitHub Contexts makes workflows much more flexible. You can get the PR number with github.event.number, obtain GitHub API permissions with secrets.GITHUB_TOKEN, and reuse github.event.sender.login and github.ref_name as environment variables to simplify conditional logic and branching. Unlike a PAT that users manage directly, secrets.GITHUB_TOKEN has the advantage of being automatically generated when a workflow runs and removed after it ends, with permissions limited to the scope of the executing repository.

As an actual use case, auto-approve-action was used to have a bot approve auto-generated develop <- main PRs. Due to the git flow structure, when main is merged, a develop sync PR is automatically created, but since 2 reviewer approvals were enforced, which was inconvenient, this process was automated.

The GitHub Actions Marketplace has the strength of letting you use needed functionality right away without implementing it yourself. For example, wait-for-green was used to check that status checks are complete, and create-or-update-comment was used to leave a "ready to merge" comment, automating the PR flow. This greatly reduces implementation cost since you don't have to write complex GitHub API scripts yourself.

However, in GitHub Enterprise environments, it can be difficult to use external actions other than official ones directly for security reasons. In this case, actions need to be cloned separately and managed internally, and a centralized group management approach is needed to prevent duplicate cloning. When introducing external actions, you also need to review whether they only use a GitHub API library like octokit, or whether unnecessary packages are mixed in.

Ultimately, GitHub Actions is not just a simple CI tool, but a foundation for automating repetitive tasks such as PR approvals, notifications, branch syncing, issue cleanup, weekly report generation, and PR labeling. As long as a Runner is set up, the barrier to entry is low, and using the Marketplace and Context together lets you consolidate much of repository operations into a few workflows.