|
| 1 | +--- |
| 2 | +title: GitHub Action & GitHub App |
| 3 | +slug: github-action-and-github-app |
| 4 | +startDate: 2024-02-01 |
| 5 | +endDate: 2024-02-18 |
| 6 | +stacks: [Python, Lambda, DynamoDB, GitHub, GitHub-Action, GitHub-App] |
| 7 | +company: upwork |
| 8 | + |
| 9 | +--- |
| 10 | + |
| 11 | +This project evolved through several iterations, each marked by specific enhancements and the introduction of new features. Below is a detailed account of these versions, highlighting the key concepts, changes, and technical implementations. |
| 12 | + |
| 13 | +### Version 1 (Feb 1, 2024 - Feb 2, 2024) |
| 14 | +<details> |
| 15 | +<summary>Key concepts in Version 1</summary> |
| 16 | + |
| 17 | +In the initial version, I developed a GitHub Action workflow designed to activate upon every push to the repository and each pull request. The primary objectives were to execute coverage and linter checks for a Rust project, capture these outputs, and automatically comment on the pull request with the results. This workflow was successfully implemented and rigorously tested within the repository. <sup>[1](https://github.com/yubrew/ac-outpost/blob/main/.github/workflows/pr-tasks.yml)</sup>. |
| 18 | +</details> |
| 19 | + |
| 20 | +### Version 2 (Feb 4, 2024 - Feb 10, 2024) |
| 21 | +<details> |
| 22 | +<summary>Key Changes in Version 2</summary> |
| 23 | + |
| 24 | +- Significant advancements were made in this iteration: |
| 25 | +- A new GitHub Action workflow, `ai-audit.yml`, was created to operate on every push and pull request, enhancing our project's automation and integration capabilities. <sup>[2](https://github.com/yubrew/ac-outpost/blob/main/.github/workflows/ai-audit.yml)</sup> |
| 26 | + |
| 27 | +- A key task was to aggregate all Rust files following a specified schema, excluding any that matched defined patterns ('test', 'schema'). This was achieved through a straightforward shell script, which efficiently processed and prepared these files for further analysis. |
| 28 | + - Note: I am sharing these files because they are on a public repo. |
| 29 | + - I've done this with a simple shell script below: |
| 30 | + |
| 31 | + <details> |
| 32 | + <summary><strong>rust_file_aggregator.sh</strong></summary> |
| 33 | + |
| 34 | + ```sh |
| 35 | + #!/bin/bash |
| 36 | + |
| 37 | + # Initialize the file |
| 38 | + echo "" > rust.md |
| 39 | + |
| 40 | + # Find all the Rust files in the current directory |
| 41 | + # and its subdirectories. |
| 42 | + # and iterate over the files |
| 43 | + find . -name "*.rs" | while read file; do |
| 44 | + # Check if the file name matches the exclusion patterns |
| 45 | + # ['test', 'schema'] |
| 46 | + if [[ $file != *test* && $file != *schema* ]]; then |
| 47 | + # Print the file name |
| 48 | + echo "Processing file: $file" |
| 49 | + # Append the file name to the output file |
| 50 | + echo "### FILE: $(basename $file)" >> rust.md |
| 51 | + # Append the file content to the output file |
| 52 | + cat $file >> rust.md |
| 53 | + fi |
| 54 | + done |
| 55 | + ``` |
| 56 | + </details> |
| 57 | + |
| 58 | + - These files were then transmitted to a mock API endpoint (Which I created), crafted using AWS Lambda and DynamoDB, demonstrating a practical application of serverless technologies in automating code review processes. |
| 59 | + |
| 60 | +- Additionally, a `webhook` workflow was set up to trigger upon receiving webhook events <sup>[3](https://github.com/yubrew/ac-outpost/blob/main/.github/workflows/webhook.yml)</sup>, further integrated with two AWS Lambda functions for dynamic API simulation `API-CRON` and repository data management `Webhook`. |
| 61 | + - `API-CRON` Which was part of Mock API to randomly simulate the API behavior. |
| 62 | + - `Webhook` Which reads data from the DynamoDB and add comment to the PR. |
| 63 | + |
| 64 | + |
| 65 | +</details> |
| 66 | + |
| 67 | +### Version 3 (Feb 12, 2024- Feb 18, 2024) |
| 68 | +<details> |
| 69 | +<summary>Key Changes in Version 3</summary> |
| 70 | + |
| 71 | +This phase marked a significant shift in the project's direction, with the introduction of a GitHub App and Webhook, both hosted on AWS Lambda, showcasing a complex, integrated development environment: |
| 72 | +
|
| 73 | +- The flow of that GitHub was as follow: |
| 74 | + - The user will install the GitHub App on their repository. |
| 75 | + - The GitHub App webhook will be triggered by the GitHub event. |
| 76 | + - The GitHub App will send the data to the AWS Lambda. |
| 77 | + - The AWS Lambda will process the data, save to the DynamoDB and commit the required file and secrets to the repository. |
| 78 | + - `ai-audit.yml` and `rust_file_aggregator.sh` will be committed to the repository. |
| 79 | + - The `MOCK API` url will be saved to the repository secrets. |
| 80 | +- The `version 2` Lambda was used as it is just updated the following: |
| 81 | + - The `webhook` Lambda updated to update the comment on the PR with the data from the Mock API. |
| 82 | +- The new Lambda `GithubAppWebhook` added to handle the GitHub App webhook event. |
| 83 | +
|
| 84 | +</details> |
| 85 | +
|
| 86 | +### Lessons Learned |
| 87 | +- How to create GitHub App and seemelessly integrate webhook with it that hosted on AWS Lambda. |
0 commit comments