diff --git a/.github/workflows/github-actions-demo.yml b/.github/workflows/github-actions-demo.yml new file mode 100644 index 00000000..dc0709a2 --- /dev/null +++ b/.github/workflows/github-actions-demo.yml @@ -0,0 +1,52 @@ +name: GitHub Actions Demo +run-name: ${{ github.actor }} is testing out GitHub Actions 🚀 +on: + push: + workflow_dispatch: + +jobs: + Explore-GitHub-Actions: + runs-on: ubuntu-latest + steps: + - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event." + - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!" + - run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}." + + - name: Check out repository code + uses: actions/checkout@v5 + + - run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner." + - run: echo "🖥️ The workflow is now ready to test your code on the runner." + + - name: List files in the repository + run: | + ls ${{ github.workspace }} + + - name: Gather system information + run: | + echo "## System Information" + echo "### Operating System Details" + cat /etc/os-release + echo "" + echo "### CPU Information" + lscpu | grep "Model name\|CPU(s)" + echo "" + echo "### Memory Information" + free -h + echo "" + echo "### Disk Information" + df -h + echo "" + echo "### Kernel Version" + uname -a + echo "" + echo "### Who am I" + whoami + echo "" + echo "### Current Directory" + pwd + echo "" + echo "### Environment Variables" + env | sort + + - run: echo "🍏 This job's status is ${{ job.status }}." \ No newline at end of file diff --git a/labs/screenshots/.DS_Store b/labs/screenshots/.DS_Store new file mode 100644 index 00000000..f0fc68c7 Binary files /dev/null and b/labs/screenshots/.DS_Store differ diff --git a/labs/screenshots/img1.png b/labs/screenshots/img1.png new file mode 100644 index 00000000..658c580d Binary files /dev/null and b/labs/screenshots/img1.png differ diff --git a/labs/screenshots/img2.png b/labs/screenshots/img2.png new file mode 100644 index 00000000..19964d93 Binary files /dev/null and b/labs/screenshots/img2.png differ diff --git a/labs/screenshots/img3.png b/labs/screenshots/img3.png new file mode 100644 index 00000000..da43a3e4 Binary files /dev/null and b/labs/screenshots/img3.png differ diff --git a/labs/screenshots/img4.png b/labs/screenshots/img4.png new file mode 100644 index 00000000..dc9bd1be Binary files /dev/null and b/labs/screenshots/img4.png differ diff --git a/labs/screenshots/img5.png b/labs/screenshots/img5.png new file mode 100644 index 00000000..13415149 Binary files /dev/null and b/labs/screenshots/img5.png differ diff --git a/labs/screenshots/img6.png b/labs/screenshots/img6.png new file mode 100644 index 00000000..8cab13e3 Binary files /dev/null and b/labs/screenshots/img6.png differ diff --git a/labs/screenshots/img7.png b/labs/screenshots/img7.png new file mode 100644 index 00000000..3fed7437 Binary files /dev/null and b/labs/screenshots/img7.png differ diff --git a/labs/submission1.md b/labs/submission1.md new file mode 100644 index 00000000..62f51f44 --- /dev/null +++ b/labs/submission1.md @@ -0,0 +1,25 @@ +# Lab 1 Submission +## Task 1: SSH Commit Signature Verification + +Commit signing proves who made code changes and that they weren't altered. It uses special digital signatures to confirm that a developer really created those commits and nobody secretly changed them. This stops people from pretending to be other team members, creates trust in team projects, and makes automated software pipelines safer. + +In DevOps workflows, where code moves quickly from writing to deployment, signed commits are important because they keep track of who did what and make sure only trusted changes get deployed. + +#### Screenshots for Task 1: +![SSH Key on GitHub](screenshots/img1.png) +![Verified Commit](screenshots/img3.png) +![Terminal Logs](screenshots/img2.png) + +## Task 2: PR Template & Checklist + +PR templates make team collaboration smoother and more efficient. By providing a standard structure for every pull request, they ensure that all necessary information is included from the start. When everyone uses the same format with sections like Goal, Changes, and Testing, reviewers know exactly where to look for information instead of going through comments or asking repetitive questions. The checklist also prevents common mistakes, like forgetting to update documentation or accidentally including sensitive files. + +Templates saves time and reduces frustration for everyone. New team members can quickly understand what's expected, experienced developers don't waste time on incomplete submissions, and the entire review process becomes more predictable. In fast-paced DevOps workflows where code moves quickly through automated pipelines, these templates create a reliable foundation that helps teams maintain quality while moving fast together. + +Several challenges emerged during setup. I initially found the repository structure confusing: understanding that work flows from the course repo to my fork to a feature branch. SSH key setup also required troubleshooting: I had to re-add my key as a "Signing Key" instead of just for authentication. Finally, I learned PR templates must exist on the main branch before they auto-fill, and they serve as empty forms that users complete when opening each PR. + +#### Screenshots for Task 2: +![Template Existance in Terminal](screenshots/img4.png) +![Template Existance on GitHub](screenshots/img5.png) +![PR template auto-filling the description](screenshots/img6.png) +![PR template filled](screenshots/img7.png) diff --git a/labs/submission2.md b/labs/submission2.md new file mode 100644 index 00000000..7545bb3c --- /dev/null +++ b/labs/submission2.md @@ -0,0 +1,353 @@ +# Lab 2 Submission +## Task 1: Git Object Model Exploration +### Command outputs for object inspection: +#### 1. Commit Object +``` +arinapetuhova@192 DevOps-Intro % git log --oneline -1 +74c38e3 (HEAD -> feature/lab2) Add test file + +arinapetuhova@192 DevOps-Intro % git cat-file -p 74c38e3 +tree b660713fc594e96a202a3eb9a00bfdceee997270 +parent fcfd20b880bf4ce1ea665b92c0f087db645d79c4 +author Arina Petuhova <119685834+arinapetukhova@users.noreply.github.com> 1770370868 +0300 +committer Arina Petuhova <119685834+arinapetukhova@users.noreply.github.com> 1770370868 +0300 +gpgsig -----BEGIN SSH SIGNATURE----- + U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgUDPLkiD0daseOoV9XP0Y0kgQg1 + G2jn3Herr0uZ2bnroAAAADZ2l0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5 + AAAAQEE3uLqt0EDdiEL5Pz0DKJhHTAF9m3fNsvV1cNAq9d2OdA8ckqtH+KPp7kUrBnBfUV + lG3dPPezDBMLQ3hTj1lQs= + -----END SSH SIGNATURE----- + +Add test file +``` + +#### 2. Tree Object +``` +arinapetuhova@192 DevOps-Intro % git cat-file -p b660713fc594e96a202a3eb9a00bfdceee997270 +100644 blob 6e60bebec0724892a7c82c52183d0a7b467cb6bb README.md +040000 tree a1061247fd38ef2a568735939f86af7b1000f83c app +040000 tree f0fbfea6739bbc15d0f4a5408cdb109a9c6cbb4f labs +040000 tree d3fb3722b7a867a83efde73c57c49b5ab3e62c63 lectures +100644 blob 2eec599a1130d2ff231309bb776d1989b97c6ab2 test.txt +``` + +#### 3. Blob Object +``` +arinapetuhova@192 DevOps-Intro % git cat-file -p 2eec599a1130d2ff231309bb776d1989b97c6ab2 +Test content +``` + +### Object Type Explanations + +- **Blob**: Represents file content - a snapshot of a file at a specific point in time. +- **Tree**: Represents directory structure - a listing of files (blobs) and subdirectories (trees) with their permissions and names. +- **Commit**: Represents a snapshot of the repository - metadata including author, timestamp, parent commits, and a pointer to the root tree. + +### Git Storage Analysis +Git stores repository data as a directed acyclic graph of objects where commits point to trees, trees point to blobs and other trees, and blobs contain actual file content. Each object is content-addressed using hashes, making Git a content-addressable filesystem where identical content is stored only once. + +### Example Object Content + +**Blob Example**: `2eec599a1130d2ff231309bb776d1989b97c6ab2` contains the exact file content "Test content". + +**Tree Example**: `b660713fc594e96a202a3eb9a00bfdceee997270` shows the repository structure with 2 blobs (README.md and test.txt) and 3 trees (app, labs, lectures). + +**Commit Example**: `74c38e3` contains metadata including parent commit `fcfd20b`, author information, timestamp, GPG signature, and commit message "Add test file". + +## Task 2: Reset and Reflog Recovery +### Testing git reset --soft HEAD~1: +``` +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git log --oneline +6eec726 (HEAD -> git-reset-practice) Third commit +a7dbccb Second commit +c7cf749 First commit + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git reflog +6eec726 (HEAD -> git-reset-practice) HEAD@{0}: commit: Third commit +a7dbccb HEAD@{1}: commit: Second commit +c7cf749 HEAD@{2}: commit: First commit + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git reset --soft HEAD~1 + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git log --oneline +a7dbccb (HEAD -> git-reset-practice) Second commit +c7cf749 First commit + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git reflog +a7dbccb (HEAD -> git-reset-practice) HEAD@{0}: reset: moving to HEAD~1 +6eec726 HEAD@{1}: commit: Third commit +a7dbccb (HEAD -> git-reset-practice) HEAD@{2}: commit: Second commit +c7cf749 HEAD@{3}: commit: First commit + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git status +On branch git-reset-practice +Changes to be committed: + (use "git restore --staged ..." to unstage) + modified: file.txt +``` + +**Explanation:** here, I ran commands `git log --oneline` and `git reflog` to see the last commits and HEAD position. After running `git reset --soft HEAD~1` to reset the last commit while keeping index & working tree, I verified with `git log --oneline` (shows only 2 commits), `git reflog` (shows reset action), and `git status` (shows changes are staged). + +### Testing git reset --hard HEAD@{1}: +``` +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git reset --hard HEAD@{1} +HEAD is now at 6eec726 Third commit + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git log --oneline +6eec726 (HEAD -> git-reset-practice) Third commit +a7dbccb Second commit +c7cf749 First commit + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git reflog +6eec726 (HEAD -> git-reset-practice) HEAD@{0}: reset: moving to HEAD@{1} +a7dbccb HEAD@{1}: reset: moving to HEAD~1 +6eec726 (HEAD -> git-reset-practice) HEAD@{2}: commit: Third commit +a7dbccb HEAD@{3}: commit: Second commit +c7cf749 HEAD@{4}: commit: First commit +``` +**Explanation:** here, I ran command `git reset --hard HEAD@{1}` recovered the repository to the state it was in before the previous `git reset --soft HEAD~1`. +I verified it with `git log --oneline` (shows all 3 commits) and `git reflog` (shows reset to previous HEAD@{1} action). + +### Testing git reset --hard HEAD~1: +``` +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git reset --hard HEAD~1 +HEAD is now at a7dbccb Second commit + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git log --oneline +a7dbccb (HEAD -> git-reset-practice) Second commit +c7cf749 First commit + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git reflog +a7dbccb (HEAD -> git-reset-practice) HEAD@{0}: reset: moving to HEAD~1 +6eec726 HEAD@{1}: reset: moving to HEAD@{1} +a7dbccb (HEAD -> git-reset-practice) HEAD@{2}: reset: moving to HEAD~1 +6eec726 HEAD@{3}: commit: Third commit +a7dbccb (HEAD -> git-reset-practice) HEAD@{4}: commit: Second commit +c7cf749 HEAD@{5}: commit: First commit + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git status +On branch git-reset-practice +nothing to commit, working tree clean + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git reset --hard HEAD@{1} +HEAD is now at 6eec726 Third commit + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git log --oneline +6eec726 (HEAD -> git-reset-practice) Third commit +a7dbccb Second commit +c7cf749 First commit + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git reflog +6eec726 (HEAD -> git-reset-practice) HEAD@{0}: reset: moving to HEAD@{1} +a7dbccb HEAD@{1}: reset: moving to HEAD~1 +6eec726 (HEAD -> git-reset-practice) HEAD@{2}: reset: moving to HEAD@{1} +a7dbccb HEAD@{3}: reset: moving to HEAD~1 +6eec726 (HEAD -> git-reset-practice) HEAD@{4}: commit: Third commit +a7dbccb HEAD@{5}: commit: Second commit +c7cf749 HEAD@{6}: commit: First commit +``` + +**Explanation:** here, I ran command `git reset --hard HEAD~1` to reset the last commit without keeping index & working tree. I verified it with `git log --oneline` (shows only 2 commits), `git reflog` (shows reset action), and `git status` (shows that no changes are staged). Then everything is again recovered with `git reset --hard HEAD@{1}` nad checked with `git log --oneline` and `git reflog`. + +### Reset Changes: +- `git reset --soft HEAD~1` moves HEAD back one commit while keeping both the index and working tree unchanged. The commit disappears from history, but all its changes remain staged. +- `git reset --hard HEAD~1` also moves HEAD back but discards everything, both the index and working tree revert to the previous commit's state, making changes permanently lost from the current branch. + +### Recovery via Reflog: +The `reflog` records every HEAD movement. Even after a destructive `--hard` reset, the "lost" commit remains in reflog with a reference like HEAD@{1}. By using `git reset --hard HEAD@{1}`, it's possible to completely restore the repository to that earlier state, recovering both the commit history and all associated file changes. + +## Task 3: Visualize Commit History +### Graph Output +``` +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git log --oneline --graph --all +* 44a6364 (side-branch) Side branch commit +* 736f6df (HEAD -> feature/lab2, origin/feature/lab2) task 2 +* bcf2426 task 1 +* 5a2f7d3 lab 2, task 1 +* 74c38e3 Add test file +* fcfd20b (origin/feature/lab1, feature/lab1) feat: task 2 added +* 6b3604a feat: SSH screenshots added +* 3c838d9 remove .DS_Store file +* e7d91e0 remove screenshots folder +* d6b77e7 feat: SSH screenshots added +* 63466e5 feat: SSH screenshots added +* 71b5840 feat: SSH screenshots added +* 3cb6e7e verified commit +* b9a96c1 verified commit +* 0f2867f verified commit +``` + +**Commit messages list:** +- verified commit, +- feat: SSH screenshots added, +- remove screenshots folder, +- remove .DS_Store file, +- feat: task 2 added, +- Add test file, +- lab 2, task 1, +- task 1, +- task 2, +- Side branch commit + +**Reflection:** the graph visualization provides insight into branch relationships and development flow. It clearly shows where branches diverge (at commit 736f6df for side-branch) and reveals that feature/lab1 stopped development while feature/lab2 continued, helping understand the project's evolution at a glance. + +## Task 4: Tagging Commits +### Tag names and commands used: +**For the first tag:** +``` +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git tag v1.0.0 +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git push origin v1.0.0 +Enumerating objects: 7, done. +Counting objects: 100% (7/7), done. +Delta compression using up to 8 threads +Compressing objects: 100% (4/4), done. +Writing objects: 100% (4/4), 1.13 KiB | 1.13 MiB/s, done. +Total 4 (delta 3), reused 0 (delta 0), pack-reused 0 (from 0) +remote: Resolving deltas: 100% (3/3), completed with 3 local objects. +To https://github.com/arinapetukhova/DevOps-Intro.git + * [new tag] v1.0.0 -> v1.0.0 +``` + +**For the second tag:** +``` +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git tag v1.1.0 +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git push origin v1.1.0 +Enumerating objects: 7, done. +Counting objects: 100% (7/7), done. +Delta compression using up to 8 threads +Compressing objects: 100% (4/4), done. +Writing objects: 100% (4/4), 619 bytes | 619.00 KiB/s, done. +Total 4 (delta 3), reused 0 (delta 0), pack-reused 0 (from 0) +remote: Resolving deltas: 100% (3/3), completed with 3 local objects. +To https://github.com/arinapetukhova/DevOps-Intro.git + * [new tag] v1.1.0 -> v1.1.0 +``` + +### Associated commit hashes: +``` +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git show v1.0.0 --quiet +commit dca8922603375fbf462fbd9cbc91ca01d529ae71 (tag: v1.0.0) +Author: Arina Petuhova <119685834+arinapetukhova@users.noreply.github.com> +Date: Sat Feb 7 15:00:16 2026 +0300 + + task 3 & 4 +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git show v1.1.0 --quiet +commit aedb4327ac1872dfb768603aaae29483bbc5994e (HEAD -> feature/lab2, tag: v1.1.0) +Author: Arina Petuhova <119685834+arinapetukhova@users.noreply.github.com> +Date: Sat Feb 7 15:07:34 2026 +0300 + + new tag +``` + +### Why tags matter: +1. Versioning: Tags provide immutable reference points for specific releases, enabling precise version tracking and rollback capabilities. + +2. CI/CD Triggers: Automated pipelines can be configured to deploy or test only when specific tags are pushed (e.g., v1.* triggers production deployment). + +3. Release Management: Tags create GitHub releases with downloadable source code, changelogs, and binary assets, facilitating organized software distribution. + +## Task 5: git switch vs git checkout vs git restore +### Commands & Outputs: +``` +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git switch -c test-command-comparison +Switched to a new branch 'test-command-comparison' + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git branch + feature/lab1 + feature/lab2 + main +* test-command-comparison + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git switch -c cmd-compare +Switched to a new branch 'cmd-compare' + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git switch - +Switched to branch 'test-command-comparison' + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git checkout -b cmd-compare-2 +Switched to a new branch 'cmd-compare-2' + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git checkout test-command-comparison +Switched to branch 'test-command-comparison' + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % echo "original content" > demo.txt + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git add demo.txt + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git commit -m "Add demo.txt" +[test-command-comparison c4505a0] Add demo.txt + 1 file changed, 1 insertion(+) + create mode 100644 demo.txt +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git status +On branch test-command-comparison +nothing to commit, working tree clean + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % echo "scratch changes" >> demo.txt + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git status +On branch test-command-comparison +Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git restore ..." to discard changes in working directory) + modified: demo.txt + +no changes added to commit (use "git add" and/or "git commit -a") + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git restore demo.txt + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git status +On branch test-command-comparison +nothing to commit, working tree clean + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % echo "new content" > demo.txt + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git add demo.txt + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git status +On branch test-command-comparison +Changes to be committed: + (use "git restore --staged ..." to unstage) + modified: demo.txt + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git restore --staged demo.txt + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git status +On branch test-command-comparison +Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git restore ..." to discard changes in working directory) + modified: demo.txt + +no changes added to commit (use "git add" and/or "git commit -a") + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git restore --source=HEAD~1 demo.txt + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git status +On branch test-command-comparison +Changes not staged for commit: + (use "git add/rm ..." to update what will be committed) + (use "git restore ..." to discard changes in working directory) + deleted: demo.txt + +no changes added to commit (use "git add" and/or "git commit -a") + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git checkout -- demo.txt + +arinapetuhova@MacBook-Air-Arina DevOps-Intro % git status +On branch test-command-comparison +nothing to commit, working tree clean +``` + +**Conclusion:** +- Use `git restore` when discarding uncommitted changes in the working directory (unstaged changes) or unstaging files (staged changes) +- Use `git checkout` when wanting to switch branches, create new branches, or restore files to their committed state (older syntax) +- Use `git switch` specifically for switching between branches in a cleaner, more intuitive way, as it's designed only for branch operations unlike checkout which has multiple functions. + +## Task 6: GitHub Community Engagement +### Challenges & Solutions: +The main challenges I faced were related to understanding the Git Object Model and commands I hadn't used before (reset, reflog, restore). After reading the theory, I understood how they work. + +### GitHub Community: +Starring repositories matters in open source because it shows appreciation to maintainers, helps projects gain visibility in rankings, and serves as a bookmark to revisit useful code later. + +Following developers helps in team projects by keeping you updated on their contributions, and supports professional growth by exposing you to their techniques, projects, and community insights. \ No newline at end of file diff --git a/labs/submission3.md b/labs/submission3.md new file mode 100644 index 00000000..a968eacb --- /dev/null +++ b/labs/submission3.md @@ -0,0 +1,70 @@ +# Lab 3 Submission +## Task 1: First GitHub Actions Workflow + +### Link to the successful workflow run: +[Link](https://github.com/arinapetukhova/DevOps-Intro/actions/runs/21980663308) + +### Key Concepts Learned: +GitHub Actions is an automation tool triggered by repository events. **Jobs** are the main execution units that run independently; this workflow contained a single job named "Explore-GitHub-Actions". **Steps** are individual tasks within a job, such as echo commands or the actions/checkout action. **Runners** are the virtual machines that execute workflows; this job ran on a GitHub-hosted Linux runner. **Triggers** are events that initiate workflows; this workflow was configured to run on push events. + +### What Caused This Run to Trigger +The workflow was triggered by a push event to a new branch feature/lab3. When the branch was created locally and pushed to the remote repository, GitHub detected the push and automatically started the workflow. + +### Analysis of Workflow Execution Process +First, GitHub set up a Linux runner with version 2.331.0. The actions/checkout@v5 action was downloaded using a specific hash to ensure version consistency. + +The workflow then executed several echo steps that printed information about the trigger event, runner environment, and branch name. Next, the checkout action cloned the repository onto the runner. Authentication was configured using GITHUB_TOKEN, and the exact commit from the feature/lab3 branch was checked out. A directory listing confirmed the presence of project files (app, labs, lectures, README.md, and test.txt). + +After all steps completed successfully, post-job cleanup was performed. Git configuration settings were removed, authentication headers were unset, and the runner was terminated. This demonstrates how GitHub Actions provides a temporary, isolated, and secure environment for each workflow execution. + +## Task 2: Manual Trigger + System Information + +### Link to the manual workflow run: +[Link](https://github.com/arinapetukhova/DevOps-Intro/actions/runs/21989980188) + +### Changes made to the workflow file: +`workflow_dispatch` was added: +``` +on: + push: + workflow_dispatch: +``` + +System information collection step was added, as well: +``` +- name: Gather system information + run: | + echo "## System Information" + echo "### Operating System Details" + cat /etc/os-release + echo "" + echo "### CPU Information" + lscpu | grep "Model name\|CPU(s)" + echo "" + echo "### Memory Information" + free -h + echo "" + echo "### Disk Information" + df -h + echo "" + echo "### Kernel Version" + uname -a + echo "" + echo "### Who am I" + whoami + echo "" + echo "### Current Directory" + pwd + echo "" + echo "### Environment Variables" + env | sort +``` + +### Gathered system information from runner: +The runner is an Ubuntu 24.04.3 LTS virtual machine hosted on Azure, running Linux kernel 6.14.0-1017-azure. Hardware includes an AMD EPYC 7763 processor with 4 CPU cores, 15GB RAM (plus 3GB of swap space), and 145GB storage with 92GB free. The repository is cloned to /home/runner/work/DevOps-Intro/DevOps-Intro under the "runner" user account. + +### Manual vs Automatic Workflow Triggers: +The last run was triggered manually using `workflow_dispatch`. Automatic push triggers run immediately after code changes, ideal for continuous integration. Manual triggers provide on-demand control for testing and debugging. Both trigger types execute the same steps. + +### Analysis of runner environment and capabilities: +The runner gives user a clean, separate, and temporary setup with many tools already installed, like different versions of Java, Go, Android SDK, and .NET. It is short-lived — a new one is created for each job and removed afterward, so no leftover files affect future runs. GitHub-hosted runners always have the same hardware and software setup, and security is handled automatically — login info and secrets are erased when the job finishes. The environment is built specifically for automated testing and integration tasks. \ No newline at end of file diff --git a/labs/submission4.md b/labs/submission4.md new file mode 100644 index 00000000..c57c8ce1 --- /dev/null +++ b/labs/submission4.md @@ -0,0 +1,332 @@ +# Lab 3 Submission +## Task 1: Operating System Analysis +### System Boot Time: +``` +arina_os@arinaos:~$ systemd-analyze +systemd-analyze blame +Startup finished in 1.773s (kernel) + 2min 1.743s (userspace) = 2min 3.516s +graphical.target reached after 2min 1.724s in userspace. +2min 43ms systemd-networkd-wait-online.service + 1.527s snapd.seeded.service + 1.483s snapd.service + 818ms NetworkManager.service + 447ms dev-mapper-ubuntu\x2d\x2dvg\x2dubuntu\x2d\x2dlv.device + 390ms dev-loop9.device + 387ms dev-loop10.device + 384ms dev-loop8.device + 328ms gnome-remote-desktop.service + 281ms power-profiles-daemon.service + 265ms polkit.service + 255ms NetworkManager-wait-online.service + 220ms snapd.apparmor.service + 218ms accounts-daemon.service + 216ms avahi-daemon.service + 208ms udisks2.service + 189ms secureboot-db.service + 183ms rsyslog.service + 165ms apparmor.service + 150ms grub-common.service + 148ms ModemManager.service + 146ms switcheroo-control.service + 143ms dev-loop3.device + 142ms dev-loop7.device + 141ms dev-loop4.device + 139ms dev-loop2.device + 137ms dev-loop5.device + 127ms dev-loop1.device + 126ms systemd-resolved.service + 125ms dev-loop6.device + 124ms apport.service + 120ms dbus.service + 119ms e2scrub_reap.service + 104ms pd-mapper.service + 102ms user@1000.service + 95ms systemd-networkd.service + 92ms systemd-oomd.service + 92ms dev-loop0.device + 82ms dev-mqueue.mount + 81ms sys-kernel-tracing.mount + 81ms sys-kernel-debug.mount + 80ms dev-hugepages.mount + 75ms keyboard-setup.service + 74ms kmod-static-nodes.service + 73ms lvm2-monitor.service + 71ms systemd-timesyncd.service + 69ms systemd-journald.service + 67ms modprobe@configfs.service + 65ms systemd-udev-trigger.service + 63ms systemd-journal-flush.service + 62ms systemd-logind.service + 62ms multipathd.service + 61ms upower.service + 60ms modprobe@drm.service + 59ms sysstat.service + 59ms systemd-udevd.service + 53ms modprobe@fuse.service + 49ms packagekit.service + 49ms geoclue.service + 47ms systemd-tmpfiles-setup.service + 47ms grub-initrd-fallback.service + 45ms systemd-fsck@dev-disk-by\x2duuid-b4d72888\x2d7ae9\x2d4e31\x2dae57\x2d> + 42ms wpa_supplicant.service + 42ms systemd-hostnamed.service + 42ms snap-bare-5.mount + 41ms gdm.service + 41ms systemd-modules-load.service + 39ms systemd-binfmt.service + 39ms snap-core22-1666.mount + 38ms snap-core22-1752.mount + 37ms systemd-tmpfiles-setup-dev-early.service + 37ms systemd-remount-fs.service + 35ms snap-firefox-4845.mount + 33ms boot.mount + 32ms snap-firefox-5698.mount + 31ms snap-gnome\x2d42\x2d2204-178.mount + 30ms cups.service + 29ms snap-gtk\x2dcommon\x2dthemes-1535.mount + 28ms sys-fs-fuse-connections.mount + 28ms systemd-localed.service + 28ms sys-kernel-config.mount + 27ms snap-snapd-21761.mount + 25ms colord.service + 25ms snap-snapd-25939.mount + 24ms systemd-fsck@dev-disk-by\x2duuid-CCB2\x2dE67C.service + 23ms swap.img.swap + 23ms kerneloops.service + 22ms snap-thunderbird-491.mount + 22ms systemd-random-seed.service + 22ms systemd-sysctl.service + 20ms snap-thunderbird-547.mount + 16ms plymouth-read-write.service + 16ms finalrd.service + 16ms console-setup.service + 14ms alsa-restore.service + 13ms lxd-installer.socket + 9ms proc-sys-fs-binfmt_misc.mount + 9ms ufw.service + 8ms user-runtime-dir@1000.service + 8ms systemd-update-utmp.service + 8ms snapd.socket + 7ms rtkit-daemon.service + 7ms systemd-user-sessions.service + 7ms boot-efi.mount + 7ms modprobe@dm_mod.service + 6ms spice-vdagentd.service + 6ms modprobe@efi_pstore.service + 5ms setvtrgb.service + 5ms modprobe@loop.service + 4ms openvpn.service + 4ms systemd-tmpfiles-setup-dev.service + 4ms plymouth-quit-wait.service + 3ms systemd-update-utmp-runlevel.service + 68us blk-availability.service +``` +**Observations:** A total boot time of 2 minutes and 3 seconds was observed. The kernel was loaded in only 1.7 seconds, but the userspace took 2 minutes to start. The biggest delay was caused by `systemd-networkd-wait-online.service`, which waited 2 minutes for the network to be ready. The commands were run on a virtual machine, that's why the network was slower to initialize. Snap packages were also seen adding about 1.5 seconds to the boot process. + +### System Load: +``` +arina_os@arinaos:~$ uptime +w + 16:59:39 up 4 min, 1 user, load average: 0.24, 0.18, 0.07 + 16:59:39 up 4 min, 1 user, load average: 0.24, 0.18, 0.07 +USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT +arina_os tty2 - 16:57 4:12 0.01s 0.01s /usr/libexec/gn +``` +**Observations:** The virtual machine was seen running for only 4 minutes after boot. Load averages of 0.24, 0.18, and 0.07 were displayed, which are very low numbers. This means the virtual CPU is not being heavily used. Only one user was found logged into the system through the graphical interface. + +### Resource-Intensive Processes: +``` +arina_os@arinaos:~$ ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head -n 6 +ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -n 6 + PID PPID CMD %MEM %CPU + 1841 1660 /usr/bin/gnome-shell 9.9 8.8 + 2403 1841 /usr/libexec/mutter-x11-fra 2.1 0.1 + 2320 1660 /usr/libexec/gsd-xsettings 1.8 0.1 + 2276 1841 gjs /usr/share/gnome-shell/ 1.5 0.3 + 2414 1810 /usr/libexec/evolution-data 1.4 0.0 + PID PPID CMD %MEM %CPU + 1841 1660 /usr/bin/gnome-shell 9.9 8.8 + 2077 1955 /usr/libexec/ibus-extension 0.7 1.1 + 2600 1660 /usr/libexec/gnome-terminal 1.2 1.0 + 1 0 /sbin/init 0.3 0.8 + 798 1 /usr/lib/snapd/snapd 0.9 0.4 +``` +**Observations:** GNOME Shell was identified as the most resource-heavy process, with 9.9% of memory and 8.8% of CPU being used by it. This is expected because the desktop environment needs more resources to run the graphical interface in a virtual machine. Other processes like `mutter`, `ibus-extension`, and `gnome-terminal` were seen using very little memory and CPU. No signs of system struggle were noticed. + +### Service Relationships: +``` +arina_os@arinaos:~$ systemctl list-dependencies +systemctl list-dependencies multi-user.target +default.target +\u25cf \u251c\u2500accounts-daemon.service +\u25cf \u251c\u2500gdm.service +\u25cf \u251c\u2500gnome-remote-desktop.service +\u25cf \u251c\u2500power-profiles-daemon.service +\u25cf \u251c\u2500switcheroo-control.service +\u25cb \u251c\u2500systemd-update-utmp-runlevel.service +\u25cf \u251c\u2500udisks2.service +\u25cf \u2514\u2500multi-user.target +\u25cf \u251c\u2500anacron.service +\u25cf \u251c\u2500apport.service +\u25cf \u251c\u2500avahi-daemon.service +\u25cf \u251c\u2500console-setup.service +\u25cf \u251c\u2500cron.service +\u25cf \u251c\u2500cups-browsed.service +\u25cf \u251c\u2500cups.path +\u25cf \u251c\u2500cups.service +\u25cf \u251c\u2500dbus.service +\u25cb \u251c\u2500dmesg.service +\u25cb \u251c\u2500e2scrub_reap.service +\u25cb \u251c\u2500grub-common.service +\u25cb \u251c\u2500grub-initrd-fallback.service +\u25cf \u251c\u2500kerneloops.service +lines 1-23 +``` +**Observations:** A clear service hierarchy was shown: `default.target` was seen as the main goal that starts all graphical services like the login screen. Inside it, `multi-user.target` was found handling background services such as printing, scheduling, and error reporting. Active services were marked with black dots and inactive ones with white dots. + +### Login Activity: +``` +arina_os@arinaos:~$ who -a +last -n 5 + system boot 2026-02-20 16:55 +LOGIN ttyAMA0 2026-02-20 16:57 1144 id=AMA0 + run-level 5 2026-02-20 16:57 +arina_os ? seat0 2026-02-20 16:57 ? 1722 (login screen) +arina_os + tty2 2026-02-20 16:57 00:08 1722 (tty2) +arina_os tty2 tty2 Fri Feb 20 16:57 still logged in +arina_os seat0 login screen Fri Feb 20 16:57 still logged in +reboot system boot 6.8.0-47-generic Fri Feb 20 16:55 still running +reboot system boot 6.8.0-47-generic Fri Feb 20 16:53 still running +reboot system boot 6.8.0-47-generic Fri Feb 20 16:51 still running + +wtmp begins Wed Aug 28 08:25:05 2024 +``` +**Observations:** Three reboots were noticed at 16:51, 16:53, and 16:55, which were different attempts of starting the virtual machine. The current session was started at 16:55, and the user login was made at 16:57 through the graphical terminal. Only one user was found logged in. + +### Memory Allocation: +``` +arina_os@arinaos:~$ free -h +cat /proc/meminfo | grep -e MemTotal -e SwapTotal -e MemAvailable + total used free shared buff/cache available +Mem: 3.8Gi 1.0Gi 2.2Gi 57Mi 823Mi 2.8Gi +Swap: 3.8Gi 0B 3.8Gi +MemTotal: 3996336 kB +MemAvailable: 2953684 kB +SwapTotal: 3995644 kB +``` +**Observations:** A total of 3.8 GB of RAM was seen allocated to the virtual machine. Only 1.0 GB of it was being used. Free memory of 2.2 GB was available, and 2.8 GB was shown as available for applications. Swap space of 3.8 GB was configured but no swap was being used because enough physical memory exists. About 823 MB was being used for cache to improve performance. + +### Top Memory-Consuming Process: +GNOME Shell (PID: 1841) is the top memory-consuming process, using 9.9% of the system's total memory. + +### Resource Utilization Patterns Observed: +A "single heavy user" pattern is visible where GNOME Shell (PID 1841) dominates both memory (9.9%) and CPU (8.8%), while all other processes use 2% or less of resources. A parent-child hierarchy exists with GNOME Shell spawning helper processes like `mutter-x11-fra` for window management and `gjs` for extensions. Background services such as `snapd` and `init` use minimal resources (under 1%), showing the system is well-optimized and not under any pressure despite being a virtual machine. + +## Task 2: Networking Analysis +### Traceroute Execution: +``` +arina_os@arinaos:~$ traceroute github.com +traceroute to github.com (140.82.121.4), 64 hops max + 1 192.168.64.1 1.146ms 0.524ms 0.535ms + 2 10.91.48.1 6.109ms 4.793ms 6.397ms + 3 10.252.6.1 5.820ms 5.107ms 8.373ms + 4 188.170.164.34 8.542ms 9.917ms 10.533ms + 5 * * * +``` + +### DNS Resolution Check: +``` +arina_os@arinaos:~$ dig github.com + +; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> github.com +;; global options: +cmd +;; Got answer: +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29388 +;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 + +;; OPT PSEUDOSECTION: +; EDNS: version: 0, flags:; udp: 65494 +;; QUESTION SECTION: +;github.com. IN A + +;; ANSWER SECTION: +github.com. 17 IN A 140.82.121.4 + +;; Query time: 18 msec +;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) +;; WHEN: Sat Feb 21 14:32:13 UTC 2026 +;; MSG SIZE rcvd: 55 +``` + +### Captured DNS Traffic: +``` +arina_os@arinaos:~$ sudo tcpdump -c 5 -i any 'port 53' -nn +tcpdump: data link type LINUX_SLL2 +tcpdump: verbose output suppressed, use -v[v]... for full protocol decode +listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes +14:42:37.621513 lo In IP 127.0.0.1.36234 > 127.0.0.53.53: 48675+ [1au] A? google.com. (51) +14:42:37.622199 enp0s1 Out IP 192.168.64.2.38302 > 192.168.64.1.53: 32857+ [1au] A? google.com. (39) +14:42:37.637177 enp0s1 In IP 192.168.64.1.53 > 192.168.64.2.38302: 32857 6/0/1 A 142.250.9.138, A 142.250.9.113, A 142.250.9.102, A 142.250.9.101, A 142.250.9.139, A 142.250.9.100 (135) +14:42:37.637565 lo In IP 127.0.0.53.53 > 127.0.0.1.36234: 48675 6/0/1 A 142.250.9.138, A 142.250.9.113, A 142.250.9.102, A 142.250.9.101, A 142.250.9.139, A 142.250.9.100 (135) +14:43:06.530191 lo In IP 127.0.0.1.45313 > 127.0.0.53.53: 20295+ A? microsoft.com. (31) +5 packets captured +18 packets received by filter +0 packets dropped by kernel +``` + +### PTR Lookups: +``` +arina_os@arinaos:~$ dig -x 8.8.4.4 +dig -x 1.1.2.2 + +; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> -x 8.8.4.4 +;; global options: +cmd +;; Got answer: +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60460 +;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 + +;; OPT PSEUDOSECTION: +; EDNS: version: 0, flags:; udp: 65494 +;; QUESTION SECTION: +;4.4.8.8.in-addr.arpa. IN PTR + +;; ANSWER SECTION: +4.4.8.8.in-addr.arpa. 4502 IN PTR dns.google. + +;; Query time: 29 msec +;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) +;; WHEN: Sat Feb 21 14:35:11 UTC 2026 +;; MSG SIZE rcvd: 73 + + +; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> -x 1.1.2.2 +;; global options: +cmd +;; Got answer: +;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54997 +;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 + +;; OPT PSEUDOSECTION: +; EDNS: version: 0, flags:; udp: 65494 +;; QUESTION SECTION: +;2.2.1.1.in-addr.arpa. IN PTR + +;; AUTHORITY SECTION: +1.in-addr.arpa. 900 IN SOA ns.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 23597 7200 1800 604800 3600 + +;; Query time: 29 msec +;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) +;; WHEN: Sat Feb 21 14:35:11 UTC 2026 +;; MSG SIZE rcvd: 137 +``` + +### Insights on Network Paths Discovered: +A traceroute to github.com was performed, and 4 successful hops were seen before the requests timed out. The first hop was identified as the local virtual machine gateway at `192.168.64.1`, and responses were received in under 1 millisecond. Private IP addresses (`10.x.x.x`) were used for the next two hops, which means they are part of the internet provider's internal network. Response times of 5-8 milliseconds were recorded for these hops. A public router at `188.170.164.34` was reached on the fourth hop, with response times between 8-10 milliseconds. Asterisks were shown for all probes after that. This does not mean github.com is unreachable - it just means the router at hop 5 is probably configured to ignore traceroute requests for security reasons. + +### Analysis of DNS Query/Response Patterns: +A DNS query for github.com was performed using the `dig` command. A successful response with status NOERROR was received. The query was completed in only 18 milliseconds. The local Ubuntu resolver at `127.0.0.53` was used as the DNS server. This is systemd-resolved, which caches DNS results to improve speed. The IP address `140.82.121.4` was returned for github.com in the answer section. A TTL of 17 seconds was shown, which is quite short and indicates the address is changed frequently for load balancing purposes. Only one IP address was given in the response. + +### Comparison of Reverse Lookup Results: +A reverse lookup was performed for `8.8.4.4`, and it was successful. The name "dns.google" was returned with a `NOERROR` status. This was expected because `8.8.4.4` is known to be one of Google's public DNS servers. A TTL of 4502 seconds (about 75 minutes) was shown. A reverse lookup was also performed for `1.1.2.2`, but a different result was received. An `NXDOMAIN` status was returned, which means no reverse record exists for this IP address. No answer section was provided, but an authority section with information from `APNIC` was shown instead. Both lookups took 29 milliseconds, so the resolver performance was consistent. + +### Example DNS Query from Packet Capture: +One DNS query was captured when google.com was looked up. At 14:42:37, a packet was sent from the virtual machine. The source IP was `192.168.64.2` and the source port was `38302`. The destination IP was `192.168.64.1` and the destination port was `53`. An `A record` for google.com was being requested. The packet was marked as "Out", meaning it was leaving the computer through the `enp0s1 network interface`. A query ID of 32857 was used to match this request with its response later. The total size of the query was 39 bytes. \ No newline at end of file diff --git a/test.txt b/test.txt new file mode 100644 index 00000000..2eec599a --- /dev/null +++ b/test.txt @@ -0,0 +1 @@ +Test content