Git Pipeline SFTP AWS EC2

### Prerequisites
1. **AWS EC2 Instance**: Ensure your EC2 instance is running and you have SSH/SFTP access.
2. **SFTP Credentials**: You should have the necessary credentials (IP address, username, password/private key) to access your EC2 instance via SFTP.
3. **Git Repository**: Your project should be stored in a Git repository (e.g., GitHub, Bitbucket).

### Steps to Set Up the Pipeline

1. **Create a Deployment Script**:
Create a shell script to handle the deployment process. This script will be executed during the deployment stage of your pipeline.

# deploy.sh
   #!/bin/bash

   # Variables
   EC2_USER="ubuntu"                      # Replace with your EC2 username
   EC2_HOST="ec2-16-170-254-93.eu-north-1.compute.amazonaws.com" # Replace with your EC2 instance's public IP
   EC2_PORT="22"                          # SFTP Port (default is 22)
   DEPLOY_DIR="/var/www/share"            # Directory on EC2 where files will be deployed
   LOCAL_DIR="path/to/your/project"       # Path to your local project directory

   # Sync files using lftp or rsync (example using lftp)
   lftp -u $EC2_USER,sftp://$EC2_HOST <<EOF
   set ssl:verify-certificate no
   mirror --reverse --delete --verbose $LOCAL_DIR $DEPLOY_DIR
   bye
   EOF

Make sure to give execute permission to the script:

chmod +x deploy.sh

2. **Configure Git Hooks**:
You can use Git hooks to trigger the deployment script after a successful push to the main branch. Create a `post-receive` hook on your Git repository:

# .git/hooks/post-receive
   #!/bin/bash

   # Deploy script
   /path/to/your/deploy.sh

Make the hook executable:

chmod +x .git/hooks/post-receive

3. **Set Up Continuous Integration/Deployment (CI/CD) Tool**:
If you're using a CI/CD tool (like GitHub Actions, GitLab CI, Jenkins, etc.), you can configure it to trigger your deployment script. Here’s an example using GitHub Actions:

# .github/workflows/deploy.yml
   name: Deploy to EC2

   on:
     push:
       branches:
         - main

   jobs:
     deploy:
       runs-on: ubuntu-latest
       steps:
         - name: Checkout code
           uses: actions/checkout@v2

         - name: Deploy to EC2
           env:
             EC2_USER: ${{ secrets.EC2_USER }}
             EC2_HOST: ${{ secrets.EC2_HOST }}
             EC2_KEY: ${{ secrets.EC2_KEY }}
           run: |
             ssh -i $EC2_KEY -o StrictHostKeyChecking=no $EC2_USER@$EC2_HOST 'bash -s' < deploy.sh

Ensure you add the necessary secrets (like `EC2_USER`, `EC2_HOST`, `EC2_KEY`) in your repository settings.

4. **Test the Deployment**:
Push changes to your repository and check if the pipeline triggers successfully. Verify that the files are correctly deployed to your EC2 instance.

### Additional Considerations
– **Security**: Ensure your SFTP connection is secure, and consider using SSH keys for authentication instead of passwords.
– **Error Handling**: Add error handling in your deployment script to handle any failures gracefully.
– **Dependencies**: If your application has dependencies (like Composer for PHP or npm for Node.js), ensure your deployment script includes steps to install/update them on the server.

This is a basic outline to get you started. Depending on your specific requirements, you might need to adjust the script or pipeline configuration.

### Updated Deployment Script

# deploy.sh
#!/bin/bash

# Variables
EC2_USER="ubuntu"                        # Replace with your EC2 username
EC2_HOST="ec2-16-170-254-93.eu-north-1.compute.amazonaws.com" # Replace with your EC2 instance's public IP
PEM_FILE="/path/to/your/key.pem"        # Path to your PEM file
DEPLOY_DIR="/var/www/share"              # Directory on EC2 where files will be deployed
LOCAL_DIR="path/to/your/project"         # Path to your local project directory

# Sync files using lftp or rsync (example using rsync)
rsync -avz -e "ssh -i $PEM_FILE -o StrictHostKeyChecking=no" $LOCAL_DIR/ $EC2_USER@$EC2_HOST:$DEPLOY_DIR

### Explanation of the Script:
1. **PEM_FILE**: Set the path to your PEM file.
2. **rsync Command**: This command synchronizes your local project directory with the deployment directory on the EC2 instance using SSH with the specified PEM file.
– `-avz`: This flag enables archive mode, verbose output, and compression during transfer.
– `-e "ssh -i $PEM_FILE"`: This option tells `rsync` to use the specified PEM file for authentication.
– `-o StrictHostKeyChecking=no`: This option disables strict host key checking, which is useful if you're deploying to a new instance for the first time.

### Git Hook (if applicable)
If you decide to use Git hooks as mentioned earlier, ensure the `deploy.sh` script is referenced correctly.

### CI/CD Tool Configuration (if applicable)
If you are using a CI/CD tool (like GitHub Actions), make sure to reference the PEM file correctly. Here’s an example for GitHub Actions:

