Introduction

This article is a personal path to review and improve my Git and GitHub skills at the command line and in Visual Studio Enterprise and Visual Studio Code. My plan is to spend an hour every day on GitHub, Git, and Visual Studio Enterprise, and Visual Studio Code. This article will document this learning path during the month. You might find this material useful for your learning path. I am hoping to do this several more times throughout the year on different topics. Two years ago I wrote another learning path article on Go that is very popular: Google Cloud and Go – My Journey to Learn a New Language in 30 days.

I am already very comfortable with Git and somewhat with GitHub. I have been storing projects on GitHub personally for years and at work, GitHub or a private Git repository has been the convention for years. I also consult on Git internals development for Visual Studio.

However, it is easy to get in a rut and use only the features that I am most comfortable with. I am usually only a contributor on large GitHub projects, so I want to improve my GitHub large project and open-source management skills. Products like GitHub are extremely popular. That means new features are being constantly developed. Time to refresh and learn a couple of advanced features and put them into my daily routine.

One of my favorite free learning resources is Microsoft Learn. Learn has a number of paths for Git and GitHub. I searched their catalog and selected the following paths:

GitHub:

• Path: GitHub fundamentals – Administration basics and product features – Complete
  • Module: Introduction to GitHub – Completed 2021-12-26
  • Module: Introduction to GitHub administration – Completed 2021-12-27
  • Module: Introduction to GitHub’s Products – Completed 2021-12-27
• Path: Build community-driven software projects on GitHub
  • Module: Introduction to GitHub – Completed 2021-12-26
  • Module: Manage an InnerSource program by using GitHub – Completed 2021-12-31
  • Module: Create an open-source program by using GitHub best practices –
  • Module: Upload your project by using GitHub best practices –
  • Module: Migrate your repository by using GitHub best practices –
  • Module: Maintain a secure repository by using GitHub best practices –
  • Module: Contribute to an open-source project on GitHub –
• Path: Manage the lifecycle of your projects on GitHub
  • Module: Introduction to GitHub – Completed 2021-12-26
  • Module: Manage software delivery by using a release based workflow on GitHub – Completed 2022-01-01
  • Module: Manage repository changes by using pull requests on GitHub –
  • Module: Settle competing commits by using merge conflict resolution on GitHub –
  • Module: Automate DevOps processes by using GitHub Apps –
  • Module: Search and organize repository history by using GitHub –
• Path: AZ-400: Manage source control
  • Module: Introduction to GitHub – Completed 2021-12-26
  • Module: Migrate your repository by using GitHub best practices –
  • …
  • Module: Manage an InnerSource program by using GitHub – Completed 2021-12-31
  • Module: Communicate effectively on GitHub by using Markdown –
  • Module: Maintain a secure repository by using GitHub best practices – Completed 2022-01-01
  • …
  • Module: Manage software delivery by using a release based workflow on GitHub – Completed 2022-01-01
  • Module: Build continuous integration (CI) workflows by using GitHub Actions – Completed 2021-12-30
  • …
• Module: GitHub administration for enterprise support and adoption
• Module: Manage sensitive data and security policies within GitHub –
• Module: Configure and use secret scanning in your GitHub repository –
• Module: Configure Dependabot security updates on your GitHub repo – Completed 2022-01-09
• Module: Authenticate and authorize user identities on GitHub – Completed 2022-01-09

GitHub Pages and Markdown:

• Path: Collaborate with others with Markdown and GitHub Pages
  • Module: Introduction to GitHub – Completed 2021-12-26
  • Module: Communicate effectively on GitHub by using Markdown –
  • Module: Create and host web sites by using GitHub Pages – Completed 2021-12-28

GitHub Actions:

• Path: Automate your workflow with GitHub Actions
  • Module: Introduction to GitHub – Completed 2021-12-26
  • Module: Automate development tasks by using GitHub Actions – Completed 2021-12-29
  • Module: Build continuous integration (CI) workflows by using GitHub Actions – Completed 2021-12-30
  • Module: Build and deploy applications to Azure by using GitHub Actions –
  • Module: Automate GitHub by using GitHub Script – Completed 2022-01-03
  • Module: Leverage GitHub Actions to publish to GitHub Packages – Completed 2022-01-07
