[Azure] CLI 명령어를 통한 Blob Storage 생성 및 사용


Azure Blob Storage는 대규모 비정형 데이터를 저장하고 관리하는 확장 가능하고 고가용성의 객체 스토리지 서비스입니다.

 

Azure CLI 명령어로 스토리지 계정에 컨테이너를 생성 후 파일을 업로드 및 다운로드를 해보도록 하겠습니다.

 

 


스토리지 접근 방법

Azure CLI를 통해 스토리지를 접근 시 Auze login을 통한 권한이 있는 계정에 접근하거나, 스토리지 계정에 있는 액세스 키를 사용하여 스토리지를 사용할 수 있습니다.

 

Azure CLI 설치 및 login 방법은 아래 링크를 통해 확인해보시길 바랍니다.
https://every-up.tistory.com/77

 

 

스토리지 액세스 키는 스토리지 계정의 액세스 키 메뉴에서 확인하실 수 있습니다.

 

 

스토리지 계정 이름과 액세스 키를 CLI 명령어에서 사용 시 아래와 같이 옵션을 추가하여 사용합니다.
ex) --account-name $AZURE_STORAGE_ACCOUNT --account-key $AZURE_STORAGE_KEY

 

 


컨테이너 생성 및 확인

스토리지 관련 명령어는 az storage 명령어로 관리되며 컨테이너 생성을 위한 container create 등의 옵션이 추가적으로 필요합니다.


앞에서 확인한 스토리지 계정 이름과 액세스 키를 사용하여 "test-container-02" 이름의 컨테이너를 생성해보겠습니다.

> az storage container create --name test-container-02 --account-name $AZURE_STORAGE_ACCOUNT --account-key $AZURE_STORAGE_KEY
{
  "created": true
}

 

 

 

생성이 완료되면 아래 명령어를 통해 생성된 컨테이너를 확인하실 수 있습니다.

> az storage container list --account-name $AZURE_STORAGE_ACCOUNT --account-key $AZURE_STORAGE_KEY
[
  {
    "deleted": null,
    "encryptionScope": {
      "defaultEncryptionScope": "$account-encryption-key",
      "preventEncryptionScopeOverride": false
    },
    "immutableStorageWithVersioningEnabled": false,
    "metadata": null,
    "name": "test-container-02",
    "properties": {
      "etag": "\"0x###############\"",
      "hasImmutabilityPolicy": false,
      "hasLegalHold": false,
      "lastModified": "2024-06-07T04:59:08+00:00",
      "lease": {
        "duration": null,
        "state": "available",
        "status": "unlocked"
      },
      "publicAccess": null
    },
    "version": null
  }
]

 

 


컨테이너 파일 업로드 및 다운로드

파일 업로드

이제 생성된 컨테이너에 파일을 업로드 해보도록 하겠습니다. az storage blob upload 명령어를 사용하여 "text2.txt" 이름의 파일을 "test-container-02" 컨테이너에 업로드 해보도록 하겠습니다.

