Please enable JavaScript.

Coggle requires JavaScript to display documents.

Path github actions - Coggle Diagram

- - - - Communication: All of the ways that Github makes it esasy for a team of devs to communicate in the project example code reviews in pull requests, Github issues, projects boards, wikis, notifications, etc
      - Automation: Gh Actions lets your team automate workflows at every step in the Software development process, from integration to delivery to deployment. You can automate adding labels to pull request and checking for stale issues and pull requests
    - - Is to decrease development time
      - Tasks after the code is written but before you can use the code
        
        Ensure the code passes all unit test
        
        Perform code quality and compliance checks to make sure the source code meets the organization's standards
        
        Check the code and its dependencies for known security issues
        
        Build the code integrating new source from multiple contributors
        
        Ensure the software passes integrations tests
        
        Version the new build
        
        Deliver the new binaries to the appropiate filesystem lcation
        
        Deploy the new binaries to one or more servers
        
        If any of these tasks don't pass, report the issue to the proper individual or team for resolution
    - - actions.yml file for inputs, outputs, and to make sure the code does what it says it does
      - Check if the action is in the gh marketplace
      - Check if the actions is verified in the github marketplace
      - Include the version of the actions by specifying a Git ref, sha or tag
  - - - MY_NAME:
        
        description: "descripcion"
        
        required: boolean
        
        default: "World"
    - - uses: "docker"
      - image: "Dockerfile"
    - - icon: "mic"
      - color: "purple"
  - - - name: A workflow for my hello world file
      - on: push
      - jobs:
        
        build:
        
        name: <nombre>
        
        runs-on: ubuntu-latest
        
        steps:
        
        uses: <action>
        
        uses: ./action-a (<action>)
        
        with:
        
        MY_NAME: "mona"
    - - This es a trigger to specify when this workflow will run
      - Se puede especificar un evento simple (on: push), un arreglo on: [push, pull_request] o un mapa de configuración de evento (event-configuration map)
        
        ejemplo
    - - 🗝️ A job is a section of the workflow associated with a runner
  - - - Workflow: A workflow is a unit of automation from its start to finish, including the definition of what triggers the automation, what environment or other aspects should be taken into account during the automation, and what should happen as a result of the trigger.
    - - Job: A job is a section of the workflow, and is made up of one or more steps.
    - - A step represents one effect of the automation. A step could be defined as a GitHub Action, or another unit, like printing something to the console.
    - - Action: An action is a piece of automation written in a way that is compatible with workflows. Actions can be written by GitHub, by the open source community, or you can write them yourself!
  - - - Manual events [workflow_distpatch]
        To run the workflow by using the Gitthub rest API or by selection Run workflow button in the actions tab
      - Activities that occurs outside of GH [repository_dispatch]
        that have a endpoint /repos/{owner}/{repo}/dispatches that capture POST request with the webhook event names in the request body
        
        on: repository_dispatch: types: [opened, deleted]
      - Events on Github
        
        on: check_run: types: [rerequested, requested_action]
    - - on: schedule: - cron: '*/15 * * * *'
    - - if: github.ref == 'refs/heads/main' ${{ <expression> }}
      - https://docs.github.com/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsif
    - - steps: # Reference a specific commit - uses: actions/setup-node@c46424eee26de4078d34105d3de3cc4992202b1e # Reference the major version of a release - uses: actions/setup-node@v1 # Reference a minor version of a release - uses: actions/setup-node@v1.2 # Reference a branch - uses: actions/setup-node@main