• Module: Introduction to GitHub Actions – Completed 2021-12-29
• Module: Learn continuous integration with GitHub Actions – Completed 2022-01-05
• Module: Create and publish custom GitHub actions –

Git:

• Path: Introduction to version control with Git
• Path: AZ-400: Work with Git for enterprise DevOps

Visual Studio:

• Module: Get started with Git and GitHub in Visual Studio
• Module: Use Git version-control tools in Visual Studio Code
• Module: Introduction to GitHub in Visual Studio Code

GitHub Learning Lab:

• Lab: GitHub Actions: Hello World – Completed 2021-12-29
• Lab: GitHub Actions: Continuous Integration – Completed 2021-12-29
• Lab: InnerSource fundamentals – Completed 2021-12-31
• Lab: Securing your workflows – Completed 2022-01-01
• Lab: Security strategy essentials –
• Lab: Create a release based workflow – Completed 2022-01-01
• Lab: Welcome to the Use .gitignore exercise! – Completed 2022-01-01
• Lab: GitHub Actions: Using GitHub Script – Completed 2022-01-03
• Lab: Welcome to the exercise on publishing packages! – Completed 2022-01-07

That is a lot of resources. About half should be basic reviews for me, but I noticed a number of GitHub learning paths should help me meet my objectives. At the end of January, I will have improved my abilities with GitHub management significantly.

There are several GitHub trials that I want to practice with:

• GitHub Team
• GitHub Free for organizations
  • Turn your account into an organization
• GitHub Enterprise Cloud
  • Setting up a trial of GitHub Enterprise Cloud
• GitHub Enterprise Server
  • Setting up a trial of GitHub Enterprise Server
• GitHub Developer Program
  • Register for the GitHub Developer Program

GitHub Certifications

There are none at this time, but it appears like Microsoft is preparing several. You can signup to receive notifications here.

Action Items:

• GitHub Organizations support Identity Provider (IdP) groups such as Azure Active Directory.
• GitHub Codespaces. I have not used this feature before.
• GitHub Copilot. The potential for this service is shocking.

Prologue

January 1, 2022

I have spent my entire career developing proprietary software. GitHub’s success is due to open source development. Linux was created because of AT&T Unix’s licensing. Linux spawned Git which spawned GitHub. In some respects, AT&T and Digital Equipment Corporation (DEC) are the forefathers to modern-day Linux. Without them, Linux might not have been created.

The open-source community has fought tool and nail for free and open software. The proprietary software companies have fought tool and nail to keep software as an asset that they own and control. If you analyze what is now happening in the cloud market today, we are rapidly headed back to proprietary software. The cloud companies have shifted huge bodies of code into infrastructure that we no longer have access to. AI and ML will become technologies and services that we will not be able to live without. The people that understand that code now work for the largest software companies – Google, IBM, Microsoft, and Amazon. AI and ML will make software developers obsolete very soon – probably by 2030. That process is already happening and once AI and ML reach the event horizon, machine-created software will explode overnight. I predict that machines will invent new languages that we cannot understand.

If you take a look at the software development landscape, platforms like GitHub become critical for AI and ML. With similar techniques that we taught computers to play chess by analyzing millions of real games, computers are now able to analyze millions of open source projects. As machine learning improves, machines will be able to first replicate common small challenges by possessing a searchable knowledge base created from billions of human-written modules of code. If you take the most complex software problems and break them down into individual tasks, problems and facts, you have the beginnings of structured code. Combine those small modules, typically 50 lines or less, into larger and larger webs of modules, you have a software program or suite of programs. Machines will first assimilate billions of lines of code with billions of facts. Quickly those tiny details will become software that is larger than the largest teams of humans can understand and written faster than we can adapt.