# .github/workflows/deploy.yml
name: Deploy to EC2

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Deploy to EC2
        env:
          EC2_USER: ${{ secrets.EC2_USER }}
          EC2_HOST: ${{ secrets.EC2_HOST }}
          PEM_FILE: ${{ secrets.PEM_FILE }}  # Store your PEM file content in a secret
        run: |
          echo "$PEM_FILE" > key.pem
          chmod 600 key.pem
          rsync -avz -e "ssh -i key.pem -o StrictHostKeyChecking=no" ./ $EC2_USER@$EC2_HOST:/var/www/share
          rm key.pem  # Clean up the PEM file after the deployment

### Important Notes
– **Permissions**: Make sure the PEM file has the correct permissions (readable only by the user executing the script).
– **Security**: Be cautious about how you store and handle your PEM file, especially in CI/CD environments. Using secrets to manage sensitive information is a good practice.

Test the script after making these changes to ensure it works correctly with your PEM file for SFTP access.

### 1. Root of Your Project Directory
You can place `deploy.sh` in the root of your project directory. This way, it's easily accessible and can be executed directly from there.

/path/to/your/project/
├── deploy.sh
├── src/
├── README.md
└── other_project_files/

### 2. A Dedicated Scripts Directory
If you prefer to keep your project organized, you might create a dedicated directory for scripts:

/path/to/your/project/
├── scripts/
│   └── deploy.sh
├── src/
├── README.md
└── other_project_files/

### 3. Inside a Deployment Directory
If your project has a deployment-related folder, you can place it there:

/path/to/your/project/
├── deployment/
│   └── deploy.sh
├── src/
├── README.md
└── other_project_files/

### Setting Up Your CI/CD Environment
– **Local Execution**: If you're executing the script locally, navigate to the directory where the script is located before running it. For example:

cd /path/to/your/project/
  ./deploy.sh

– **CI/CD Tools**: If you are using a CI/CD tool (like GitHub Actions), you can configure the workflow to reference the `deploy.sh` script from its location. For example, if you place it in the root directory, you can reference it as `./deploy.sh` in your workflow YAML file.

### Permissions
Ensure that your script is executable. You can set the executable permission with the following command:

chmod +x /path/to/your/project/deploy.sh

### Summary
Choose a location that makes sense for your project's structure, and remember to adjust any paths in your CI/CD configuration or Git hooks to match the location where you placed the `deploy.sh` script.

### 1. **Local Server**
– **`deploy.sh`**: This script will be executed on your local machine (or CI/CD server) to initiate the deployment process. It contains the logic for syncing your local project files to your AWS EC2 instance.

### 2. **AWS EC2 Instance**
– **Deployment Directory**: The target directory on your EC2 instance (e.g., `/var/www/share`) is where your files will be uploaded. You don’t need to place the `deploy.sh` script on the EC2 instance; it’s only used locally to perform the deployment.

### Workflow
1. **Prepare Your Local Environment**:
– Place the `deploy.sh` script in a convenient location on your local machine or in your project's directory (e.g., the root of your project or a dedicated scripts folder).

2. **Execute the Script**:
– Run the `deploy.sh` script from your local machine. The script will use SFTP/SSH to connect to your EC2 instance and synchronize files from your local project directory to the designated directory on the EC2 instance.

3. **Deployment to EC2**:
– When you run the script, it will upload the files to the specified path on the EC2 instance, ensuring that your application is updated with the latest code.

### Summary
– Place `deploy.sh` on your **local server** (development environment).
– The deployment will push files to the **AWS EC2 instance** but does not require the script to be on the EC2 instance itself.

### 1. Using Git Hooks

You can create a Git hook that automatically runs the `deploy.sh` script after every push to a specific branch (commonly the `main` or `master` branch). Here’s how to do it:

#### Step-by-Step for Git Hooks

1. **Navigate to Your Local Git Repository**:
Go to the root directory of your local Git repository where your project is located.

2. **Create a Post-Receive Hook**:
If you’re using a bare repository or want to set this up on the server-side, you would create the `post-receive` hook. However, since you’re deploying from your local environment, you can use a `post-commit` or `post-push` hook.

Create a file named `post-commit` in the `.git/hooks` directory:

touch .git/hooks/post-commit

3. **Edit the Hook**:
Open the `post-commit` file in your preferred text editor and add the following content:

#!/bin/bash
   # Run the deployment script after a commit
   /path/to/your/project/deploy.sh

4. **Make the Hook Executable**:
Ensure the hook is executable:

chmod +x .git/hooks/post-commit

5. **Usage**:
Now, whenever you make a commit in your local repository, the `deploy.sh` script will automatically run, deploying your changes to the AWS EC2 instance.

### 2. Using a CI/CD Tool

If you prefer a more robust solution, you can use a CI/CD tool like GitHub Actions, GitLab CI, or Jenkins to automate the deployment process. Here’s a basic example using GitHub Actions:

#### GitHub Actions Example

1. **Create a Workflow File**:
In your GitHub repository, create a workflow file in the `.github/workflows` directory (e.g., `deploy.yml`):

