GitHub actions:

In software engineering, CI/CD is the combined practices of continuous integration and continuous delivery or, less often, continuous deployment. it automates and streamlines the software development process. It helps in quickly identifying and fixing bugs, ensuring code quality, and accelerating the delivery of software updates.

GitHub Actions simplifies CI/CD by letting you automate tasks like building, testing, and deploying your code directly within GitHub.

💡

what is github action :

GitHub Actions is a feature on GitHub that enables you to automate tasks and workflows directly within your GitHub repository. It allows you to build, test, and deploy your code without needing to rely on external services. With GitHub Actions, you can define custom workflows using YAML files, trigger them based on various events (like pushes, pull requests, or schedules), and integrate with other tools and services to streamline your software development process.

Components Of GitHub Actions:

The components of GitHub Actions include:

Workflows: Defined using YAML files, workflows are sets of customizable steps that automate tasks within your GitHub repository.

Events: Events is an activity that triggers a workflow to run. Events can be triggered by opening a pull request, merging a pull request, etc. It can be configured to run on schedule.

Jobs: Each workflow consists of one or more jobs, which are a sequence of steps executed on the same runner.

Steps: Jobs are comprised of individual steps, each representing a single task such as checking out code, running tests, or deploying applications.

Runners: Runner is a server that runs your workflow when they are triggerd. Each runner can run a single job at a time.

Actions: Reusable units of code that perform specific tasks within a workflow, either pre-built actions provided by GitHub or custom actions created by users.

These components work together to automate various aspects of software development, including building, testing, and deploying code, within the GitHub ecosystem.

Setting up a GitHub Action in your GitHub repository involves the following steps:

Create a Workflow File: In your repository, create a .github/workflows directory if it doesn't already exist. Inside this directory, create a YAML file to define your workflow. You can name this file whatever you like, but it must have a .yml or .yaml extension.

Define Workflow: In the YAML file, define your workflow by specifying events that trigger it and the jobs and steps to be executed. You can use predefined actions provided by GitHub or create custom actions.

Commit and Push

View Workflow: Navigate to the "Actions" tab in your GitHub repository to view the status and execution logs of your workflow. You can also manually trigger workflows from this tab.

Here's a simplified example of a workflow YAML file that runs on every push to the main branch:

yamlCopy code
name: CI

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Check out code
        uses: actions/checkout@v2

      - name: Run tests
        run: |
          # Commands to run your tests

In this example:

The workflow is triggered on every push to the main branch.

It defines a single job called build that runs on the latest version of Ubuntu.

The steps include checking out the code from the repository and running tests.

You can customize this YAML file based on your specific requirements and workflows.

create github action workflow through terminal:

o create a GitHub Actions workflow through the terminal, you can follow these steps:

Navigate to Your Repository: Open a terminal window and navigate to the directory of your GitHub repository using the cd command.

Create the Workflow Directory: If the .github/workflows directory doesn't already exist in your repository, create it using the mkdir command:

bashCopy code
mkdir -p .github/workflows

Create the Workflow File: Use a text editor or command-line tools to create a YAML file within the .github/workflows directory. You can name the file whatever you like, but it must have a .yml or .yaml extension. For example:

bashCopy code
touch .github/workflows/my_workflow.yml

Edit the Workflow File: Open the YAML file in a text editor or use command-line tools to add the workflow configuration. Define the events that trigger the workflow and specify the jobs and steps to be executed. You can use predefined actions provided by GitHub or create custom actions. Here's an example of a simple workflow YAML file:

yamlCopy code
name: CI

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Check out code
        uses: actions/checkout@v2

      - name: Run tests
        run: |
          # Commands to run your tests

Commit and Push the Workflow File: Once you've defined the workflow configuration, commit the YAML file to your repository and push the changes to GitHub:

bashCopy code
git add .github/workflows/my_workflow.yml
git commit -m "Add GitHub Actions workflow"
git push origin main

Verify on GitHub: Navigate to the "Actions" tab in your GitHub repository to verify that the workflow has been set up correctly. You should see your workflow listed and any associated runs triggered by the defined events.

Once the GitHub actions are configured and start running, you can view each step’s activity on GitHub.

conclution:

By setting up GitHub Actions in your GitHub repository empowers you to automate tasks and streamline your software development workflows. By defining workflows, specifying triggers, and incorporating predefined or custom actions, you can automate processes such as building, testing, and deploying your code—all within the GitHub ecosystem. With easy visibility into workflow status and execution logs, GitHub Actions provides a powerful tool for enhancing productivity, ensuring code quality, and accelerating the delivery of software updates.

Goals

What should be true after this project is implemented?

Non-goals

What is explicitly not in scope and why?

Proposed solution

What changes are required to solve this problem and achieve the project goals?

What are the high level architectural changes?

Diagrams can be very helpful here.

What are the high level data model changes?

These should include any database schema changes, or any changes to structured fields, e.g. an existing JSON column.

What are the main changes to the UI?

Risks

What risks might be introduced by this set of changes? Consider running a pre-mortem to raise risks. Be sure to capture mitigating these risks in the Implementation and Rollout Plans.

Are there any backwards-incompatible changes?

Does this project have special implications for security and data privacy?

Could this change significantly increase load on any of our backend systems?

Does this project have any dependencies?

Alternative solutions

What alternatives did you consider? Describe the evaluation criteria for how you chose the proposed solution.

Implementation and rollout plan

Fill this section out based on what is relevant for the size and scope of this project. This section can also be TBD as the project is started, but you should gradually fill this in as the project progresses towards launch.

Does this project require a migration?

If an extensive migration is necessary, write a separate tech spec for it, and link it here. Describe how to rollback in the event of an unsuccessful migration.

Is this project in an experiment or feature flagged?

Describe how to support an incremental release if needed.

Success Criteria

How will you validate the solution is working correctly?

Describe what automated and/or manual testing you will do. Does this project need load or stress testing? This can also be a separate Testing Plan doc that is shared with QA, and linked here.

What monitoring and alerting will you do to ensure this project doesn’t decrease performance and reliability?

E.g. Increased requests, latency, and error rates.

Github Actions