Machines will eventually create software that is so large that there is no single program or computer. The software will be trillions of lines of code, running on billions/trillions of processors, communicating via events sent over global networks, consuming compute resources that span the planet. Data will be collected, transformed, processed, and stored. Humans will become worker ants implementing output from machines.

I am not certain if software will possess what we call intelligence. Software will definitely be able to model intelligent activity. Will software become a living breathing carbon machine as foretold in science fiction? We breathe oxygen, computers breathe electricity. What is the definition of being alive? Will software evolve into another life form? So many questions that might be answered in our generation.

GitHub is providing the soil that will grow and feed machine-written software.

As developers, we are forging our own career extinctions and possibly our own extinction.

Epilogue

Choosing the octopus as its mascot (octocat) is a great representation of GitHub. The merged cephalopod and cat have many legs just like GitHub. The primary legs of GitHub are:

1. Repository storage.
2. Workflows and actions.
3. Websites.
4. Repository management.
5. Repository programming.

Learning GitHub could easily be a multi-quarter university program. Each of the major areas could consume a quarter, making learning GitHub a significant adventure and investment.

Day 1 – December 26, 2021

I do not want to play in my real GitHub account, so I need to create a new account. I have only created a few GitHub accounts years ago, so I do not even remember the process.

The process was simple. Enter your email address, password, and username. Receive an email and verify the account. Then complete a picture selection to make sure you are not a bot. Now on to complete the first Microsoft Learn module.

Module: Introduction to GitHub

It is very interesting when you consider that Microsoft purchased GitHub on June 4, 2018, for $7.5 Billion in Microsoft stock. On June 4, Microsoft was trading for about $97.00. Today, Microsoft is about $327.00. That is more than 3x which would put GitHub worth more than $22.5 Billion in today’s dollars.

Also interesting is reviewing GitHub’s history. From the initial release of Git on April 7, 2005, and the first release of GitHub in April 2008 the growth has been dramatic. GitHub is a success story few companies have achieved. As of November 2021, GitHub reports having over 73 million developers and more than 200 million repositories [source].

Two important items to understand: what Git is and what GitHub is. Most people confuse the two together. In fact, Git is the source code version control tool. You do not even need GitHub to put your project under SCCS (Source Code Control System). For those of us that have been around for a few years, SCCS existed long before Git arrived. In fact, SCCS systems were very mature a decade before Git.

The beauty of GitHub in the early days was the ability to push your code to a public repository that provided some important features:

• Public or Private Repository which facilitated sharing either publicly or privately.
• Version Control. This is the major purpose of SCCS.
• Distributed Version Control. This allowed for multiple developers to safely work together on one project. This also allowed for other contributors to contribute to the system such as technical writers, test and QA engineers, and management.
• Web Interface. This feature makes browsing, diffing, reviewing, and approving source code easy, documented, and manageable.
• Backups. I cannot even begin to remember the number of projects that died because of no backups or backups that could not be restored.

Key features provided by GitHub include:

• Issues
• Discussions
• Pull requests
• Notifications
• Labels
• Actions
• Forks
• Projects

Key features provided by Git include:

• Installed and used on your local machine
• Handles version control
• Supports branching

In reviewing the GitHub key features list, I realized that I do not use most of the GitHub features. I think the reason why is that I think in terms of version control and the CLI and do almost everything from a command prompt. I seldom visit the GitHub GUI. Time to modify my thinking and work processes.

GitHub Docs has several nice Quickstarts:

• GitHub – Hello World – Completed.
• Quickstart for GitHub Issues – Completed.

GitHub Logo

The concept behind the GitHub logo came from “octopus merge”. The image is a merge of an octopus and a cat. Octocat has even appeared in his/her own videos [search].

More Information

• Setting up and managing organizations and teams
• Committing changes to your project
• Collaborating with issues and pull requests
• About the role of labels
• GitHub Actions
• Fork a repo
• Working with GitHub Pages

Day Summary