> az storage blob upload --container-name test-container-02 --file text2.txt --name text2.txt --account-name $AZURE_STORAGE_ACCOUNT --account-key $AZURE_STORAGE_KEY
Finished[#############################################################]  100.0000%
{
  "client_request_id": "f6525a32-248b-11ef-####-###########",
  "content_md5": "CkKOC8iUNoUV##########==",
  "date": "2024-06-07T05:08:23+00:00",
  "encryption_key_sha256": null,
  "encryption_scope": null,
  "etag": "\"0x###############\"",
  "lastModified": "2024-06-07T05:08:24+00:00",
  "request_id": "106ef2b2-801e-006a-####-###########",
  "request_server_encrypted": true,
  "version": "2022-11-02",
  "version_id": null
}

 

파일 확인

생성된 컨테이너의 파일 정보는 az storage blob list 명령어를 통해 확인하실 수 있습니다.

> az storage blob list --container-name test-container-02 --account-name $AZURE_STORAGE_ACCOUNT --account-key $AZURE_STORAGE_KEY
[
  {
    "container": "test-container-02",
    "content": "",
    "deleted": null,
    "encryptedMetadata": null,
    "encryptionKeySha256": null,
    "encryptionScope": null,
    "hasLegalHold": null,
    "hasVersionsOnly": null,
    "immutabilityPolicy": {
      "expiryTime": null,
      "policyMode": null
    },
    "isAppendBlobSealed": null,
    "isCurrentVersion": null,
    "lastAccessedOn": null,
    "metadata": {},
    "name": "test2.txt",
    "objectReplicationDestinationPolicy": null,
    "objectReplicationSourceProperties": [],
    "properties": {
      "##### 생략 #####"
    }

 

 

파일 이름명만 확인하고 싶을 경우에는 해당 명령어에 --query "[].name" --output tsv 옵션을 추가합니다.

> az storage blob list --container-name test-container-02 --account-name $AZURE_STORAGE_ACCOUNT --account-key $AZURE_STORAGE_KEY --query "[].name" --output tsv
test2.txt

 

파일 다운로드

생성된 컨테이너의 파일을 다운로드하기 위해 az storage blob download 명령어를 사용합니다.
D:\TEST\test2-upload.txt 이름으로 파일을 다운로드 받도록 설정하였습니다.

> az storage blob download --container-name test-container-02 --name test2.txt --file D:\TEST\test2-upload.txt --account-name $AZURE_STORAGE_ACCOUNT --account-key $AZURE_STORAGE_KEY
{
  "container": "test-container-02",
  "content": "",
  "contentMd5": null,
  "deleted": false,
  "encryptedMetadata": null,
  "encryptionKeySha256": null,
  "encryptionScope": null,
  "hasLegalHold": null,
  "hasVersionsOnly": null,
  "immutabilityPolicy": {
    "expiryTime": null,
    "policyMode": null
  },
  "isAppendBlobSealed": null,
  "isCurrentVersion": null,
  "lastAccessedOn": null,
  "metadata": {},
  "name": "test2.txt",
  "objectReplicationDestinationPolicy": null,
  "objectReplicationSourceProperties": [],
  "properties": {
    "##### 생략 #####"

 

D:\TEST\ 경로 확인 시 test2-upload.txt 파일을 확인할 수 있습니다.

 

 


 

Azure CLI를 통해 이미 생성된 스토리지 계정에 액세스 키를 사용하여 컨테이너를 생성하고 파일을 업로드 및 다운로드 해봤습니다. 컨테이너 생성은 az storage container create 명령어로, 파일 업로드는 az storage blob upload, 파일 다운로드는 az storage blob download 명령어를 사용합니다. 업로드된 파일 목록을 확인하려면 az storage blob list 명령어를 사용합니다.

 

Azure 콘솔을 통해서도 위 작업을 동일하게 할 수 있지만, CLI를 통해 작업이 필요한 경우에는 위 방법을 활용하여 사용하시기 바랍니다.

 

지금까지 CLI 명령어를 통해 Blob Storage 생성 및 사용하는 방법에 대해 알아보는 시간을 가졌습니다....! 끝...!

 

 

 

[Reference]
https://learn.microsoft.com/ko-kr/azure/storage/blobs/storage-quickstart-blobs-cli

 

 

 

[Azure] Blob Storage 생성 및 기초 사용법


Azure Blob Storage는 대규모 비정형 데이터(이미지, 동영상, 로그 등)를 저장하고 관리할 수 있는 Microsoft Azure의 객체 스토리지 서비스입니다. 세 가지 저장소 유형(블록 블롭, 애플리케이션 블롭, 페이지 블롭)을 제공하여 다양한 데이터 요구에 맞게 최적화할 수 있습니다. 뛰어난 확장성과 고가용성을 제공하여 백업, 아카이브, 빅데이터 분석 등에 적합합니다.

 

Azure 콘솔을 통해 Blob Storage를 생성하고 기본적인 사용법을 알아보겠습니다.

 


 

스토리지 계정

Azure 스토리지 계정은 Azure의 모든 스토리지 서비스(Blob, Queue, Table, File)를 관리하고 접근하는 기본 단위입니다. 다양한 스토리지 유형과 성능 계층을 선택할 수 있으며, 고가용성과 보안, 확장성을 제공하며, 이를 통해 데이터 저장, 백업, 복구, 빅데이터 분석 등 다양한 요구를 효율적으로 처리할 수 있습니다.

 

Blob Storage를 생성하기 위해서는 사전에 스토리지 계정을 생성해야 됩니다.

 


Azure 콘솔의 스토리지 계정 메뉴에서 만들기를 선택합니다.

 

스토리지 계정 이름은 소문자와 숫자만 사용할 수 있습니다.

구독, 리소스 그룹, 지역 등의 옵션을 추가적으로 선택하며, 추가적인 옵션이 필요한 경우 고급, 네트워킹, 데이터 보호 등의 옵션을 추가적으로 선택 후 스토리지 계정을 생성합니다.

 


생성된 스토리지 계정은 동일한 메뉴에서 확인 가능합니다.

 

 


스토리지 컨테이너 생성

Azure 스토리지 컨테이너는 Azure Blob Storage 내에서 블롭 데이터를 논리적으로 그룹화하고 관리하는 단위입니다. 각 컨테이너는 무제한의 블롭을 포함할 수 있으며, 개별 블롭에 대한 접근 권한 및 정책을 설정할 수 있으며, 이를 통해 데이터 조직, 접근 제어, 보안 관리를 효과적으로 수행할 수 있습니다.

 

데이터 스토리지의 컨테이너 메뉴를 통해 컨테이너를 생성할 수 있습니다.

 

 

컨테이너 이름 설정 후 만들기를 통해 컨테이너를 생성합니다.

 

 

생성 완료된 컨테이너를 클릭 후 들어가보면 아래와 같이 파일을 업로드하거나 관리할 수 있습니다.

 

 


콘솔을 통한 파일 업로드 및 다운로드

컨테이너에 파일을 업로드하고, 업로드 완료된 파일을 다운로드 해보도록 하겠습니다.

 

업로드 버튼을 클릭 후 파일을 드래그하거나 파일 찾아보기로 선택 후 업로드 합니다.

 

 

업로드 성공 팝업 알림과 함께 컨테이너에 test.txt 파일이 업로드되었음을 확인하였습니다.

 

 

test.txt 파일을 선택하면 해당 파일에 대한 정보를 확인할 수 있으며, 다운로드 버튼을 클릭하여 파일을 다운로드 받을 수 있습니다.

 

 


URL을 통한 파일 다운로드

파일 선택 시 스토리지 계정 및 컨테이너 이름 정보가 포함되어 있는 URL 정보를 통해 파일 다운로드가 가능합니다.

 

 

URL 정보를 웹 브라우저에서 입력하여 해당 파일을 다운로드 시 아래와 같이 권한 오류가 발생하는데요.

 

 

기본적으로 스토리지 계정에 Blob 익명 액세스 옵션이 사용 안 함으로 설정되어 있어 URL을 통해 외부에서 바로 다운로드가 불가합니다.

 

 

따라서 Blob 익명 액세스 옵션을 사용하거나 SAS(공유 액세스 서명) 토큰을 발급 후 URL 정보에 추가하여 다운로드 해야됩니다.

 

공유 액세스 토큰 메뉴에서 생성한 토큰 값을 복사 후 URL 정보 뒤에 추가하면 권한 오류 없이 파일을 다운로드 할 수 있습니다.

https://everyuptest.blob.core.windows.net/test-container-01/test.txt?sp=r&st=2024-06-07T04:16:39Z&se=2024-06-07T12:16:39Z&spr=https&sv=2022-11-02&sr=c&sig=################################

 

 


 

Azure Blob Storage를 생성하고 사용하는 방법으로, 먼저 스토리지 계정을 생성하고 그 안에 컨테이너를 만듭니다. 컨테이너에 파일을 업로드하고 다운로드하며, 외부 접근을 위해 SAS 토큰을 사용해 URL에 권한을 부여합니다. 이를 통해 대규모 비정형 데이터를 효율적으로 저장하고 관리할 수 있습니다.

 

Azure Blob Storage를 통해 장기 보관이 필요한 데이터를 저장하고나, 대규모 비정형 데이터를 분석하는 등 다양한 방법으로 활용하여 사용하시기 바랍니다.

 

지금까지 Blob Storage 생성 및 사용하는 방법에 대해 알아보는 시간을 가졌습니다....! 끝...!

 

 

 

[Reference]
https://learn.microsoft.com/ko-kr/azure/storage/blobs/storage-blobs-introduction

 

 

 

[Azure] CLI(az) 설치 및 로그인 방법

 

Azure CLI (Command-Line Interface)는 Microsoft Azure 리소스를 관리하는 데 사용되는 도구입니다.
명령어 기반으로 Azure 서비스의 배포, 관리 및 모니터링을 자동화할 수 있으며, Windows, macOS, Linux 등 다양한 운영 체제에서 실행 가능합니다. 직관적인 명령어와 스크립트를 통해 효율적으로 클라우드 작업을 처리할 수 있습니다.

 

Azure CLI를 설치하고 로그인 하는 방법을 확인해보도록 하겠습니다.

 

 


 

설치 파일 다운로드

Windows OS 환경에서 Azure CLI를 사용하기 위해 아래 링크를 통해 설치 파일을 다운로드 하였습니다.
https://learn.microsoft.com/ko-kr/cli/azure/install-azure-cli-windows?tabs=azure-cli

 

 


 

설치 파일 실행 및 설치

다운로드 받은 azure-cli 설치 msi 파일을 실행합니다.

 

설치 시 중요하게 선택해야되는 옵션 등은 없습니다.

 

 


 

설치 확인

설치가 완료되면 CMD나 Powershell 등에서 Azure CLI의 az 명령어를 통해 사용할 수 있습니다.
az version 명령어를 통해 설치된 Azure CLI 버전을 확인할 수 있습니다.

 

 


 

로그인 및 확인

Azure CLI의 az login 명령어를 통해 로그인하여 사용할 수 있습니다.

 


Microsoft 계정 로그인 팝업이 출력되며 해당 로그인을 통해 로그인을 진행합니다.

 



로그인 완료 후에는 az account show 명령어를 통해 로그인된 계정의 정보를 확인하실 수 있으며, 로그인한 계정의 권한을 통해 Azure 리소스들을 관리 및 사용하실 수 있습니다.

az account show
{
  "environmentName": "AzureCloud",
  "homeTenantId": "########-####-####-####-############",
  "id": "########-####-####-####-############",
  "isDefault": true,
  "managedByTenants": [],
  "name": "TEST-구독",
  "state": "Enabled",
  "tenantDefaultDomain": "#########.onmicrosoft.com",
  "tenantDisplayName": "################",
  "tenantId": "########-####-####-####-############",
  "user": {
    "name": "########@#########.onmicrosoft.com",
    "type": "user"
  }
}

 

 


 

Azure CLI는 Microsoft Azure 리소스를 관리하는 도구로, 다양한 운영 체제에서 사용 가능합니다.
설치 파일을 다운로드하여 실행하고, az version 명령어로 설치 확인 후, az login 명령어를 통해 Azure에 로그인합니다. 로그인 후 az account show 명령어로 계정 정보를 확인할 수 있으며 그 외의 다양한 Azure CLI 명령어를 통해 Azure를 관리할 수 있습니다.

 

다양한 Azure CLI를 통해 다양한 Azure의 리소스들을 관리 및 사용하시기 바랍니다.

지금까지 Azure CLI (Command-Line Interface)를 설치 및 로그인을 해보는 시간을 가졌습니다....! 끝...!

 

 

 

[Reference]
https://learn.microsoft.com/ko-kr/cli/azure/install-azure-cli

 

 

 

[Azure] 가상 머신(VM) 중첩 가상화 구축하기


중첩 가상화란 Azure와 AWS와 같은 클라우드 컴퓨팅 서버에 중첩으로 Hyper-V, VirtualBox, VMware Workstation과 같은 가상화 환경을 사용하는 것입니다. 가상화를 사용하기 위해서는 기본적으로 CPU에 Virtualization 옵션이 BIOS에서 활성화되어 있어야 하지만, 기본적으로 Azure와 AWS에서 제공하는 컴퓨팅 서버에는 해당 옵션이 활성화 되어 있지 않습니다.

 

Azure를 기준으로는 특정 가상머신(VM) 크기를 사용해야 하며, 가상 머신 생성 시에도 별도의 옵션이 필요합니다. 해당 설정을 통해 Azure에서 중첩 가상화를 사용할 수 있도록 구축해보겠습니다.

 

 


 

가상 머신 크기

Azure에서는 중첩 가상화를 위해 nested virtualization을 지원하는 가상머신을 사용해야 된다고 합니다. 중첩 가상화를 지원하지 않는 가상 머신의 크기를 사용한다면 가상화 환경 사용 시 관련 기능이 필요하다고 경고창이 팝업됩니다.

 

nested virtualization을 지원하는 가상머신은 아래와 같습니다.
https://learn.microsoft.com/en-us/azure/virtual-machines/acu

 

Overview of the Azure Compute Unit - Azure Virtual Machines

Overview of the concept of the Azure compute units. The ACU provides a way of comparing CPU performance across Azure SKUs.

learn.microsoft.com

 

기본적으로 많이 사용하는 스탠다드 크기인 Dsv3 크기를 주로 많이 사용할 것으로 예상되며,
CPU, Memory 특화 크기인 Fsv2, Esv3 크기도 있습니다.

 

 


 

가상 머신 생성 시 옵션

Azure에서 가상 머신 생성 시 옵션도 필수입니다.
보안 유형을 "신뢰할 수 있는 시작 가상 머신"이 아닌 "표준"을 반드시 선택해야 됩니다.

 

 

중첩 가상화는 "신뢰할 수 있는 시작 가상 머신" 에서는 지원되지 않으므로 "표준"을 선택해야 된다고 합니다.
자세한 내용은 아래 링크를 통해 추가적인 정보를 확인해주시기 바랍니다.
https://learn.microsoft.com/en-us/answers/questions/1328431/enable-virtualization-in-windows-10-azure-vm

 

Enable Virtualization in windows 10 azure vm - Microsoft Q&A

Hi, I am using an azure VM, Windows 10 Enterprise, version - 21H2, OS build - 19044.3086. I am installing WSL2 and installed Ubuntu from windows store on it, for this I enabled nested virtualization using -…

learn.microsoft.com

 

추가적으로 보안 유형을 "신뢰할 수 있는 시작 가상 머신"으로 선택한 가상머신은 "표준"으로 변경이 불가하므로 처음에 선택 시 잘 확인하여 보안 유형을 설정할 수 있도록 합니다.

 


 

가상화 서버 VirtualBox 설치

가상화 환경을 구축하기 위해 Azure 가상 머신으로 Windows 11 pro OS를 설치하였습니다.
OS 설치 이후에는 VM 서버로 VirtualBox를 설치하였습니다.

 

간단히 가상 머신을 생성하고 정상적으로 실행되는지 확인해봅시다.

 

 

가상 머신 크기와 보안 유형을 선택하지 않을 경우에는 가상 머신을 실행하면 오류가 발생합니다.
가상화를 지원하지 않는다는 오류가 발생하며 가상 머신의 크기 및 보안 유형을 다시 한번 확인해보시기 바랍니다.

 


 

 

중첩 가상화는 클라우드 환경에서 더 깊은 가상화 층을 추가함으로써 복잡한 IT 인프라 요구사항을 충족할 수 있는 기능입니다. Azure에서 중첩 가상화를 활용하기 위해서는 특정 크기의 가상 머신을 선택하고, 보안 유형을 '표준'으로 설정해야 합니다.

 

이러한 조치를 통해 VirtualBox와 같은 가상화 플랫폼을 설치하고 추가 가상 머신을 운영할 수 있습니다. 개발 및 테스트 환경의 구축을 손쉽게 구축하고, 유연하고 확장 가능한 작업 환경 사용하시기 바랍니다.

 

지금까지 Azure에서 중첩 가상화를 구축해보는 시간을 가졌습니다....! 끝...!

 

 

 

[Reference]
https://learn.microsoft.com/en-us/azure/virtual-machines/acu
https://learn.microsoft.com/en-us/answers/questions/1328431/enable-virtualization-in-windows-10-azure-vm

 

 

 

[GitHub Actions] push 이벤트로 트리거 구성하기


GitHub Actions의 workflows는 소프트웨어 개발 과정에서 자동화된 작업을 정의합니다. 이를 통해 코드 푸시, 풀 요청 또는 다른 GitHub 이벤트에 반응하여 테스트, 빌드, 배포와 같은 CI/CD 작업을 실행할 수 있습니다.

 

GitHub Actions workflows에서 on 구문을 사용하여 이벤트를 트러거할 수 있습니다. 다양한 이벤트를 지원하며 특정 이벤트가 발생했을 때 자동으로 실행되어 CI/CD 자동화 작업을 구성할 수 있습니다. push 이벤트를 트리거하여 CI/CD 자동화 작업을 구성해보도록 하겠습니다.

 

 


개요

GitHub Actions의 on 구문은 workflows가 어떤 이벤트에 의해 트리거될 것인지를 정의하는 핵심 요소입니다.
이 구문을 통해 GitHub 리포지토리에서 발생하는 다양한 이벤트를 통해 자동화된 작업을 실행할 수 있습니다.
on 구문의 사용은 workflows의 유연성을 확장시켜 활용도 높게 사용할 수 있습니다.

on 구문 기본 구조

on: 
  [event_name]:
    [options]:

 


push 이벤트

GitHub Actions에서 push 이벤트는 가장 일반적으로 사용되는 트리거 중 하나입니다.


push 이벤트는 리포지토리에 커밋이 푸시될 때 발생합니다.workflows 파일에서 on: push 구문을 사용하면 특정 조건 하에 이 이벤트가 발생할 때마다 워크플로우가 실행되도록 설정할 수 있습니다.

 

 

기본 사용법

on: push
  • 리포지토리의 어느 브랜치에든 커밋이 푸시될 때마다 workflows가 실행되도록 설정하였습니다.

 

 

브랜치 제한

on:
  push:
    branches:
      - main
  • branches 옵션을 통해 main 브랜치에 푸시될 때만 workflows가 실행되도록 설정하였습니다.
  • 복수의 브랜치를 지정하고 싶다면 브랜치 목록에 추가하면 됩니다.

 

on:
  push:
    branches-ignore:
      - 'dev'
      - 'experiment/*'
  • branches-ignore 옵션을 통해 "dev" 브랜치와 "experiment/" 로 시작하는 모든 브랜치에 대한 푸시 이벤트를 무시하고 workflows 또한 실행되지 않도록 설정하였습니다.
  • 이는 주로 안정적인 빌드나 배포 프로세스에 집중하고, 아직 개발 중이거나 실험적인 브랜치의 변경사항으로 인한 workflows 실행을 방지하고자 할 때 유용합니다.

 

branches 옵션과 branches-ignore 옵션을 동시에 사용하면 아래 오류가 발생합니다.

you may only define one of `branches` and `branches-ignore` for a single event
  • branches 옵션과 branches-ignore 옵션은 동시에 사용할 수 없으며, 이 오류를 해결하기 위해서는 하나의 이벤트에 대해 branches 옵션 또는 branches-ignore 옵션을 사용해야 합니다.

 


태그 제한

on:
  push:
    tags:
      - 'v1.*'
  • tags 옵션은 "v1." 이름으로 시작되는 모든 태그에 푸시될 때만 workflows가 실행되도록 설정하였습니다.
  • 복수의 태그를 지정하고 싶다면 태그 목록에 추가하면 됩니다.

 

on:
  push:
    tags-ignore:
      - '*beta'
  • tags-ignore 옵션은 branches-ignore 옵션과 유사하며 "beta" 로 끝나는 모든 태그에 대한 푸시 이벤트를 무시하고 workflows 또한 실행되지 않도록 설정하였습니다.

 

branches 옵션과 branches-ignore 옵션과 동일하게 tags 옵션과 tags-ignore 옵션을 같이 사용하면 아래 오류가 발생합니다.

you may only define one of `tags` and `tags-ignore` for a single event
  • tags 옵션과 tags-ignore 옵션을 동시에 사용할 수 없으며, 이 오류를 해결하기 위해서는 하나의 이벤트에 대해 tags  옵션 또는 tags-ignore 옵션을 사용해야 합니다.

 


패턴을 사용한 제한

on:
  push:
    branches:
      - 'feature/*'
      - 'releases/**'
      - '!releases/**-test'
    tags:
      - 'v1.[0-9].[0-9]'
  • "feature/" 로 시작하는 모든 브랜치 이름을 가진 브랜치에 푸시될 때 workflows가 실행되도록 설정하였습니다.
  • "releases/" 아래의 모든 하위 브랜치 이름을 가진 브랜치에 푸시될 때 workflows가 실행되도록 설정하였습니다.
    • 하지만 "releases/" 하위 브랜치 중 "-test" 로 끝나는 브랜치는 제외합니다.
  • "v1." 로 시작하고 그 다음에 숫자가 오는 태그(예: v1.0.0, v1.2.9, ...)에 대한 푸시 이벤트 발생 시 workflows가 실행되도록 설정하였습니다.
  • branches-ignore 옵션와 tags-ignore 옵션에서도 패턴을 사용할 수 있습니다.
  • 다양한 패턴을 통해 workflows를 구분하여 실행할 수 있습니다.

 

 

경로 및 파일 변경사항을 통한 제한

on:
  push:
    paths:
      - '**/*.js'
  • paths 옵션은 설정한 파일이 변경될 경우에만 워크플로우가 실행하는 옵션입니다.
  • ".js" 확장자를 가진 파일이 변경되어 푸시될 때만 워크플로우가 실행되도록 설정하였습니다.

 

 

on:
  push:
    paths-ignore:
      - 'docs/**'
  • paths-ignore 옵션은 설정한 파일이 변경되면 워크플로우를 실행하지 않는 옵션입니다.
  • "docs/" 디렉토리 내의 어떤 변경사항에도 워크플로우가 실행되지 않도록 설정하였습니다.

 

 


 

GitHub Actions의 on 구문과 push 옵션을 통해 push 이벤트 발생 시 workflows 실행되도록 설정해봤습니다.

 

GitHub Actions의 on 구문을 활용하면 리포지토리에서 발생하는 다양한 이벤트에 대응하여 workflows를 자동으로 실행할 수 있습니다. 특히, push 이벤트는 소프트웨어 개발 과정에서 매우 흔하게 발생하는 이벤트로, 이에 대해 workflows를 구성함으로써 코드의 푸시, 빌드, 테스트, 배포 등의 CI/CD 작업을 자동화할 수 있습니다.


branches, branches-ignore, tags, tags-ignore, paths, paths-ignore 등의 옵션을 사용하여 특정 조건에서만 workflows가 실행되도록 세밀하게 설정할 수 있습니다. 하지만 branches와 branches-ignore, tags와 tags-ignore는 각각 동시에 사용할 수 없으며, 이를 위반할 경우 오류가 발생함을 유의해야 합니다.

 

workflows의 다양한 옵션을 사용하여 workflows의 효율성과 유용성을 극대화하여 사용하시기 바랍니다.
지금까지 push 이벤트를 트리거하여 다양한 옵션을 통해 workflows를 실행해보는 시간을 가졌습니다....! 끝...!

 

 

 

[Reference]
https://docs.github.com/ko/actions/using-workflows/events-that-trigger-workflows

 

 

 

[GitHub Actions] workflows 이름 설정하기

GitHub Actions의 workflows는 소프트웨어 개발 과정에서 자동화된 작업을 정의합니다. 이를 통해 코드 푸시, 풀 요청 또는 다른 GitHub 이벤트에 반응하여 테스트, 빌드, 배포와 같은 CI/CD 작업을 실행할 수 있습니다.

 

GitHub Actions의 하나의 작업을 workflows라고 정의하는데요. name 설정과 run-name 설정을 통해 workflows와 workflow runs 이름을 설정하여 사용할 수 있습니다. 해당 설정을 활용하여 workflows 이름을 설정해보도록 하겠습니다.

 


"name", "run-name" 미설정 시 기본 이름

GitHub Action을 통해 workflows 실행 시 기본적으로 설정되는 이름을 확인해봅시다.

 

예시 코드

run_name_demo.yml 이름의 workflow 파일을 생성하였으며 간단히 echo 명령어로 Text를 출력하도록 설정하였습니다. commit 메시지는 "[Action] Test run_name_demo"로 지정 후 push하여 workflows를 실행하도록 하였습니다.

> run_name_demo.yml

on: 
  push:

jobs:
  Jobs-Names-run_name_demo-01:
    runs-on: ubuntu-latest
    steps:
      - name: Echo Test
        run: echo "Run Workflows - run_name_demo"

 

실행 결과

workflows 이름 설정인 name 설정을 하지 않을 경우 생성되는 이름을 확인해보도록 하겠습니다.
workflows 이름은 파일 경로인 .github/workflows/run_name_demo.yml으로 생성되었습니다.
별도로 name 설정을 하지 않으면 workflows 이름은 파일 이름으로 생성되는 것을 확인하실 수 있습니다.

 


자 이제는 workflow runs 이름을 확인해보도록 하겠습니다.
run 이름은 commit 메시지인 [Action] Test run_name_demo으로 생성되었습니다.
별도로 run-name 설정을 하지 않으면 workflow runs 이름은 commit 메시지로 생성되는 것을 확인하실 수 있습니다.

 

 


 

"name", "run-name" 기본 설정

GitHub Action을 통해 workflows 실행 시 name, run-name 설정을 통해 이름을 설정해봅시다.

 

예시 코드

workflows 이름을 설정하기 위해 name, run-name 옵션을 사용하여 이름을 설정하였습니다.

> run_name_demo.yml

name: Workflows Names - run_name_demo
run-name: Runs Names - run_name_demo 🚀

on: 
  push:

jobs:
  Jobs-Names-run_name_demo-01:
    runs-on: ubuntu-latest
    steps:
      - name: Echo Test
        run: echo "Run Workflows - run_name_demo"

 

 

실행 결과

설정한 name 옵션으로 "Workflows Names - run_name_demo" 이름의 workflows가 생성되었습니다.

 

 

또한 설정한 run-name 옵션으로 "Runs Names - run_name_demo 🚀" 이름의 workflow runs이 생성되었습니다.

 

 


"name", "run-name" 설정 활용

GitHub Action의 name, run-name 설정을 활용해보도록 하겠습니다.


활용해볼 설정은 run-name 설정입니다. run-name 설정은 githubinputs 컨텍스트를 사용하여 동적으로 구성할 수 있습니다.

 

예시 코드 및 실행 결과

이벤트 이름을 workflow runs 이름에 추가하기 위해 run-name 설정에 github 컨텍스트를 추가하였습니다.

run-name: Run_Names [ ${{ github.event_name }} ]

 

workflow runs 이름에 이벤트 이름을 확인하실 수 있습니다.

 

 

 

이번에는 branch 및 tag 정보를 추가해봤습니다.

run-name: Run_Names [ ${{ github.ref_type }} ]  [ ${{ github.ref_name }} ]

 

workflow runs 이름에 트리거된 branch 및 tag 타입과 이름을 확인하실 수 있습니다.

 

 

 

이번에는 workflows 실행자와 마지막 commit 시간 정보를 추가해봤습니다.

run-name: Run_Names [ ${{ github.actor }} ] [ ${{ github.event.head_commit.timestamp }} ]

 

workflow runs 이름에 workflows 실행자와 마지막 commit 시간을 확인하실 수 있습니다.

 

위 활용 방법과 같이 run-name 설정은 githubinputs 컨텍스트를 사용하여 동적으로 구성할 수 있습니다.


다만 아쉬운 점은 githubinputs 컨텍스트만 사용 할 수 있다는 점과 Job(작업)에서 활용된 변수나 결과에 따른 이름을 설정할 수 없다는 부분이 아쉽습니다. 또한 githubinputs 컨텍스트를 사용한다고 해도 원하는 형식의 문자열로 변환하거나 출력할 수 없습니다. 이러한 부분이 아쉽지만 github 컨텍스트 정보에는 많은 정보가 있기 때문에 잘 활용할 경우 유용하게 사용할 수 있을 것 같습니다.

 

 


 

GitHub Actions의 name, run-name 설정을 통해 workflows 이름과 workflow runs 이름을 지정해봤습니다.

 

name 설정은 workflows 이름을 지정하며, GitHub 저장소의 "Actions" 탭에 표시됩니다.

run-name 설정은 workflow runs 탭에 표시되며 이벤트 이름, 브랜치 또는 태그 정보, 워크플로우 실행자, 마지막 커밋의 타임스탬프 등과 같은 동적 정보를 포함시킬 수 있습니다

 

GitHub Actions의 namerun-name 설정은 workflows와 workflows run을 명확하게 식별하고 조직화하는 데 매우 중요합니다. 이 설정들을 적절히 활용하면 workflows 관리의 효율성을 높일 수 있습니다. 특히 run-name 설정을 통해 workflow runs의 동적 이름을 구성함으로써, 각 실행의 세부 사항을 쉽게 파악하고 필요에 따라 신속하게 대응할 수 있습니다.

 

GitHub Actions를 사용할 때는 이러한 설정들을 적극적으로 활용하여 더욱 효과적인 워크플로우 관리를 해보시기 바랍니다. 지금까지 name 설정과 run-name 설정을 통해 workflows와 workflow runs 이름을 설정하여 사용해보는 시간을 가졌습니다....! 끝...!

 

 

 

[Reference]
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions
https://docs.github.com/en/actions/learn-github-actions/contexts

 

 

 

[GitHub Actions] actions artifact 기능을 통한 데이터 공유 및 저장

GitHub Actions의 workflow는 소프트웨어 개발 과정에서 자동화된 작업을 정의합니다. 이를 통해 코드 푸시, 풀 요청 또는 다른 GitHub 이벤트에 반응하여 테스트, 빌드, 배포와 같은 CI/CD 작업을 실행할 수 있습니다.

 

GitHub Actions에는 CI/CD 작업을 위해 다양한 기능이 있으며 이번에 테스트할 기능은 actions/upload-artifact, actions/download-artifact 기능입니다. actions/upload-artifact, actions/download-artifact 기능은 workflow 동안 생성된 파일이나 디렉토리 등을 저장하고 활용할 수 있도록 해줍니다.

 


개요

GitHub Actions의 actions/upload-artifact는 workflow 실행 중에 생성된 파일이나 데이터를 GitHub에 업로드하여 저장하는 기능입니다. 이를 통해 작업이 끝난 후에도 데이터를 보존하고 사용할 수 있습니다.


actions/download-artifact는 저장된 아티팩트를 나중에 다운로드할 수 있게 해주어, 같은 workflow 내의 이후 작업에서 데이터를 사용하거나 공유할 수 있게 해줍니다.


이 두 기능을 통해 CI/CD 파이프라인에서 빌드 결과나 테스트 결과와 같은 중요한 데이터를 관리하고 전달할 수 있습니다.

- name: Upload Artifact text_dir
  uses: actions/upload-artifact@v4
  with:
    name: text_dir-artifact
    path: text_dir

- name: Download Artifact text_dir
  uses: actions/download-artifact@v4
  with:
    name: text_dir-artifact

 


사용 범위 및 제한 사항

사용 범위

  • workflow가 생성한 파일이나 디렉토리를 아티팩트로 업로드하여, GitHub에서 호스팅하는 동안 해당 데이터를 보존합니다.
  • 빌드 결과, 로그 파일, 테스트 결과, 바이너리 파일 등의 저장에 사용됩니다.
  • 이미 업로드된 아티팩트를 다운로드하여 workflow가 완료된 후에도 아티팩트를 활용할 수 있습니다.

 

제한 사항

  • 아티팩트의 기본 보관 기간은 90일입니다. 이 기간은 설정을 통해 조정할 수 있으나, 최대 90일로 제한됩니다.
  • 저장 공간과 데이터 전송량은 GitHub Actions의 사용 한도에 포함되어 비용에 청구됩니다.
  • workflow 실행 단위로 아티팩트를 관리하며, 이전 워크플로우 실행에서 생성된 아티팩트를 다운로드할 수는 없습니다.
  • workflow 실행의 각 작업에는 아티팩트가 500개로 제한됩니다.

 


artifact vs cache 간단 비교

아티팩트와 캐싱은 GitHub에 파일을 저장하는 기능을 제공한다는 점에서 유사하지만 각 기능은 서로 다른 사용 사례를 제공하며 서로 바꿔서 사용할 수 없습니다.

  • 패키지 관리 시스템의 빌드 종속성과 같이 작업이나 워크플로 실행 간에 자주 변경되지 않는 파일을 재사용하려는 경우 캐싱을 사용합니다.
  • 워크플로 실행이 종료된 후 보기 위해 작업에서 생성된 파일(예: 빌드된 바이너리 또는 빌드 로그)을 저장하려는 경우 아티팩트를 사용합니다.

 


예시 코드

예시 코드의 workflow는 push 이벤트가 발생할 때마다 실행되도록 설정하였습니다. 또한 두 개의 작업(Job)을 구성하여 첫 번째 작업에서 파일을 저장하고, 두 번째 작업에서 저장 파일을 사용하도록 구성하였습니다.

actions/upload-artifact 코드

jobs:
  Jobs-Names-actions_artifact_demo-01:
    runs-on: ubuntu-latest
    steps:
      - name: Make text_dir
        run: mkdir text_dir

      - name: Create File
        run: touch text_dir/test-$(date "+%H%M%S")-01

      - name: Check File
        run: ls -al text_dir/*

      - name: Upload Artifact text_dir
        uses: actions/upload-artifact@v4
        with:
          name: text_dir-artifact
          path: text_dir/**
          retention-days: 5

 

mkdir 명령어와 touch 명령어를 통해 text_dir 디렉토리에 파일을 생성하였습니다.
생성한 파일은 actions/upload-artifact 기능을 통해 아티팩트로 저장하였습니다.
name 설정으로 저장되는 아티팩트 이름을 지정하고, path 설정으로 경로를 지정하였습니다.
retention-days 옵션은 아티팩트 보관 기간 설정이며 필수 설정은 아닙니다.

 

actions/download-artifact 코드

Jobs-Names-actions_artifact_demo-02:
  needs: Jobs-Names-actions_artifact_demo-01
  runs-on: ubuntu-latest
  steps:
    - name: Check File
      run: ls -al

    - name: Download Artifact text_dir
      uses: actions/download-artifact@v4
      with:
        name: text_dir-artifact
        path: text_dir

    - name: Check File
      run: ls -al text_dir/*

 

actions/upload-artifact 기능을 통해 저장된 아티팩트를 저장하였습니다.
name 설정으로 앞서 저장된 아티팩트의 이름을 지정하였으며, path 설정으로 다운받을 경로를 지정하였습니다.
path 설정이 없다면 기존 workspace 경로($GITHUB_WORKSPACE)에 저장되므로 특정 경로에 저장이 필요하다면 설정이 필요합니다.

 


실행

자 이제 예시 코드를 실행하여 actions/upload-artifact, actions/download-artifact 기능을 통한 데이터 저장 및 다운을 확인해보겠습니다.

 

설정한 workflow가 실행되었습니다.

 

 

01번 작업에서 mkdir 명령어와 touch 명령어를 통해 text_dir 디렉토리에 파일을 생성하였습니다.

 

 

01번 작업에서 actions/upload-artifact 기능을 통해 파일을 저장하였습니다.
저장시 아티팩트는 text_dir-artifact 이름으로 저장되었습니다.

 

 

자 이번에는 02번 작업에서 actions/download-artifact 기능을 통해 파일을 다운받아보도록 하겠습니다.
앞서 저장한 text_dir-artifact 이름의 아티팩트를 지정하였으며 text_dir 경로에 다운된 것을 확인하였습니다.

 

 

추가로 해당 workflow를 확인해보면 저장된 아티팩트를 GitHub에서 직접 다운로드 받을 수 있습니다.
저장 이름은 앞서 설정한 text_dir-artifact 이름으로 저장됩니다.

 


 

GitHub Actions의 actions/upload-artifact와 actions/download-artifact 기능을 통해 소프트웨어 개발 과정에서 생성된 데이터를 저장하고 공유할 수 있어, CI/CD 파이프라인의 효율성과 유연성이 크게 향상됩니다. 또한 빌드 결과, 로그 파일, 테스트 결과 등의 중요한 데이터를 쉽게 참조하고 이후 작업이나 다른 작업에서 활용할 수 있습니다.

 

그러나 아티팩트의 보관 기간, 저장 공간, 데이터 전송량에 대한 제한 사항이 있어 이를 고려해야 합니다. 실제 테스트에서는 actions/upload-artifact로 데이터를 업로드하고 actions/download-artifact로 다운로드하여 성공적으로 파일을 사용하는 것을 확인했습니다. 이러한 기능들은 다양하게 활용하여 CI/CD 자동화 시 효율성을 높여보시기 바랍니다.

 

지금까지 actions/upload-artifact와 actions/download-artifact 기능을 통해 workflow에서 생성한 데이터를 저장하고 공유해보는 시간을 가졌습니다....! 끝...!

 

 

 

[Reference]
https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts

 

 

 

[GitHub Action] actions/cache 기능을 통한 데이터 캐싱


GitHub Action의 GitHub Actions의 workflow는 소프트웨어 개발 과정에서 자동화된 작업을 정의합니다. 이를 통해 코드 푸시, 풀 요청 또는 다른 GitHub 이벤트에 반응하여 테스트, 빌드, 배포와 같은 CI/CD 작업을 실행할 수 있습니다.

 

GitHub Actions에는 CI/CD 작업을 위해 다양한 기능이 있으며 이번에 테스트할 기능은 actions/cache 기능입니다. actions/cache 기능은 workflow 간에 파일을 캐싱하고 공유할 수 있습니다.

 


개요

GitHub Actions의 actions/cache는 workflow 간에 파일을 캐싱하여 실행 시간을 줄입니다. 사용자는 key와 path를 설정하여 캐시를 구성하며, 동일한 key가 있을 경우 기존 캐시를 재사용합니다. actions/cache 기능을 통해 의존성 다운로드, 빌드 결과 캐싱 등에 사용할 경우 유용합니다.

- name: Cache node modules
  uses: actions/cache@v2
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

 


Cache Hit & Miss

GitHub Actions에서 actions/cache를 사용할 때, "Cache Hit"과 "Cache Miss"는 중요한 개념입니다.

 

  • 캐시 히트(Cache Hit)
    • 요청한 key로 캐시가 이미 존재하면, 해당 캐시가 사용됩니다. 이 경우 새 캐시를 생성하지 않고, 기존 캐시를 사용하여 작업을 빠르게 진행할 수 있습니다.
  • 캐시 미스(Cache Miss)
    • 요청한 key로 캐시가 존재하지 않으면, 새로운 캐시가 생성됩니다. 작업이 완료된 후, 지정된 path에 있는 파일들이 새 key와 함께 캐시됩니다.

 

actions/cache를 사용할 때, 적절한 key 전략을 수립하는 것이 중요합니다. 이미 존재하는 key 값으로 새로운 데이터를 캐싱할 경우 Cache Hit가 발생하며 새 캐시를 생성하지 않습니다.


따라서 새로운 데이터는 캐싱되지 않고 기존에 캐시한 데이터를 불러오도록 동작합니다. 그러므로 key는 고유한 값을 가지도록 파일의 해시값, 사용된 의존성 목록, 환경변수 등을 포함하여 구성됩니다. 이는 key의 고유성을 보장하고, 적절한 시점에 Cache Hit 또는 Miss를 발생시키는 데 사용될 수 있습니다.

 

Cache Hit은 성능을 최적화하는 반면, Cache Miss는 캐시를 최신 상태로 유지하고, 변경사항을 반영할 수 있는 기회를 제공합니다.

 


사용 범위 및 제한 사항

사용 범위

  • 의존성 캐싱
    • node_modules, vendor/bundle, .pip 등과 같은 의존성 디렉터리를 캐시하여, 매번 의존성을 설치하는 시간을 절약할 수 있습니다.
  • 빌드 캐싱
    • 빌드 과정에서 생성되는 아티팩트(예: 컴파일된 소스코드)를 캐시하여, 변경되지 않은 부분은 다시 빌드하지 않도록 할 수 있습니다.
  • 테스트 캐싱
    • 테스트 데이터나 테스트 결과를 캐시하여, 변경되지 않은 테스트는 다시 실행하지 않을 수 있습니다.

 

제한 사항

  • 캐시 크기 제한
    • GitHub Actions는 캐시의 최대 크기를 10GB로 제한하며, 이는 저장소 단위로 적용됩니다.
    • 대용량 파일을 캐시하려는 경우 이 제한에 주의해야 하며, 최대 캐시 스토리지에 도달하면 가장 오래된 캐시를 삭제하여 공간을 생성합니다.
  • 캐시 유지 기간
    • 캐시된 데이터는 최대 7일간 유지됩니다. 7일이 지나면 캐시가 만료되고, 자동으로 삭제됩니다.
    • 장기간에 걸쳐 캐시를 유지하려는 경우에는 이를 고려하여 CI/CD 코드를 작성해야 됩니다.
  • 캐시 공유 제한
    • 캐시는 동일한 GitHub Actions workflow 내에서만 공유됩니다.
    • 다른 저장소나 workflow 간에 캐시를 직접 공유할 수는 없습니다.

 


artifact vs cache 간단 비교

아티팩트와 캐싱은 GitHub에 파일을 저장하는 기능을 제공한다는 점에서 유사하지만 각 기능은 서로 다른 사용 사례를 제공하며 서로 바꿔서 사용할 수 없습니다.

 

패키지 관리 시스템의 빌드 종속성과 같이 작업이나 워크플로 실행 간에 자주 변경되지 않는 파일을 재사용하려는 경우 캐싱을 사용합니다.

 

워크플로 실행이 종료된 후 보기 위해 작업에서 생성된 파일(예: 빌드된 바이너리 또는 빌드 로그)을 저장하려는 경우 아티팩트를 사용합니다.

 


예시 코드

예시 코드의 workflow는 push 이벤트가 발생할 때마다 실행되도록 설정하였습니다. 또한 두 개의 작업(Job)을 구성하여 첫 번째 작업에서 파일을 캐싱하고, 두 번째 작업에서 캐싱된 파일을 복원하도록 구성하였습니다.

> ./.github/workflows/action_caching_demo.yml

name: Workflows Names - action_caching_demo
run-name: Runs Names - action_caching_demo 🚀
on: 
  push

jobs:
  Jobs-Names-action_caching_demo-01:
    runs-on: ubuntu-latest
    steps:
      - name: check all file
        run: ls -al 

      - name: create test file
        run: touch test_file

      - name: check create file
        run: ls -al 

      - name: caching file
        uses: actions/cache@v3
        with:
          path: test_file
          key: ${{ runner.os }}-test-${{ hashFiles('test_file') }}
          restore-keys: |
            ${{ runner.os }}-test-${{ hashFiles('test_file') }}
            ${{ runner.os }}-test-


  Jobs-Names-action_caching_demo-02:
    needs: Jobs-Names-action_caching_demo-01
    runs-on: ubuntu-latest
    steps:
      - name: check all file
        run: ls -al

      - name: caching file
        uses: actions/cache@v3
        with:
          path: test_file
          key: ${{ runner.os }}-test-${{ hashFiles('test_file') }}
          restore-keys: |
            ${{ runner.os }}-test-${{ hashFiles('test_file') }}
            ${{ runner.os }}-test-

      - name: check caching file
        run: ls -al

 

01번 작업에서 touch test_file 명령어를 사용하여 test_file이라는 새로운 파일을 생성 후 캐싱하고자 설정하였습니다.
02번 작업에서 캐싱된 파일을 복구하여 확인하도록 설정하였습니다.

 

캐싱 키는 실행 환경(OS)와 test_file의 해시 값을 기반으로 생성됩니다. 이는 key의 중복 없이 고유성을 보장하고자 설정하였습니다.

 


실행

자 이제 예시 코드를 실행하여 actions/cache 기능을 통한 데이터 캐싱을 확인해보겠습니다.

 

설정한 workflow를 실행하였습니다.

 

 

01번 작업에서 touch test_file 명령어를 사용하여 test_file이라는 새로운 파일을 생성하였습니다.

 

 

01번 작업에서 actions/cache 기능을 통해 test_file이라는 파일을 캐싱하였습니다. 요청한 key로 캐시가 존재하지 않아 Cache Miss가 발생하여 새 key와 함께 새로운 캐시를 생성하였습니다.

 

 

자 이번에는 02번 작업에서 actions/cache 기능을 통해test_file이라는 파일을 복구해보도록 하겠습니다. ls -al 명령어를 통해 파일이 없음을 확인하였으며, actions/cache 기능을 사용하였습니다. 요청한 key로 캐시를 확인하여 파일을 복구하였으며, 다시 ls -al 명령어를 통해 test_file 파일을 확인하였습니다.




 

GitHub Actions의 actions/cache 기능은 워크플로우의 실행 시간을 단축하고 성능을 최적화하기 위한 효율적인 도구입니다. 예시를 통해 test_file 생성 및 캐싱 과정을 통해, 동일한 key를 사용하여 캐시를 재사용하는 과정과 캐시 미스 시 새로운 캐시를 생성하는 방식을 확인하였습니다.


이는 의존성 설치, 빌드 과정의 최적화 및 테스트 데이터의 재사용 등 다양한 상황에서 유용하게 활용될 수 있습니다. 다만, 캐시 크기 제한 및 유지 기간과 같은 제한 사항을 고려하여 워크플로우를 설계해야 합니다.


GitHub Actions의 actions/cache 기능에 대한 이해에 도움이 되었다면 좋겠습니다.

또한 다양한 cache 설정을 통해 CI/CD 자동화 시 효율성을 높여보시기 바랍니다.

 

지금까지 actions/cache 기능을 통해 workflow 간에 파일을 캐싱하고 공유해보는 시간을 가졌습니다....! 끝...!

 

 

 

[Reference]
https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows

 

 

 

+ Recent posts