- - - - Identify the metadata and syntax needed to create custom GitHub actions.
      - Learn best practices to publish a private or public GitHub action.
      - Consume actions within a workflow file.
      - Create custom JavaScript based actions.
      - Publish a newly created action to the GitHub Marketplace.
  - - - Docker container actions
        
        Docker containers package the environment with the GitHub Actions code
        
        ventaja: consistent and reliable
        
        desventaja, mas lento wque js action
        
        pasos
        
        Create a Dockerfile for docker image
        
        Create an action.yml metadata file to define the inputs an outputs of the action
        setting the runs: using value to dockerand the runs: image: value to Dockerfile in trhe file
        
        Create an entrypoint.sh file to describe the docker image
        
        Commit and push your action to Github with the following files
        action.yml
        entrypoint.sh
        Dockerfile
        README.md
      - Javascript actions
        
        JavaScript actions can run directly on the runner machine, and separate the action code from the environment that's used to run the action
        
        As a prerequisite for creating and using packaged JavaScript actions, you need to download Node.js, which includes npm.
        
        As an optional step (but one that we recommend) is to use GitHub Actions Toolkit Node.js, which is a collection of Node.js packages that allows you to quickly build JavaScript actions with more consistency.
        
        Pasos
        
        Create an action.yml metadata file to define the inputs and outputs of the action, as well as tell the action runner how to start running this JavaScript action.
        
        Create an index.js file with context information about the Toolkit packages, routing, and other functions of the action.
        
        Commit and push your action to GitHub with the following files: action.yml, index.js, node_modules, package.json, package-lock.json, and README.md.
      - composite run steps actions
        
        Composite run steps actions allow you to reuse actions by using shell scripts. You can even mix multiple shell languages within the same action
    - - a great first step is to review the action.yml file to assess which inputs, outputs, description, runs, and other configuration information the action needs.
      - Data action.yml
        
        Name
        The name of your action. Helps visually identify the action in a job, required
        
        Description
        A summary of what your action does, required
        
        Inputs
        Input parameters enable you to specify data that the action expects to use during runtime. GitHub stores these input parameters as environment variables.
        
        example
        
        inputs:
        
        firstNameStudent:
        
        description: 'First name of student'
        
        required: false
        
        default: '1'
        
        studentGrade:
        
        description: 'Grade of the student'
        
        required: true
        
        Outputs
        Output parameters enable you to specify data that subsequent actions can use later in the workflow after the actions that defines these outputs has run
        
        Example
        
        outputs:
        
        average:
        
        description: 'The average grade of the students'
        
        Runs
        The command to run when the action executes, required
        
        Branding
        Colar and Feather icon to use to create a badge to personalize and distinguish your action in Github Marketplace
  - - - Public
        Workflows in any repository can use public actions
        That actions is recommendated has its own repository
      - Private
        In this case only workflows in the same repository can use the action. With private actions, you can store the action's files in any location in your repository.
        If you plan to combine actions, workflow and application code in a single repository, we recommend storing the action in the .github directory. ie .github/actions/action-a
    - - It's important to include good documentation with your action so that others can see how it works
      - The readme.md files is often the first place developers will look at to see how the action works
        This is a great place to include all of the important information for the action
      - List of things to include in the readme
        
        A detailed description of what the action does
        
        Required input and output arguments
        
        Optional input and output arguments
        
        Secrets the action uses
        
        Environment variables the action uses
        
        An example of how to use your action in a workflow
      - As a general rule, the README.md file should include everything a user should know to use the action
    - - If you're developing an action for other people to use you should define a release management strategy to control how uptates are distributed
      - A good release-management strategy should include versioning recommendations and not be referencing an action's default branch. Is recommendated specify a major version when using the action
        They can do this by configuring their GH actions workflow to target a tag, a commmit's SHA or a specific branch named for a release
      - Tags
        By using tags, users can easily distinguish between major an minor versions
        
        Helpful practices when creating releases
        
        Create and validate on a release branch (release/v1) before creating the release tag (v1.0.2)
        
        Use semantic versioning
        
        Move the major version tag to point to the git ref of the current release
        
        Introduce the major version tag for changes that will break existing workflows
        
        Release major versions with a beta tag to indicate their status, ie v2-beta
        
        One downside to using tags is that they can be deleted or moved
      - Use a commit's SHA
        
        With Git, each commit receives a calculated SHA value, which is unique and cannot be modified
        
        Using a commit SHA for versioning will give you the most reliable and secure way to version and use an action
        
        If you're using the commit's SHA for release management, you need to use the full SHA value and not the abbreviated value.
    - - Actions published to the GitHub Marketplace are published immediately if all of the requirements are met
        Actions that don't meet the requirements need to be reviewed by GitHub before being published
      - GitHub also uses the action's metadata on your GitHub Marketplace page.
      - Requirements to publish
        
        The action must be in a public repository.
        
        Each repository must contain a single action.
        
        The action's metadata file (action.yml or action.yaml) must be in the root directory of the repository.
        
        The name in the action's metadata file must be unique on the GitHub Marketplace
        
        The name can't match a user or organization on GitHub, unless the user or organization owner is publishing the action. For example, only the GitHub organization can publish an action named github
        
        The name can't match an existing GitHub Marketplace category.
        
        The name can't match an existing GitHub feature.
        
        You can add the action you've created to the GitHub Marketplace by tagging it as a new release and then publishing it. There are a few guided steps in GitHub that allow you to publish a release of your action. You can find more information on these steps in the Summary section at the end of this module.
  - - - Your GitHub username
      - A Personal Access Token
      - The GitHub Packages endpoint for your package ecosystem
    - - You can also use GitHub Actions to automate package management. With the delete-package-versions action, you can automatically prune the oldest version of your packages while publishing a new version.
      - You can manage GitHub Packages through the GitHub API and the GraphQL API. These APIs allows you to support advanced integrations scenarios. For example, with GitHub's Webhook feature, you can run code when a new package is published. Imagine you're a maintainer of an open-source project. With webhooks, you could automatically publish a new Tweet or a blog post when a new package is published.