When you have good resources to use for learning and reviews, I find that I always improve and learn new things. I am impressed with the quality of material that Microsoft Learn and GitHub are providing the community. I am already getting a better feel for the items I need to improve upon.

I have never used this feature GitHub Notifications Dashboard. I just used normal email in the past.

Saved for tomorrow:

GitHub Learning Lab

Day 2 – December 27, 2021

Task: Invite collaborators to a personal account

For personal accounts, collaborators are added to a repository. The invitee must have a GitHub username.

GitHub Docs: Inviting collaborators to a personal repository

• Navigate to the repository.
• Click Settings.
•  In the left sidebar, click Manage access.
• You might be prompted to enter your password.
• Click Add people.
• Enter the collaborator’s username, full name, or email.
• Confirm adding the collaborator to the repository.
• The collaborator will be sent an email. The invitation must be accepted or declined.

Personal Account Permissions

For personal accounts, there are two permission levels:

• Repository owner
• Collaborators

There can be only one owner. Ownership permissions cannot be shared with another account.

Collaborators on a personal repository can pull (read) and push (write) changes to a repository. A collaborator can do just about everything that an owner can to the repository contents.

A collaborator cannot: (this list needs to be improved)

• Archive the repository
• Delete the repository
• Delete and restore packages.
• Invite collaborators
• Change the visibility of the repository
• Display a sponsor button

GitHub Docs: Permission levels for a user account repository

GitHub Products

Module: Introduction to GitHub’s Products

GitHub has several free and paid products:

• GitHub Free
• GitHub Free for organizations
• GitHub Pro
• GitHub Team
• GitHub Enterprise

There are three account types:

• Personal user accounts
• Organization accounts
• Enterprise accounts

Pricing:

• GitHub Free – Free
• GitHub Free for Organizations – Free
• GitHub Pro – $4/month
• GitHub Team – $4 user/month
• GitHub Enterprise – $21 user/month

Create a GitHub Free for Organizations account

This was fairly easy. Follow the same steps to create a free personal account and then select organizations. Select the free plan.

Module: Introduction to GitHub administration

GitHub Authentication

• Username and password.
• Personal access tokens.
• SSH keys
• Deploy keys

Security Options

• Multi-factor authentication (MFA/2FA)
• SAML SSO
• LDAP

Permissions

• Repository permissions
• Team permissions
• Organization permissions
• Enterprise permissions

Repository permission levels

• Read – Recommended for non-code contributors who want to view or discuss your project. This is good for anyone that needs to view the content within the repository but doesn’t need to actually make contributions or changes.
• Triage – Recommended for contributors who need to proactively manage issues and pull requests without write access. This could be good for some project managers who manage tracking issues but won’t make any changes.
• Write – Recommended for contributors who actively push to your project. This is the standard permission for most developers.
• Maintain – Recommended for project managers who need to manage the repository without access to sensitive or destructive actions
• Admin – Recommended for people who need full access to the project, including sensitive and destructive actions like managing security or deleting a repository. These are repository owners and administrators.

More Information

• Organizations and teams
• Managing team synchronization for your organization
• Creating a personal access token
• Generating a new SSH key and adding it to the ssh-agent
• Deploy keys
• Requiring two-factor authentication in your organization
• Requiring two-factor authentication for organizations in your enterprise account
• About identity and access management with SAML single sign-on
• Using LDAP
• Repository permission levels for an organization
• Managing teams and people with access to your repository
• Giving “team maintainer” permissions to an organization member
• Permission levels for an organization
• Setting base permissions for an organization
• Roles in an enterprise
• Enforcing a policy on default repository permissions

Day Summary

I need to spend more time on GitHub authentication and security options. Some features are only available with certain accounts, such as enterprise. Create a table that details everything.

Day 3 – December 28, 2021

Today, I want to work on GitHub Pages. Beyond creating good README.md files, I seldom work with markdown and not at all with GitHub Pages. I will start with a Microsoft Learn module.