name: Deploy to EC2

   on:
     push:
       branches:
         - main  # Replace with your target branch

   jobs:
     deploy:
       runs-on: ubuntu-latest
       steps:
         - name: Checkout code
           uses: actions/checkout@v2

         - name: Set up SSH
           env:
             PEM_FILE: ${{ secrets.PEM_FILE }}  # Store your PEM file content in a GitHub secret
           run: |
             echo "$PEM_FILE" > key.pem
             chmod 600 key.pem

         - name: Deploy to EC2
           env:
             EC2_USER: ${{ secrets.EC2_USER }}
             EC2_HOST: ${{ secrets.EC2_HOST }}
           run: |
             rsync -avz -e "ssh -i key.pem -o StrictHostKeyChecking=no" ./ $EC2_USER@$EC2_HOST:/var/www/share
             rm key.pem  # Clean up the PEM file after deployment

2. **Configure Secrets**:
– Go to your GitHub repository settings and add the necessary secrets (`PEM_FILE`, `EC2_USER`, `EC2_HOST`) to store sensitive information.

3. **Deploying**:
Whenever you push changes to the specified branch (e.g., `main`), GitHub Actions will automatically run the workflow, executing the `deploy.sh` equivalent and deploying your code to the AWS EC2 instance.

### Summary
– **Using Git Hooks**: Automatically deploy when committing changes locally by adding a hook that runs the `deploy.sh` script.
– **Using CI/CD**: Set up a pipeline (e.g., GitHub Actions) to automate deployment whenever you push changes to your repository.

Choose the method that best fits your workflow!

### Overview

1. **You make changes to your code locally** (in your development environment).
2. **You commit and push those changes to your Git repository** (e.g., GitHub).
3. **A deployment script (`deploy.sh`) runs to upload those changes to your AWS EC2 instance**.

### Steps to Set It Up

#### Step 1: Create the Deployment Script

1. **Create a file named `deploy.sh`** in your project’s root directory or a designated `scripts` folder. This script will handle the deployment.
2. **Add the following code** to `deploy.sh` (make sure to modify the variables according to your setup):

#!/bin/bash

   # Variables
   EC2_USER="ubuntu"  # Replace with your EC2 username
   EC2_HOST="ec2-16-170-254-93.eu-north-1.compute.amazonaws.com"  # Your EC2 instance's public IP
   PEM_FILE="/path/to/your/key.pem"  # Path to your PEM file
   DEPLOY_DIR="/var/www/share"  # Directory on EC2 where files will be deployed
   LOCAL_DIR="./"  # Path to your local project directory (current directory)

   # Sync files using rsync
   rsync -avz -e "ssh -i $PEM_FILE -o StrictHostKeyChecking=no" $LOCAL_DIR/ $EC2_USER@$EC2_HOST:$DEPLOY_DIR

3. **Make the script executable**:

chmod +x deploy.sh

#### Step 2: Link Git to the Deployment Process

##### Option A: Using a Git Hook

1. **Navigate to your project’s Git hooks directory**:

cd .git/hooks

2. **Create a file named `post-commit`**:

touch post-commit

3. **Add the following to `post-commit`**:

#!/bin/bash
   # Run the deployment script after a commit
   /path/to/your/project/deploy.sh

4. **Make the hook executable**:

chmod +x post-commit

– **What This Does**: After each commit, the `deploy.sh` script runs, uploading your latest code to the EC2 instance.

##### Option B: Using a CI/CD Tool (e.g., GitHub Actions)

1. **In your GitHub repository**, create a folder named `.github/workflows` if it doesn't already exist.

2. **Create a file named `deploy.yml`** inside that folder with the following content:

name: Deploy to EC2

   on:
     push:
       branches:
         - main  # Change this to your target branch

   jobs:
     deploy:
       runs-on: ubuntu-latest
       steps:
         - name: Checkout code
           uses: actions/checkout@v2

         - name: Set up SSH
           env:
             PEM_FILE: ${{ secrets.PEM_FILE }}  # Store your PEM file content as a secret
           run: |
             echo "$PEM_FILE" > key.pem
             chmod 600 key.pem

         - name: Deploy to EC2
           env:
             EC2_USER: ${{ secrets.EC2_USER }}
             EC2_HOST: ${{ secrets.EC2_HOST }}
           run: |
             rsync -avz -e "ssh -i key.pem -o StrictHostKeyChecking=no" ./ $EC2_USER@$EC2_HOST:/var/www/share
             rm key.pem  # Clean up the PEM file after deployment

3. **Add your PEM file and EC2 details to GitHub secrets**:
– Go to your GitHub repository settings and add secrets for `PEM_FILE`, `EC2_USER`, and `EC2_HOST`.

– **What This Does**: Every time you push changes to the specified branch, GitHub Actions will automatically run the deployment process.

### Summary

– **Local Script (`deploy.sh`)**: Handles the file transfer from your local machine to the EC2 instance.
– **Git Hooks (Option A)**: Automatically runs the deployment script after each commit.
– **CI/CD Tool (Option B)**: Automatically runs the deployment script whenever you push to a specified branch.

### Choose Your Method

If you prefer simplicity and only work locally, **go with the Git hooks option**. If you want to automate the deployment process more robustly with your repository, **use a CI/CD tool** like GitHub Actions.

Let me know if you need more clarity on any specific part!

### Step 1: Create the Deployment Script

1. **Create a file named `deploy.sh`** in your project root (the same directory as your `.git` folder).
2. **Add the following code to `deploy.sh`** (make sure to adjust the variables):

