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/test.txt b/test.txt new file mode 100644 index 00000000..2eec599a --- /dev/null +++ b/test.txt @@ -0,0 +1 @@ +Test content