Module: Create and host web sites by using GitHub Pages

I created my own GitHub Pages site:

• Create a new repository
  • The repository must be public.
• Go to the repository, select Settings.
• In the left tab, select Pages.
• For Source select the repository branch to use. Click Save.
• For Theme Chooser select a theme.
• Option: For Custom domain, enter the desired domain. Click Save.
• Log into your DNS server and create a new CNAME record.
  • In my case, pages.jhanley.dev with the value hanley-dev.github.io.
  • Wait a few minutes. GitHub will:
    • Verify the DNS CNAME resource record.
    • Create an SSL certificate
• Go to the new GitHub Pages site: https://pages.jhanley.dev/

The process of creating a GitHub Pages site is very easy. Now on to learn more to see what features GitHub Pages support and how well it can be used as a public website.

GitHub features to learn:

• Markdown and HTML.
• Jekyll
  • About GitHub Pages and Jekyll
  • Transform your plain text into static websites and blogs.
• Liquid template language syntax. [link]
  • At first glance, this looks very similar to Laravel Blade Templates. [link]
• Blog Posts

GitHub has a free training lab on GitHub Pages – Completed 2021-12-28.

GitHub Pages checks for the following homepages in this order:

• index
• README.md

More Information:

• GitHub Pages official site
• Jekyll official site
• Liquid template language official site

YouTube videos GitHub Pages and Jekyll:

• GitHub Pages and Jekyll by Bill Raymond – I watched the first video. Very good material.

Day Summary

I have known about GitHub Pages, but I did not use them. I find this feature very interesting and its simplicity should remove most obstacles that developers have in writing documentation. For those just getting started with web development, this is an interesting way to get started without having to learn the underlying technologies (servers, web server software Apache/Nginx, frameworks, languages).

Day 4 – December 29, 2021

Today, I have several goals. The first is to start working on GitHub Actions, investigate GitHub Packages and the new GitHub Container Registry.

For today, I completed the following:

• Module: Automate development tasks by using GitHub Actions
• Module: Introduction to GitHub Actions
• GitHub has a free training lab on GitHub Actions

Those items consumed my entire allocated time. GitHub Actions is a huge area that requires some effort to know all the pieces well. My developer side kicked in and I also want to learn the API side of GitHub.

This example from the first module is interesting:

That example will trigger a GitHub workflow via an external POST request. Getting that example to work turned into a challenge. On another day I will document how to make that work. I can imagine all sorts of integrations where external events from Azure functions or Google Cloud Run make requests to GitHub.

More Information

• GitHub Actions documentation
• GitHub Marketplace
• GitHub created actions
• actions/checkout@v1
• Metadata syntax for GitHub Actions
• Workflow syntax for GitHub Actions
• Events that trigger workflows
• GitHub Actions usage limits
• Introduction to Docker Containers
• GitHub-hosted runners
• Self-hosted runners
• The components of GitHub Actions
• Manual events
• Webhook events and payloads
• Disabling and enabling a workflow
• Sharing workflows with your organization
• Scheduled events

Lab: GitHub Actions: Continuous Integration

The module was huge and I spent hours practicing. I did not finish and I plan to continue tomorrow. There are so many details with GitHub Actions that you can spend hours reading the documentation and hours more practicing.

In reviewing other repositories, I noticed nice graphics like this:

These are called badges. The “Build passing” badge is created like this:

That badge is called Workflow Status Badge. This link provides more information:

Adding a workflow status badge

The “License MIT” badge is a Markdown License Badge.

Adding a license to a repository

You can add other badges as well. Visit the Shields.IO repository and website for more information.

Examples:

• code coverage percentage: 
• stable release version: 
• package manager release: 
• status of third-party dependencies: 
• static code analysis grade: 
• SemVer version observance: 
• amount of Liberapay donations per week: 
• Python package downloads: 
• Chrome Web Store extension rating: 
• Uptime Robot percentage: 