#!/bin/bash

   # Variables
   EC2_USER="ubuntu"  # Replace with your EC2 username
   EC2_HOST="ec2-16-170-254-93.eu-north-1.compute.amazonaws.com"  # Your EC2 instance's public IP
   PEM_FILE="/path/to/your/key.pem"  # Path to your PEM file
   DEPLOY_DIR="/var/www/share"  # Directory on EC2 where files will be deployed
   LOCAL_DIR="./"  # Path to your local project directory

   # Sync files using rsync
   rsync -avz -e "ssh -i $PEM_FILE -o StrictHostKeyChecking=no" $LOCAL_DIR/ $EC2_USER@$EC2_HOST:$DEPLOY_DIR

3. **Make the script executable**:

chmod +x deploy.sh

### Step 2: Set Up a Git Hook

1. **Navigate to your project's `.git/hooks` directory**:

cd .git/hooks

2. **Create a file named `post-push`**:

touch post-push

3. **Add the following content to `post-push`**:

#!/bin/bash
   # Run the deployment script after a push to master
   /path/to/your/project/deploy.sh

4. **Make the hook executable**:

chmod +x post-push

### Step 3: Push Changes to the Master Branch

– Now, whenever you push changes to the `master` branch, the `deploy.sh` script will run automatically, deploying your latest code to the EC2 instance.

### Summary

1. Create and configure `deploy.sh` with the correct EC2 settings.
2. Set up the `post-push` Git hook to call the deployment script.
3. Push to the `master` branch to trigger the deployment.

Let me know if you need any further clarification or assistance!

### Method 1: Using GitHub Actions

1. **Create a GitHub Action Workflow**:
– In your GitHub repository, create the following directory structure: `.github/workflows/`.
– Inside the `workflows` directory, create a file named `deploy.yml`.

2. **Add the Following Content to `deploy.yml`**:

name: Deploy to EC2

   on:
     push:
       branches:
         - master  # Trigger on push to master branch

   jobs:
     deploy:
       runs-on: ubuntu-latest
       steps:
         - name: Checkout code
           uses: actions/checkout@v2

         - name: Set up SSH
           env:
             PEM_FILE: ${{ secrets.PEM_FILE }}  # Store your PEM file content in GitHub secrets
           run: |
             echo "$PEM_FILE" > key.pem
             chmod 600 key.pem

         - name: Deploy to EC2
           env:
             EC2_USER: ${{ secrets.EC2_USER }}  # Store your EC2 username in GitHub secrets
             EC2_HOST: ${{ secrets.EC2_HOST }}  # Store your EC2 host in GitHub secrets
           run: |
             rsync -avz -e "ssh -i key.pem -o StrictHostKeyChecking=no" ./ $EC2_USER@$EC2_HOST:/var/www/share
             rm key.pem  # Clean up the PEM file after deployment

3. **Configure GitHub Secrets**:
– Go to your GitHub repository settings.
– Under "Secrets and variables," add the following secrets:
– **`PEM_FILE`**: The content of your PEM file.
– **`EC2_USER`**: Your EC2 username (e.g., `ubuntu`).
– **`EC2_HOST`**: Your EC2 instance's public IP address.

### Method 2: Using a Post-Receive Hook (if you host your own Git server)

If you have your own Git server or are using a bare repository, you can create a post-receive hook that will deploy the code to the EC2 instance whenever someone pushes to the `master` branch.