- - - - Discover options for triggering a continuous delivery GitHub Workflow
      - Understand steps to remove workflow artifacts
      - Identify important environment protections
      - Control workflow execution with job conditionals
      - Deploying to Microsoft Azure with a GitHub deploy action
      - Store credentials with GitHub Secrets
      - Create and destroy Azure resources with GitHub Actions workflows
  - - - Next, learn how to work with conditionals in the workflow.
      - Finally, learn about how to create and delete Azure resources by using GitHub Actions.
      - This unit discusses how to use GitHub actions to deploy a container-based web app to Microsoft Azure Web Apps. It covers some options for triggering a workflow
    - - One option is to trigger the workflow with ChatOps
      - ChatOps uses chat clients, chatbots, and real-time communication tools to run tasks
      - Another option is to use labels in your pull request.
        on: pull_request: types: [labeled]
      - Different labels can start different workflows
    - - GitHub workflows provide the if conditional when you only want to run a workflow if some condition is true. The conditional uses an expression that is evaluated at runtime.
      - ejemplo
        if: contains(github.event.pull_request.labels.*.name, 'stage')
    - - GitHub Secrets is a secure place to store sensitive information that your workflow needs
      - First create the secret in Github Secrets Portal
      - After use the secret in your workflow wherever you need that information
      - example
        
        steps:
        
        name: "Login via Azure CLI"
        
        uses: azure/login@v1
        
        with:
        
        creds: ${{ secrets.AZURE_CREDENTIALS }}
    - - You can also search and browse GitHub Actions directly in a repository's workflow editor
      - To find an action
        
        In your repository, browse to the workflow file that you want to edit.
        
        Select the Edit icon in the upper right corner of the file view.
        
        Use the GitHub Marketplace sidebar to the right of the editor to browse Actions.
  - - - learn how to remove workflow artifacts from GitHub and change the default retention period
      - learn how to create a workflow status badge and add it to your README.md file
      - identify some important workflow environment protections and learn how to enable them
    - - By default, GitHub stores any build logs and uploaded artifacts for 90 days before it deletes them. But you can remove old artifacts without increasing your usage limits and blocking your workflows
      - Manually delete artifacts from your repository
        
        Go to Actions Tab
        
        Run workflow and delete button in artifact selected
      - API rest
    - - You can change the default retention period of artifact and log for your repository, organization or enterprise account
      - This change only applies to new artifacts and log files, doesn't apply to existing objects
      - You can define a custom retention period for individual artifacts right wihin the workflow file with retention-days value within the step with the upload-artifact action
      - Example step-action
        
        - name: 'Upload Artifact'
        
        uses: actions/upload-artifact@v2
        
        with:
        
        name: my-artifact
        
        path: my_file.txt
        
        retention-days: 10
  - - - Required reviewers
        Allow you to set a specific person or team to approve workflow jobs that reference the job's environment
      - Wait timer
        can be used to delay a job for a specific amount of time after the job has been triggered
    - - 1 Create a production environment within the repository
      - 2 Configure the required reviewers environment protection to require an approval from the specific dev team
      - Configure the specific job within the workflow to look for the production enfironment