There are millions of GitHub repositories. To create a good first impression and trust, spend time on the initial structure and appearance. Many times I look at a repository, see basically nothing about the code, so I move on without giving the repository a chance. There are several easy-to-add items beyond colorful badges that can add a professional status to a public repository:

• Setting up your project for healthy contributions
• “Adding a code of conduct to your project“
• “Setting guidelines for repository contributors“
• “Adding a license to a repository“
• “About issue and pull request templates“
• “Open Source Guides“

More Information

• GitHub Actions documentation
• GitHub Marketplace
• GitHub created actions
• actions/checkout@v1
• actions/upload-artifact
• actions/download-artifact
• pullreminders/label-when-approved-action
• Metadata syntax for GitHub Actions
• Workflow syntax for GitHub Actions
• Events that trigger workflows
• GitHub Actions usage limits
• About GitHub Actions: Job
• About CI: Job
• npm install
• npm run
• npm test
• Default environment variables
• Contexts
• Essential features of GitHub Actions
• Using the cache action
• Passing data between jobs in a workflow
• Enabling debug logging
• Using workflow run logs
• Workflow runs

Day Summary

Five days of study completed. I am definitely feeling the brain strain. I had planned to study for one hour per day for a total of 20 hours for the month. I have been studying for two to three hours each day very intensely. I mapped out this learning journey before starting and it is clear to me now that I underestimated the scope and depth of changes that Microsoft has put into GitHub in the past two years. To really master GitHub Actions will take a real investment of time beyond just the learning phase.

Day 6 – December 31, 2021

My head is overloaded with GitHub Actions details. I need more practice with the details that I have learned so far. I plan to switch gears and learn more about GitHub management features first and then practice GitHub Actions.

Module: Manage an InnerSource program by using GitHub

Lab: InnerSource fundamentals

More Information

• An introduction to InnerSource
• Types of GitHub accounts
• Repository permission levels for an organization
• Managing access to your organization’s repositories
• Adopt a Git branching strategy
• Best practices for protected branches
• GitHub Collaboration Best Practices
• Awesome README examples
• Awesome CONTRIBUTING.md examples
• Awesome GitHub issue & pull request templates

Day Summary

The concept of InnerSource is interesting. This is a methodology of applying open-source project management to internal projects.

Organizations have deployed many tools for managing projects. GitHub brings many of these features under a central umbrella to simplify and standardize methods for managing projects. These techniques can be applied to just about anything that uses the written form. That could be a software project, QA plan, financial budgets, marketing material, business planning, etc.

Today, I searched for various GitHub courses on the Internet. A common theme is “become a GitHub expert in four hours“. In four hours you would be a beginner. You might reach an intermediate level with forty hours of study and eighty hours of real practice. To become an expert would take a year of investment and a few more years of real-world experience. Knowing the buzzwords and being able to write a GitHub Action without Internet copy-and-paste are entirely different skillsets. Is your concept of creating a new GitHub project, simply adding a README.md and your source files? You are a beginner. Do you understand branching, merging, commits, issues, and actions well enough to not use the Internet as your crutch? You are at the intermediate level. The word expert is so overused that today you when you call yourself an expert without years of experience to back that up, you are telling everyone you are actually a beginner. When you are finally an expert, you will simply say: “Yes, I know GitHub well”.

Day 7 – January 1, 2022

Today I watched several YouTube videos on GitHub self-hosted Runners. Then I read the GitHub documentation section. I think GitHub self-hosted runners are genius. Tomorrow I will deploy my own runner on a Hyper-V virtual machine running Ubuntu 20.04.

In general, I do not watch a lot of YouTube videos for technical training – I prefer Pluralsight. I do watch YouTube often for entertainment (movies, news, etc.). When a company has well-written documentation, I jump in and read everything. GitHub has excellent documentation.

YouTube:

• How to host your own GitHub Actions pipelines
  • Very good video.
  • This one sparked my interest to dig deeper.
• GithubActions – Selfhosted Runners
  • Another good video.
  • This one covers Windows runners.