1. **Navigate to Your Bare Repository**:
Go to the directory where your bare repository is located (if you're using a self-hosted Git server).

2. **Create or Edit the `post-receive` Hook**:
– Create a file named `post-receive` in the `hooks` directory of your bare repository.

3. **Add the Following Content**:

#!/bin/bash
   while read oldrev newrev refname; do
     if [ "$refname" = "refs/heads/master" ]; then
       # Deploy to EC2
       /path/to/your/deploy.sh
     fi
   done

4. **Make the Hook Executable**:

chmod +x post-receive

### Summary

– **GitHub Actions**: Set up a workflow that triggers on any push to the `master` branch, automatically deploying to the EC2 instance.
– **Post-Receive Hook**: If you have your own Git server, set up a post-receive hook to run the deployment script whenever someone pushes to the `master` branch.

### Choose Your Method

– **Use GitHub Actions** if you are using GitHub to host your repository.
– **Use a Post-Receive Hook** if you are managing your own Git server.

This way, any push to the `master` branch from any developer will trigger the deployment to your AWS EC2 instance. Let me know if you need further assistance with any step!

### Method 1: Using the GitHub Web Interface

1. **Go to Your GitHub Repository**:
– Open your web browser and navigate to your GitHub repository.

2. **Create the `.github` Directory**:
– Click on the **"Add file"** button.
– Select **"Create new file"** from the dropdown.
– In the "Name your file" field, type `.github/.gitkeep`. This creates the `.github` directory.

3. **Create the `workflows` Directory**:
– After creating the `.github` directory, you can create the `workflows` directory within it. Click on the **"Add file"** button again.
– Select **"Create new file"**.
– In the "Name your file" field, type `.github/workflows/.gitkeep`. This creates the `workflows` directory.

4. **Create the `deploy.yml` File**:
– Click on **"Add file"** again and select **"Create new file"**.
– In the "Name your file" field, type `.github/workflows/deploy.yml`.
– Add the workflow configuration from the previous response, and click **"Commit new file"** at the bottom.

### Method 2: Using Git Commands on Your Local Machine

1. **Clone Your Repository (if not already cloned)**:
If you haven't cloned your repository yet, do so by running:

git clone https://github.com/username/repository.git
   cd repository

Replace `username` and `repository` with your actual GitHub username and repository name.

2. **Create the Directory Structure**:
Run the following commands to create the directory structure:

mkdir -p .github/workflows

3. **Create the `deploy.yml` File**:
Create the `deploy.yml` file inside the `workflows` directory:

touch .github/workflows/deploy.yml

4. **Open the `deploy.yml` File**:
Open `deploy.yml` in a text editor and add the workflow configuration from the previous response.

5. **Commit and Push Your Changes**:
After making the changes, run the following commands:

git add .github/workflows/deploy.yml
   git commit -m "Add GitHub Actions workflow for deployment"
   git push origin master

### Summary

– You can create the `.github/workflows/` directory structure either via the GitHub web interface or by using Git commands on your local machine.
– Make sure to add the `deploy.yml` file with the necessary workflow configuration for deployment.

Let me know if you have any questions or need further assistance!

### Method 1: Using Command Line (Terminal or Command Prompt)

#### On Linux or macOS:

1. **Open Terminal**.
2. Use the `mkdir` command to create a directory. For example, to create a directory named `my_directory`, type:

mkdir my_directory

3. **Create Nested Directories**: If you want to create nested directories (like `.github/workflows`), use the `-p` flag:

mkdir -p .github/workflows

#### On Windows:

1. **Open Command Prompt or PowerShell**.
2. Use the `mkdir` command similarly. For example, to create a directory named `my_directory`, type:

mkdir my_directory

3. **Create Nested Directories**: To create nested directories:

mkdir .githubworkflows

### Method 2: Using File Explorer (Windows) or Finder (macOS)

#### On Windows:

1. Open **File Explorer**.
2. Navigate to the location where you want to create the new directory.
3. Right-click in the folder and select **New > Folder**.
4. Name the folder (e.g., `.github`), and repeat to create the `workflows` folder inside it.

#### On macOS:

1. Open **Finder**.
2. Navigate to the location where you want to create the new directory.
3. Right-click (or Ctrl + click) in the folder and select **New Folder**.
4. Name the folder (e.g., `.github`), and repeat to create the `workflows` folder inside it.

### Method 3: Using Integrated Development Environments (IDEs)

If you're using an IDE (like Visual Studio Code, IntelliJ, etc.):

1. Open the IDE and load your project.
2. Right-click on the project or folder in the file explorer pane.
3. Select **New Folder** or **Create Directory** and name it accordingly (e.g., `.github`, then `workflows` inside it).

### Summary

– Use the `mkdir` command in the terminal for a quick command-line method.
– Use File Explorer or Finder for a graphical interface.
– IDEs usually have options to create new directories easily through context menus.

Let me know if you need any more help!

### Creating a Directory in GitHub

1. **Go to Your GitHub Repository**:
– Open your web browser and navigate to your GitHub repository.

2. **Add a New File**:
– Click on the **"Add file"** button, which is usually found above the file list on the repository page.
– Select **"Create new file"** from the dropdown menu.

3. **Name Your Directory**:
– In the "Name your file" field, type the name of the directory you want to create, followed by a `/`. For example, to create a directory named `.github`, type:

.github/

– This indicates that you're creating a directory.

4. **Add a File in the New Directory**:
– After typing the directory name followed by `/`, you need to name a file that will be created inside this new directory. For example, to create a `workflows` directory and a `deploy.yml` file within it, type:

.github/workflows/deploy.yml

– GitHub will automatically create the `.github` directory and the `workflows` subdirectory.

5. **Add Content to the File**:
– In the text editor that appears, you can add the contents of the `deploy.yml` file (e.g., the GitHub Actions workflow configuration).

6. **Commit the New File**:
– Scroll down to the "Commit new file" section.
– Enter a commit message, such as "Add GitHub Actions workflow".
– Choose whether to commit directly to the `master` branch or create a new branch.
– Click the **"Commit new file"** button.

### Summary

1. Navigate to your repository.
2. Click on **"Add file"** > **"Create new file"**.
3. Type the directory and file name (e.g., `.github/workflows/deploy.yml`).
4. Add the content and commit the new file.

This method allows you to create directories and files directly from the GitHub web interface. Let me know if you need any more assistance!

### Contents to Track in the `.github` Directory

1. **Workflows**: If you are using GitHub Actions for CI/CD, the `workflows` subdirectory should contain YAML files that define your workflows (e.g., `deploy.yml`).

2. **Issue Templates**: You can create `.github/ISSUE_TEMPLATE` to store issue templates that guide users when creating new issues in your repository.

3. **Pull Request Templates**: Similarly, you can create a `.github/PULL_REQUEST_TEMPLATE.md` file to provide a template for pull requests.

4. **Funding Information**: You can create a `FUNDING.yml` file to specify how people can fund your work.

5. **Code of Conduct**: If you have a code of conduct for your project, you can place it in `.github/CODE_OF_CONDUCT.md`.

### Tracking the `.github` Directory

Since the `.github` directory is part of your repository, you should track it using Git. To ensure that it's tracked, follow these steps:

1. **Add the Directory and Files**: If you created the `.github` directory and its contents through the GitHub interface, they are automatically tracked when you commit them.

2. **Using Git Commands**: If you created the directory and files locally, you can track them by running the following commands:

git add .github
   git commit -m "Add .github directory and workflows"
   git push origin master  # or the appropriate branch

### Summary

– Yes, the `.github` directory should be tracked in your repository to manage workflows, templates, and other configurations.
– Make sure to commit and push any changes to this directory to keep it updated and available for collaboration.

Let me know if you have any more questions or need further assistance!

### When to Update the `.github` Directory on EC2

1. **GitHub Actions Workflows**: If you update or add GitHub Actions workflows in the `.github/workflows` directory, those changes should not need to be on your EC2 instance since they run directly in GitHub's infrastructure when triggered. However, if your deployment process requires any files or configurations from `.github`, then they should be kept in sync.

2. **Other Configuration Files**: If you have other configuration files in the `.github` directory (like issue templates, pull request templates, etc.) that are relevant to your application, you might want to ensure that these are available in your EC2 instance if they play a role in your development or deployment processes.

### How to Update the `.github` Directory on EC2

To ensure that the `.github` directory is updated on your EC2 instance whenever you push changes to your repository, include it in your deployment process. This can be done using a CI/CD pipeline (like GitHub Actions) or through Git hooks. Here’s how you can handle it:

#### 1. **Using GitHub Actions (Recommended)**

If you're using GitHub Actions for deployment, the entire repository (including the `.github` directory) will be synchronized with your EC2 instance when you push changes. The workflow defined in `.github/workflows/deploy.yml` would typically include all files in your repository. Here's a brief outline of how it works:

– The workflow triggers on a push to the `master` branch.
– It uses `rsync` to sync the files, including `.github`, to the EC2 instance.

#### 2. **Using a Post-Receive Hook (If Hosting Your Own Git)**

If you're managing your own Git server, you can set up a post-receive hook that also updates the `.github` directory on your EC2 instance whenever changes are pushed to the repository.

### Example Command

If you're using `rsync` in your deployment script, make sure you include the `.github` directory:

rsync -avz ./ $EC2_USER@$EC2_HOST:/var/www/share

This command will copy the entire repository to the specified path on your EC2 instance, including the `.github` directory.

### Summary

– **Update Requirement**: If the `.github` directory contains relevant configurations or scripts, it should be updated on your EC2 instance.
– **Deployment Process**: Ensure your deployment process (like GitHub Actions or Git hooks) includes the `.github` directory to keep it in sync with your repository.

Let me know if you have any further questions or need clarification!

### What’s Typically Inside `.github`

1. **Workflows**: Contains YAML files for GitHub Actions, which automate CI/CD processes (e.g., testing, deployment).
2. **Issue Templates**: Helps guide users in creating issues, making it easier for you to manage contributions and bug reports.
3. **Pull Request Templates**: Provides a standardized format for pull requests.
4. **Code of Conduct**: Sets guidelines for community behavior.
5. **Funding Information**: Details how users can support your project financially.

### Reasons to Track `.github`

1. **CI/CD Automation**: If you’re using GitHub Actions, you need the workflows to be tracked so that they can run whenever relevant events (like pushes) occur.
2. **Contribution Management**: Templates for issues and pull requests help maintain a consistent contribution experience.
3. **Community Standards**: A code of conduct or other documents can help establish community expectations.

### When to Include `.github` in `.gitignore`

You might consider adding `.github` to `.gitignore` only in specific cases, such as:

1. **Personal or Experimental Projects**: If the repository is for personal use and you don’t need workflows, templates, or similar configurations.
2. **Temporary or Non-Public Projects**: If you’re working on something that won’t be shared publicly and you don’t want to track those configurations.

### Summary

– **Include** the `.github` directory in your repository to utilize its features effectively (especially workflows and templates).
– **Do Not** add it to `.gitignore` unless you have a specific reason not to track it.

If you need more information or have further questions, feel free to ask!

### Steps to Create the `.github` Directory without Tracking

1. **Create the Directory Locally**:
– Use the command line or GitHub interface to create the `.github` directory and any files you want to include (e.g., workflows, templates).

2. **Add `.github` to `.gitignore`**:
– Open your `.gitignore` file (create one if it doesn't exist) in your project root.
– Add the following line to ignore the `.github` directory:

.github/

3. **Commit Your Changes** (if necessary):
– If you already created the directory and you want to commit other changes in your repository (excluding the `.github` directory), make sure to add only the files you want to track:

git add .
   git reset .github  # This untracks the .github directory
   git commit -m "Initial commit without tracking .github"

### Summary

1. Create the `.github` directory and any necessary files.
2. Add `.github/` to your `.gitignore` file to prevent it from being tracked.
3. Commit your changes while ensuring that the `.github` directory is not included.

By following these steps, you'll have the `.github` directory created locally without it being tracked by Git. If you have any more questions or need further assistance, feel free to ask!

### Steps to Resolve the Issue

1. **Check Permissions**:
– Make sure that the user you are using to connect to the EC2 instance has the appropriate permissions to modify files and directories in your project directory. You can check the permissions using:

ls -l /var/www/shareyourthoughts/.git/info

2. **Use `rsync` Options**:
– You can modify your `rsync` command to skip preserving the timestamps of directories. This avoids the permission issue:

rsync -avz --no-times ./ $EC2_USER@$EC2_HOST:/var/www/shareyourthoughts

– The `–no-times` option tells `rsync` not to set the modification times for files, which should prevent the error.

3. **Ownership and Group Settings**:
– Ensure that the files and directories in your project are owned by the user you are using for the `rsync` operation. If necessary, you can change the ownership using:

sudo chown -R ubuntu:ubuntu /var/www/shareyourthoughts

– Replace `ubuntu:ubuntu` with the correct user and group if different.

4. **Use `sudo`**:
– If you have sufficient privileges, you might want to run your `rsync` command with `sudo` to ensure it has the necessary permissions:

sudo rsync -avz ./ $EC2_USER@$EC2_HOST:/var/www/shareyourthoughts

5. **Confirm Directory Existence**:
– Make sure that the directory `/var/www/shareyourthoughts` exists on the EC2 instance. If it doesn’t, create it using:

mkdir -p /var/www/shareyourthoughts

### Example of a Modified `rsync` Command

Here’s an example of an updated `rsync` command that incorporates the suggestions:

rsync -avz --no-times ./ $EC2_USER@$EC2_HOST:/var/www/shareyourthoughts

### Summary

– Check file permissions and ownership in your EC2 instance.
– Use `–no-times` with `rsync` to avoid timestamp setting issues.
– Ensure the directory exists and use `sudo` if necessary.

By following these steps, you should be able to resolve the permission error you're encountering. Let me know if you need further assistance!

### 1. **Check Current Permissions**

You can check the current permissions and ownership of the directory where you're trying to set timestamps:

ls -ld /var/www/shareyourthoughts/.git/info

### 2. **Change Ownership**

If the ownership is not set to the user you are connecting with (e.g., `ubuntu`), you can change the ownership using the `chown` command:

sudo chown -R ubuntu:ubuntu /var/www/shareyourthoughts

Replace `ubuntu:ubuntu` with the appropriate username and group if you are using a different user.

### 3. **Set Directory Permissions**

You need to set appropriate permissions on the directories so that the user can read, write, and execute them. You can set permissions using the `chmod` command:

sudo chmod -R 755 /var/www/shareyourthoughts

This command sets read, write, and execute permissions for the owner and read and execute permissions for the group and others.

### 4. **Set Sticky Bit (Optional)**

If you want to ensure that only the owner of a file can delete or modify it, you can set the sticky bit:

sudo chmod +t /var/www/shareyourthoughts

### 5. **Verify Permissions**

After making changes, you can verify the permissions and ownership again:

ls -ld /var/www/shareyourthoughts

### 6. **Testing the `rsync` Command**

After ensuring that the permissions and ownership are correctly set, you can retry the `rsync` command without the `–no-times` option:

rsync -avz ./ $EC2_USER@$EC2_HOST:/var/www/shareyourthoughts

### Summary

1. Check current permissions and ownership.
2. Change ownership using `chown`.
3. Set directory permissions using `chmod`.
4. Verify the changes and test the `rsync` command again.

These steps should allow you to set timestamps correctly. If you have further questions or issues, feel free to ask!

### Change Ownership

To change the ownership of the `.git/info` directory (and potentially other directories and files within the repository) to the `ubuntu` user (or the user you are using), follow these steps:

1. **Change Ownership**:
– Run the following command to change the ownership of the entire repository to the `ubuntu` user and group. This will allow you to set timestamps and perform other operations without encountering permission issues:

sudo chown -R ubuntu:ubuntu /var/www/shareyourthoughts

2. **Verify Ownership Change**:
– After changing ownership, verify the change by running:

ls -l /var/www/shareyourthoughts/.git/info

You should see that the owner and group have changed to `ubuntu`.

### Update Permissions (If Needed)

If you still want to ensure the permissions are correct after changing ownership, you can set the permissions again:

sudo chmod -R 755 /var/www/shareyourthoughts

### Retry the `rsync` Command

After changing the ownership and confirming the permissions, you can retry your `rsync` command to deploy your application:

rsync -avz ./ $EC2_USER@$EC2_HOST:/var/www/shareyourthoughts

### Summary

– Change the ownership of the repository to the user you are connecting with using `chown`.
– Verify the ownership and permissions after the change.
– Retry the `rsync` command.

Following these steps should resolve the permission issue you're facing. If you have any more questions or need further assistance, feel free to ask!

### Steps to Resolve the Issue

#### 1. **Change Ownership**

If you want the `ubuntu` user (or whichever user you are using for deployment) to have access to modify the files, you can change the ownership of the entire `/var/www/shareyourthoughts` directory to the `ubuntu` user:

sudo chown -R ubuntu:ubuntu /var/www/shareyourthoughts

Replace `ubuntu:ubuntu` with the appropriate username and group if you're using a different user.

#### 2. **Modify Permissions**

If you prefer to keep the ownership as `www-data` (which is often the case for web server directories), you can add the `ubuntu` user to the `www-data` group, which would give the `ubuntu` user permission to read and execute files in that directory. Here’s how to do it:

1. **Add the user to the `www-data` group**:

sudo usermod -aG www-data ubuntu

2. **Change the permissions of the directory**:

This step is usually optional, but you can ensure the group has write access:

sudo chmod -R 775 /var/www/shareyourthoughts

This command gives read, write, and execute permissions to the owner and group, and read and execute permissions to others.

#### 3. **Log Out and Log Back In**

After adding the user to the `www-data` group, you need to log out and log back in for the group changes to take effect.

#### 4. **Test the `rsync` Command Again**

Once you have adjusted the ownership and permissions, retry the `rsync` command:

rsync -avz ./ $EC2_USER@$EC2_HOST:/var/www/shareyourthoughts

### Summary

– **Change Ownership**: Make `ubuntu` the owner of the directory, or
– **Modify Group Membership**: Add `ubuntu` to the `www-data` group and adjust permissions accordingly.

These steps should resolve the permission issue you're encountering. If you have further questions or run into any other issues, feel free to ask!

### 1. **Create an IAM User**

1. Go to the **IAM console** in the AWS Management Console.
2. Click on **Users** and then **Add user**.
3. Enter a username and select **Programmatic access** to generate an access key and secret key.
4. Click **Next: Permissions** and attach existing policies or create a new one with the necessary permissions (e.g., AmazonEC2FullAccess).
5. Click **Next: Tags**, then **Next: Review**, and finally click **Create user**.
6. **Note down** the Access Key ID and Secret Access Key.

### 2. **Set Up AWS CLI**

1. Install the AWS Command Line Interface (CLI) if you haven't already.
2. Run the following command to configure the AWS CLI with your IAM user's credentials:

aws configure

You'll be prompted to enter:
– AWS Access Key ID
– AWS Secret Access Key
– Default region name (e.g., `us-east-1`)
– Default output format (e.g., `json`)

### 3. **Modify Your SSH Access Method**

To access your EC2 instance using IAM user credentials, you can use AWS Systems Manager (SSM) Session Manager. This requires that:

1. **SSM Agent** is installed and running on your EC2 instance.
2. Your IAM user has permissions to use SSM, such as the `AmazonSSMFullAccess` policy.
3. Your EC2 instance has an IAM role attached that allows SSM access (e.g., `AmazonEC2RoleforSSM`).

### 4. **Access Your EC2 Instance via SSM**

1. In the AWS Management Console, go to the **Systems Manager** service.
2. Click on **Session Manager** under **Instances & Nodes**.
3. Click on **Start session**.
4. Select the EC2 instance you want to connect to and click **Start session**. This will open a terminal session directly in your browser.

### 5. **Using SSH with IAM Roles (Optional)**

If you still want to use SSH but with IAM roles, you'll need to set up EC2 Instance Connect or use a service like AWS Transfer Family, but this is more complex and requires additional setup.

### Summary

1. Create an IAM user with programmatic access and necessary permissions.
2. Set up the AWS CLI with IAM credentials.
3. Use AWS Systems Manager Session Manager to connect to your EC2 instance.

By following these steps, you can access your EC2 instance using IAM credentials instead of a PEM file. If you have any questions or need further assistance, feel free to ask!

### Example `deploy.sh` Script

#!/bin/bash

# Variables
HOST="your.sftp.server"     # Replace with your SFTP server address
USER="your_username"        # Replace with your SFTP username
PASSWORD="your_password"    # Replace with your SFTP password
REMOTE_DIR="/path/on/server" # Replace with the remote directory path

# Local directory to sync
LOCAL_DIR="./" # Change this to the directory you want to deploy

# Use lftp for SFTP connection
lftp -u "$USER","$PASSWORD" sftp://"$HOST" <<EOF
set ssl:verify-certificate no
mirror --delete --verbose "$LOCAL_DIR" "$REMOTE_DIR"
bye
EOF

### Instructions to Use

1. **Install `lftp`**:
– Ensure that `lftp` is installed on your local machine or the server where the script will run. You can usually install it using your package manager:
– For Ubuntu/Debian:

sudo apt-get install lftp

– For CentOS/RHEL:

sudo yum install lftp

2. **Make the Script Executable**:
– After creating the `deploy.sh` file, make it executable:

chmod +x deploy.sh

3. **Configure Your Variables**:
– Replace `your.sftp.server`, `your_username`, `your_password`, and `/path/on/server` with your SFTP server details.

4. **Add to GitHub Actions Workflow**:
– In your GitHub repository, create a `.github/workflows/deploy.yml` file to run this script on pushes to the master branch.

### Example GitHub Actions Workflow

name: Deploy to SFTP

on:
  push:
    branches:
      - master

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v2

      - name: Set up SSH
        run: |
          echo "${{ secrets.SFTP_PASSWORD }}" > sftp_password.txt
          chmod 600 sftp_password.txt

      - name: Run Deployment Script
        run: |
          chmod +x deploy.sh
          ./deploy.sh
        env:
          SFTP_PASSWORD: ${{ secrets.SFTP_PASSWORD }}

### Notes

– **Security**: Instead of hardcoding your SFTP password in the `deploy.sh`, you can use GitHub Secrets to store sensitive information securely. In the example above, the SFTP password is retrieved from GitHub Secrets.
– **Mirror Option**: The `mirror` command in `lftp` synchronizes the local directory with the remote directory, deleting files in the remote directory that are not present in the local directory.

This setup will automatically deploy your code to the specified SFTP server whenever you push to the master branch. If you have any questions or need further modifications, let me know!