- - - - Identify the different tools you can use at enterprise and organization levels to manage your actions and workflows.
      - Evaluate what the appropriate runners are for your enterprise instance.
      - Discover the different configurations available for self-hosted runners and customize them according to your enterprise use case.
      - Understand what encrypted secrets are and how to use them in your actions and workflows.
  - - - Configure a GitHub Actions use policy
        
        For this reason, configuring a use policy for workflows and actions in your enterprise is essential to prevent users from using malicious third-party actions
        
        You have several options in Enterprise Cloud to configure a policy, as well as in Enterprise Server if GitHub Connect is enabled in your enterprise settings
        
        In account enterprise-> policies -> Action
      - Manually sync actions for Enterprise Server
        
        if you want stricter control over the public actions that should be made available in your enterprise, you can manually download and sync actions into your enterprise instance using the actions-sync tool
    - - Document corporate standards
      - As a best practice, we recommend you document the following
        
        Repositories for storage
        
        Files/folders naming conventions
        
        Location of shared components
        
        Plans for ongoing maintenance
        
        Contribution guidelines
      - Create workflow templates
        
        Workflow templates are a great way to ensure automation is reused and maintained in your enterprise
        
        Steps
        
        Create a YML workflow file
        
        Create a json metadata file that describes how the template should be presented to users when they?re creating a workflow (same that workflow file but must be appended with .properties.json
        
        Both files must be placed in a public .github repository and in a directory named workflow-templates
        
        Parameters metadata file
        
        name
        Req. Name of the workflow template displayed in the list of available templates
        
        description
        Req. Description of the workflow template displayed in the list of available templates
        
        iconName
        Defines an icon for the workflow's entry in the template list. Must be an SVG icon of the same name, and must be stored in the workflow-templates directory
        
        categories
        Defines the language category of the workflow. When a user views the available templates, the templates that match the same language will feature more prominently
        
        filePatterns
        Enables the template to be used if the user's repository has a file in its root directory that matches a defined regular expression
        
        Find it templates in
        Actions-> New workflow-> Workflows created by ORG_NAME
  - - - In this section, you'll explore the different tools and strategies available to you in GitHub Enterprise Cloud and GitHub Enterprise Server to manage the use of GitHub Actions runners in your enterprise.
    - - Types
        
        Github-hosted runners
        
        Self-hosted runners
      - Comparation
        
        GH HOSTED
        
        Receive automatic updates for the operating system, preinstalled packages and tools, and the self-hosted runner application
        
        Github managed and maintained (PAAS)
        
        Provide a clean instance for every job execution
        
        Use free minutes on your Github plan, with per-minute rates applied after surpassing the free minutes
        
        Self-hosted runners
        
        Receive automatic updates for the self-hosted runner applications only. You're responsible for updating the operating system and all other software
        
        Can use cloud services or local machines that you already pay for. Also are customizable to your hardware, operating system, software and security requirements
        
        Don't need to have a clean instance for every job execution
        
        Are free to use with Github actions, but you're responsible for the cost of maintaining your runner machines
    - - You can restrict only specific users or organizations in your enterprise instance to deply code to your production environment
      - For create groups at enterprise level, navigate to your enterprise account and then to Policies > actions- > In te runner groups tab select New runner group
    - - In enterprise cloud and enterprise server, offer features to customize your self-hosted runners for your enterprise use, as labels, proxy servers and IP allowlists
      - Labels
        
        self-hosted, [linux,windows,macOS], [X64,ARM,ARM64]
      - Proxy servers
        
        Environment variables
        
        https_proxy
        Proxy URL for HTTPS traffic. You can also include basic authentication credentials, if necessary.
        
        http_proxy
        Proxy URL for HTTP traffic. You can also include basic authentication credentials, if necessary.
        
        no_proxy
        Comma-separated list of hosts that should'nt use a proxy. Only hostnames are allowed in no_proxy. You can't use IP addresses.
      - IP Allowlist
        
        If your Enterprise Cloud or Enterprise Server organization has configured IP allowlists, you must add the IP address or IP address range of your self-hosted runners to the IP allowlist in order for your self-hosted runners to communicate with GitHub
        
        To add the IP address or IP address range of your self-hosted runners to an organization IP allowlist, navigate to your organization Settings and select Organization security in the sidebar. Under IP Address, add the IP address or IP address range of your self-hosted runners in CIDR notation and select + Add.
    - - Both Enterprise Cloud and Enterprise Server offer tools enabling you to monitor, troubleshoot, and update your self-hosted runners
      - If your builds start to fail, some files in your repository get locked, or your workflow runs are stuck, troubleshooting the runner executing your workflow can help solve the issue
      - Steps
        
        Check the status of the runner in the github actions settings of the organization, repository or enterprise where your self-hosted runner is registered (under actions for an organization or repository, under policies>actions for an enterprise
        
        Review the activities and automatic updates of the runner in the Runner_ files in the _diag folder.
        
        Review the status of the jobs the runner executed in the Worker_ files in the _diag folder
        
        Extra steps
        
        Mac
        Check the self-hosted runner application service using launchd
        
        Windows
        Check the self-hosted runner application service using PowerShell
        
        Linux
        - Check the self-hosted runner application service using journalctl
        - If your jobs require containers, check that Docker is installed and running and the Docker permissions using systemctl
  - - - To access an encrypted secret in a workflow, you must use the secrets context in your workflow file
        
        steps:
        
        - name: Hello world action
        
        with: # Set the secret as an input
        
        super_secret: ${{ secrets.SuperSecret }}
        
        env: # Or as an environment variable
        
        super_secret: ${{ secrets.SuperSecret }}
      - To access an encrypted secret in an action, you must specify the secret as an input parameter in the action.yml metadata file.
        If you need to access the encrypted secret in your action's code, the action code could read the value of the input using the $SUPER_SECRET environment variable.
        
        inputs:
        
        super_secret:
        
        description: 'My secret token'
        
        required: true
  - - - Use different tools at enterprise and organization levels to manage your actions and workflows.
      - Evaluate what the appropriate runners are for your enterprise instance.
      - Customize your self-hosted runners according to your enterprise use case.
      - Scope, create, and access encrypted secrets in your actions and workflows.
- - - - Create a workflow from a template.
      - Understand the GitHub Actions logs.
      - Test against multiple targets.
      - Separate build and test jobs.
      - Save and access build artifacts.
      - Automate labeling a PR on review.
    - - To create a workflow, you start by using a template
      - A template has common jobs and steps preconfigured for the particular type of automation you're implementing.
      - Procedimiento
        
        On the main page of your repository, select the Actions tab and then select New workflow
        
        Search template and In the search results, in the Node.js pane, select Configure.
      - Action Logs for the build
        
        When a workflow runs, it produces a log that includes the details of what happened and any errors or test failures.
        
        If there's an error or if a test fails, you see a red ✖ rather than a green check mark ✔ in the logs. You can examine the details of the error or failure to investigate what happened.
      - Customize workflow templates with matrix OS and matrix of node versions
      - What are artifacts?
        
        When a workflow produces something other than a log entry, the product is called an artifact.
        
        Storing an artifact preserves it between jobs. Each job uses a fresh instance of a virtual machine (VM), so you can't reuse the artifact by saving it on the VM.
        
        If you need your artifact in a different job, you can upload the artifact to storage in one job, and download it for the other job.
      - Artifact storage
        
        Artifacts are stored in storage space on GitHub. The space is free for public repositories and some amount is free for private repositories, depending on the account. GitHub stores your artifacts for 90 days.
      - Automate reviews in GitHub using workflows
        
        We could also run a workflow on a schedule, or on some event outside of GitHub. For example only after a person performs an action, ie after a reviewer approves the pull request
  - - - In Github Actions Workflow there are default environment variables that are available for you to use, but only within the runner that's executing a job
        
        These default variables are case-sensitive, and they refer to configuration values for the system and for the current user.
        
        We recommend that you use these default environment variables to reference the filesystem rather than using hard-coded file paths
        
        For use specify $<name>
        ex $GITHUB_REF
      - You too can to use defined variables as contexts, while default environment variables can only be used within the runner, context variables can be used at any point within the workflow
        
        ejemplo
        
        name: CI
        
        on: push
        
        jobs:
        
        prod-check:
        
        if: github.ref == 'refs/heads/main'
        
        runs-on: ubuntu-latest
        
        steps:
        
        run: echo "Deploying to production server on branch $GITHUB_REF"
        
        Notice that default environment variables are all uppercase where context variables are all lowercase.
    - - Similar to using default environment variables, you can use custom environment variables in your workflow file.
      - o create a custom variable, you need to define it in your workflow file using the env context
      - example
        
        name: CI
        
        on: push
        
        jobs:
        
        prod-check:
        
        if: github.ref == 'refs/heads/main'
        
        runs-on: ubuntu-latest
        
        steps:
        
        - run: echo "Nice work, $First_Name. Deploying to production server on branch $GITHUB_REF"
        
        env:
        
        First_Name: Mona
    - - To cache dependencies for a job, use GitHub's cache action
      - Parameters (with:)
        
        Key (required)
        Refers to the key identifier created when saving and searching for a cache
        
        Path (required)
        Refers to the file path on the runer to cache or search
        
        Restore-keys (optional)
        Consist of alternative existing keys to caches if the desired cache key isn't found
    - - Similar to the idea of caching dependencies within your workflow, you can pass data between jobs within the same workflow
      - ou can do this by using the upload-artifact and download-artifact actions
      - For example, job_2 requires job_1 by using the needs: job_1 syntax. This is positionated at job_specific level (with name, runs-on or steps)
    - - In some cases, the default workflow logs won't provide enough detail to diagnose why a specific workflow run, job, or step has failed
        For these situations, you can enable additional debug logging for two options: runs and steps.
      - Enable this diagnostic logging by setting two repository secrets that require admin access to the repository to true:
        
        To enable runner diagnostic logging, set the ACTIONS_RUNNER_DEBUG secret in the repository that contains the workflow to true.
        
        To enable step diagnostic logging, set the ACTIONS_STEP_DEBUG secret in the repository that contains the workflow to true.
    - - To view the logs of a workflow run in GitHub, you can follow these steps:
        
        Navigate to the Actions tab in your repository.
        
        In the left sidebar, click the desired workflow.
        
        From the list of workflow runs, select the desired run.
        
        Under Jobs, select the desired job.
        
        Read the log output.
    - - To view a workflow run's log using the API, you need to send a GET request to the logs endpoint
      - If the repository is private, you must use an access token with the repo scope
      - GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs
    - - In this module, you implemented a CI solution using GitHub Actions and workflows.
      - You can now:
      - Build and test a Node.js project by using GitHub Actions and a templated workflow.
      - Debug a failed test using the GitHub Actions log.
      - Customize your workflow with GitHub Actions to:
      - Create a build artifact and save it.
      - Get access to your build artifacts.
      - Test against multiple targets.
      - Add labels to your pull requests.
- - - - Understand what a Package Repository is and when to use it.
      - Set up a Continuous Integration (CI) workflow with GitHub Actions to publish to GitHub Packages.
      - Validate your knowledge with an exercise that checks your ability to publish to a GitHub Packages registry.
      - Identify how to authenticate, install, and manage GitHub Packages.
  - - - GitHub Packages allow you to share your project dependencies within your organization or publicly.
    - - GitHub Packages allow you to publish and distribute container images
      - You can use these images from
        
        your local development environment
        
        a base image from github codespaces dev environment
        
        As a step into your CI CD worfklow with github actions
        
        on a server or a cloud service
    - - GitHub Packages are used to publish releases of your libraries to a standard package feed or a container registry
      - They are meant to leverage the ways the specific package-management client works with that feed
      - GitHub Releases are used to release a bundle of packaged software,along with release notes and links to binary files
    - - With GitHub Packages, you can use a single set of credentials across your source-code repository, your private npm registry, and your Maven or Gradle private registry
      - You can give read acces to a package and its code, simply give then read access to the repository
    - - GitHub Actions is another GitHub feature that allows you to automate your software workflows. You can build, test, and deploy your code right from GitHub.
      - Combining GH actions and github packages, you can build a workflow that will build and test your code, and then publish it to Github Packages by simply pushing code to your repository
  - - - GitHub Packages let you securely publish and consume packages, store your packages alongside your code, and share your packages privately with your team or publicly with the open-source community. You can also use GitHub Actions to automate your packages.
      - It's common practice to name a workflow that publishes a new package whenever a new release is created something like release-package.yml, to make it easy for project collaborators to understand its purpose without navigating to the workflow file.
    - - GitHub Packages also offers a container registry designed to support the unique needs of container images
      - You can use GitHub Container Registry to seamlessly host and manage Docker container images in your GitHub organization or personal user account.
      - GitHub Container Registry allows you to configure who can manage and access packages using fine-grained permissions.
      - You can
        
        Store container images within your organization and user account rather tan a repository
        
        Set fine-grained permissions for the container images
        
        Access public container images anonymously
      - After you've built the image and authenticated and signed in to the GitHub Container Registry service at ghcr.io, you can then tag and push the latest version of the image to the container registry using these commands:
        
        echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin docker tag IMAGE_ID ghcr.io/OWNER/IMAGE_NAME:latest docker push ghcr.io/OWNER/IMAGE_NAME:latest
        
        To authenticate using a GitHub Actions workflow, you can use a GITHUB_TOKEN:
        For package registries at PACKAGE-REGISTRY.pkg.github.com.
        For the container registry at ghcr.io/OWNER/IMAGE-NAME.