• MLOps Tutorial #4: GitHub Actions with your own GPUs
  • Very interesting idea about using runners to access your own GPUs.

GitHub Documentation:

• Hosting your own runners – 10 sections – read each one.

GitHub Security:

• Module: Maintain a secure repository by using GitHub best practices
• Lab: Welcome to the Use .gitignore exercise!
• Lab: Securing your workflows
• Lab: Security strategy essentials
• Docs: Getting started with code security
• Docs: About GitHub Advanced Security

using a .gitignore file is a standard procedure with git. Until I started studying GitHub Security, I did not think of .gitignore as a security feature. By implementing a good .gitignore file, you can keep sensitive files out of a repository.

Additional Completed Lessons:

• Module: Manage software delivery by using a release based workflow on GitHub
• Lab: Create a release based workflow

More Information

• Managing project boards
• Tracking the progress of your work with project boards
• Tracking the progress of your work with milestones
• About GitHub releases
• Release Drafter app
• Git cherry-pick documentation
• Semantic Versioning 2.0.0
• About security alerts for vulnerable dependencies
• Dependabot official site
• Security apps on GitHub Marketplace
• Adding a security policy to your repository
• Ignoring files
• Removing sensitive data from a repository

Day Summary

I spent a lot of time on GitHub today. I studied three different areas:

• GitHub self-hosted Runners
• GitHub Security
• GitHub Projects and Releases

Tomorrow I plan to build the GitHub Runner and study GitHub Security.

Week 1 Summary

I deliberately did not work on any of the Microsoft Learn or GitHub Labs for git. I wanted to focus entirely on GitHub as I know git well.

This has been a whirlwind week. I had planned to study one hour per day for five days. Instead, I studied two-plus hours every day, and today is Saturday, the entire day for a total of 20+ hours. I have learned a lot and covered almost all of the major GitHub features. However, if I were to stop now, I would probably remember the concepts and keywords, but the details would quickly fade. My GitHub knowledge is broad but not deep. I will need to practice many concepts and features multiple times to reinforce memory. Then I plan to review how I can incorporate the new skills into my daily procedures.

Day 8 – January 2, 2022

Today I will build a GitHub self-hosted Runner on a Hyper-V virtual machine running Ubuntu Server 20.04.

I created the self-hosted runner and wrote a separate article on the steps I followed.

GitHub – Create a Self-Hosted Runner – Hyper-V plus Ubuntu

Day Summary

I did not complete any Microsoft Learn modules or GitHub Lab labs. I focussed entirely on GitHub self-hosted runners and GitHub actions that deployed updates to my GitHub runner. You can deploy a runner on-premises and then manage updates to the runner using GitHub workflows. I wrote a few workflows that do things like install Docker and PHP 8.1. System updates can now be scripts that are managed as GitHub repositories including capturing the log output. Very interesting ideas come to mind in managing CI/CD infrastructure. I am already planning a part two article.

Day 9 – January 3, 2022

Today I will continue with Microsoft Learn and GitHub Actions then do more learning on GitHub self-hosted runners.

GitHub Script logo:

Completed Lessons:

• Module: Automate GitHub by using GitHub Script –
• Lab: GitHub Actions: Using GitHub Script –

While completing the GitHub Lab exercises, I wondered how they did everything. I think the answer is GitHub Script. In learning how to write basic GitHub actions with actions/github-script, I can see how GitHub can become a programming platform for managing repositories, builds, deployments, and more.

GitHub Octokit

GitHub Octokit is a collection of clients for the GitHub API. GitHub Script provides an authenticated octokit client and allows JavaScript to be written directly in a workflow.

More Information

• GitHub Script
• octokit

Day Summary

The learning module and lab are very interesting. Using JavaScript inside a GitHub action is easy. If you know JavaScript and Node.js, you will be writing GitHub Script in no time. I plan to spend more time writing scripts.

Day 10 – January 4, 2022

Today, I wrote Part 2 of my work learning GitHub self-hosted runners. That took up all the time I allocated for this evening.

GitHub – Create a Self-Hosted Runner – Part 2

More Information

• Using self-hosted runners in a workflow
• Events that trigger workflows
• Manually running a workflow
• Reusing workflows

Day Summary

GitHub self-hosted runners have enormous potential. The features of running GitHub workflows on-premises or in private clouds are intriguing. I plan to learn the self-host runner API next.

Self-hosted runners

Day 11 – January 5, 2022

Today I want to focus on GitHub environment variables, artifacts, and secrets. I chose a Microsoft Learn module to meet this goal.

• Module: Learn continuous integration with GitHub Actions

GitHub built-in environment variables

GitHub provides a series of built-in environment variables. They have a GITHUB_ prefix.

• GITHUB_WORKFLOW is the name of the workflow.
• GITHUB_ACTION is the unique identifier for the action.
• GITHUB_REPOSITORY is the name of the repository (but also includes the name of the owner in owner/repo format)

I create a workflow .github/workflows/test1.yml with this content:

I ran the workflow and the environment variables that contain the string GITHUB:

More Information:

• Environment variables

The GitHub Default Environment variables are accessed with the $ character: example, $GITHUB_REPOSITORY.

Action Items:

• Dig deeper into environment variables, default environment variables, and contexts.

More Information

• About continuous integration – GitHub Docs.
• Environment variables – GitHub Docs.
• Storing workflow data as artifacts – GitHub Docs.
• Encrypted secrets – GitHub Docs.

Day Summary

The Microsoft Learn module is just an overview with links to read the documentation. I plan to study further on each topic and practice with my self-hosted runner.

Day 12 – January 6, 2022

No study today. I need a break. Time to watch a good movie instead of studying.

Day 13 – January 7, 2022

I now want to reinforce my GitHub knowledge by creating a Laravel project that uses GitHub features. This project will use GitHub Authentication to authenticate users to a Laravel application. I want to use GitHub Workflows to build and deploy this application. I do everything with my self-hosted runner. GitHub packages will be used for releases. The application will be deployed to Azure. I will create a separate article on integrating GitHub authentication with Laravel. This project will be a good test of what I have learned in the first two weeks.

Key Items:

• Laravel 8
• GitHub Authentication
• Azure Virtual Machine
• GitHub Self-Hosted Runner
• GitHub Packages
• Terraform

Project Plan:

• Day 1:
  • Create a new Laravel 8 application.
  • Add GitHub Authentication.
  • Configure my self-hosted runner to build and test Laravel.
• Day 2:
  • Create an Azure virtual machine with Terraform.
  • Manually configure the virtual machine with a DNS URL
  • Configure SSL via Let’s Encrypt.
  • Deploy the application to the virtual machine via GitHub workflows.

There are several Microsoft Learn GitHub Labs modules that I want to complete in preparation for this project:

• Module: Leverage GitHub Actions to publish to GitHub Packages
• Lab: Welcome to the exercise on publishing packages!
• Module: Build and deploy applications to Azure by using GitHub Actions

Day 14 – January 8, 2022

Today I worked on my Laravel plus GitHub Authentication application. I am writing a separate article for today’s work.

Week 2 Summary

My progress appears to have slowed down but I have been spending a lot of time repeating and practicing with what I have learned in the past two weeks. GitHub has so many features that an engineer could focus just on GitHub as part of a large team or be an advisor to multiple teams.

Day 15 – January 9, 2022

Today, I want to start with more study on GitHub security and I added several more Microsoft Learn modules in this area.

• Module: Manage sensitive data and security policies within GitHub
• Module: Configure and use secret scanning in your GitHub repository
• Module: Configure Dependabot security updates on your GitHub repo
• Module: Authenticate and authorize user identities on GitHub

More Information

Day Summary

[to be continued]

Photography Credit

I write free articles about technology. Recently, I learned about Pexels.com which provides free images. The image in this article is courtesy of Markus Winkler at Pexels.