EC2 Build Optimization

### 1. **Instance Size and Resources**
– Ensure that your EC2 instance has enough resources (CPU, memory) to handle the build process. Sometimes, smaller instance types can cause delays in build times.
– You can monitor your instance's resource usage via **CloudWatch** or use commands like `top` or `htop` to check CPU and memory usage.

### 2. **Disk I/O Performance**
– The EC2 instance might be using an EBS volume with slow read/write speeds, which can slow down build processes. Consider using **Provisioned IOPS SSD** for faster disk performance if you're using standard or magnetic storage.

### 3. **Network Latency for Dependencies**
– If your build process requires downloading a lot of dependencies, network speed can become a bottleneck. You can speed up the process by:
– Using a **local npm cache** or running `npm install` before the build to make sure dependencies are already present.
– If using Docker, ensure you are caching layers to avoid unnecessary re-fetching.

### 4. **Node.js and npm Optimizations**
– **Enable npm cache**: Run `npm install –prefer-offline` to minimize network requests.
– **Use `npm ci`** instead of `npm install`: This command is faster and ensures that the dependencies are installed exactly as per `package-lock.json`.

### 5. **Parallelize Tasks**
– If you are using tools like **Webpack**, check if you can enable parallel processing or optimize configurations (e.g., using `thread-loader` or `parallel-webpack`).

### 6. **Optimizing the Build Process**
– **Disable source maps**: In production builds, source maps can slow down the process. Make sure that source maps are disabled in your `webpack.config.js`.
– **Split your build**: Use **code splitting** to only bundle the necessary parts of your application.

### 7. **Running Build Locally First**
– Try running `npm run build` on your local machine to see if the issue is specific to the EC2 instance. If it's significantly slower on EC2, the issue may be with the EC2 environment itself.

### 8. **Check for any npm Warnings/Errors**
– Run the build with `npm run build –verbose` to see if there are any warnings or errors that could indicate issues with dependencies or other configurations.

Let me know if you'd like further details on any of these!

Error: ENOSPC: System limit for number of file watchers reached, watch '/var/www/shareyourthoughts/vendor/fakerphp/faker/src/Faker/Provider/en_UG/PhoneNumber.php'
at FSWatcher. (node:internal/fs/watchers:247:19)
at Object.watch (node:fs:2468:36)
at createFsWatchInstance (file:///var/www/shareyourthoughts/node_modules/vite/dist/node/chunks/dep-CDnG8rE7.js:42736:17)
at setFsWatchListener (file:///var/www/shareyourthoughts/node_modules/vite/dist/node/chunks/dep-CDnG8rE7.js:42783:15)
at NodeFsHandler._watchWithNodeFs (file:///var/www/shareyourthoughts/node_modules/vite/dist/node/chunks/dep-CDnG8rE7.js:42938:14)
at NodeFsHandler._handleFile (file:///var/www/shareyourthoughts/node_modules/vite/dist/node/chunks/dep-CDnG8rE7.js:43002:23)
at NodeFsHandler._addToNodeFs (file:///var/www/shareyourthoughts/node_modules/vite/dist/node/chunks/dep-CDnG8rE7.js:43244:21)
Emitted 'error' event on FSWatcher instance at:
at FSWatcher._handleError (file:///var/www/shareyourthoughts/node_modules/vite/dist/node/chunks/dep-CDnG8rE7.js:44437:10)
at NodeFsHandler._addToNodeFs (file:///var/www/shareyourthoughts/node_modules/vite/dist/node/chunks/dep-CDnG8rE7.js:43252:18) {
errno: -28,
syscall: 'watch',
code: 'ENOSPC',
path: '/var/www/shareyourthoughts/vendor/fakerphp/faker/src/Faker/Provider/en_UG/PhoneNumber.php',
filename: '/var/www/shareyourthoughts/vendor/fakerphp/faker/src/Faker/Provider/en_UG/PhoneNumber.php'
}

Node.js v22.11.0

### Solutions to Resolve the ENOSPC Error:

#### 1. **Increase the File Watcher Limit**:
The default limit on the number of file watchers in Linux systems is often too low for large projects. You can increase this limit by running the following command:

sudo sysctl fs.inotify.max_user_watches=524288
   sudo sysctl fs.inotify.max_user_instances=512

To make the change persistent, add it to the sysctl configuration:

echo "fs.inotify.max_user_watches=524288" | sudo tee -a /etc/sysctl.conf
   echo "fs.inotify.max_user_instances=512" | sudo tee -a /etc/sysctl.conf

Then, apply the changes:

sudo sysctl -p

#### 2. **Clear the Watcher Cache**:
In some cases, you may need to clear the file system watcher cache. You can restart your machine or clear the cache manually with the following command:

sudo sysctl -w fs.inotify.max_user_watches=524288

#### 3. **Reduce the Number of Watched Files**:
If possible, you can configure your build tools (like Vite) to watch fewer files. You can exclude large directories that aren't relevant to the build process, such as the `node_modules` or `vendor` directory, which might reduce the number of file watchers.

In **Vite**, you can add a `watch` option in `vite.config.js` to exclude certain directories:

export default {
     server: {
       watch: {
         ignored: ['**/node_modules/**', '**/vendor/**']
       }
     }
   };

#### 4. **Check for Other Processes Using File Watchers**:
If you have other processes that use a lot of file watchers, like an IDE or other Node.js processes, try stopping those to free up watchers.

#### 5. **Use `polling` as a Watcher Strategy (as a fallback)**:
If increasing the file watcher limit doesn't resolve the issue, you can switch to polling for file changes, which uses more CPU but avoids the file watcher limit.

In **Vite**, you can add this configuration:

export default {
     server: {
       watch: {
         usePolling: true
       }
     }
   }

After applying these changes, try running `npm run build` again. This should help alleviate the file watcher error and allow the build to proceed normally.

### 1. **Check Pipeline Logs**:
– **GitHub Actions**: Go to the "Actions" tab of your repository and select the relevant pipeline run. You can view the logs to see if the deployment step was successful or if there were any errors during the deployment process.
– **GitLab CI**: Go to your GitLab repository, navigate to **CI / CD > Pipelines**, and select the pipeline run. Check the logs for the deploy job.
– **Jenkins**: Go to the Jenkins job that handles deployment and look at the build console output for logs related to the deployment.

In the logs, look for:
– SSH or SCP commands (if you're pushing the code via SSH).
– Logs from a deployment script or tool (e.g., `rsync`, `scp`, `git pull`).

### 2. **Check EC2 Instance Logs**:
– **SSH into your EC2 instance**: You can SSH into your EC2 instance using the following command:

ssh -i your-key.pem ubuntu@ec2-XX-XX-XX-XX.compute.amazonaws.com

– **Check the application directory**: Navigate to the directory where your application is deployed and check if the latest code is present.

cd /var/www/shareyourthoughts
     git status   # Check if the latest commit is reflected

You can also check if specific files were updated using:

ls -l   # Check file modification dates

### 3. **Verify Deployment Script**:
If you're using a deployment script (e.g., `deploy.sh`), make sure the script is set up correctly. You should check for:
– **Git Pull**: If the script is pulling the latest code from a repository (e.g., `git pull origin main`).
– **File Transfer**: If using `scp`, `rsync`, or similar tools, ensure that the files are being transferred correctly.
– **Environment Variables**: Ensure that any necessary environment variables (like AWS keys, access tokens, etc.) are available to the pipeline.

### 4. **Check for Post-Deploy Activity**:
– If your pipeline includes build steps, you can verify that the build was successful (e.g., running tests or compiling assets).
– Check that services (e.g., Apache, Nginx, or your PHP/Node.js server) are restarted or reloaded post-deployment. This can be checked with:

sudo systemctl status apache2    # for Apache
     sudo systemctl status nginx      # for Nginx
     sudo systemctl status php8.3-fpm # for PHP

### 5. **Automated Notifications**:
Some pipelines can be configured to send notifications (via email, Slack, etc.) when the deployment succeeds or fails. Make sure these notifications are set up so you can quickly check if the deployment succeeded.

### 6. **Use AWS CodeDeploy (if applicable)**:
If you're using **AWS CodeDeploy** to deploy the code, you can check the status of the deployment:
– Go to the **AWS Management Console** > **CodeDeploy**.
– Select your deployment group and check the deployment status.
– Review the logs for any errors that occurred during the deployment process.

### 7. **Check Web Server Logs (Optional)**:
If your application is a web app, you can check the web server logs (e.g., Apache, Nginx) to see if the deployment is live and if there are any issues.
– **Apache Logs**: `/var/log/apache2/error.log`
– **Nginx Logs**: `/var/log/nginx/error.log`
– **PHP Logs**: `/var/log/php8.3-fpm.log`

### Example: GitHub Actions Deployment to EC2

Here’s an example of a GitHub Actions workflow that pushes code to an EC2 instance:

name: Deploy to EC2

on:
  push:
    branches:
      - main

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

    - name: Set up SSH
      uses: webfactory/ssh-agent@v0.5.3
      with:
        ssh-private-key: ${{ secrets.EC2_SSH_PRIVATE_KEY }}

    - name: Copy files to EC2
      run: |
        scp -r ./ ubuntu@${{ secrets.EC2_IP }}:/var/www/shareyourthoughts

    - name: SSH into EC2 and restart server
      run: |
        ssh ubuntu@${{ secrets.EC2_IP }} "cd /var/www/shareyourthoughts && git pull && sudo systemctl restart php8.3-fpm"

Make sure the following are set in GitHub Secrets:
– `EC2_SSH_PRIVATE_KEY`: The private key for SSH access to your EC2 instance.
– `EC2_IP`: The IP address of your EC2 instance.

In this example, the pipeline runs every time code is pushed to the `main` branch, SSHs into the EC2 instance, pulls the latest changes, and restarts the PHP service.

### Conclusion:
By checking the logs from your pipeline and EC2, verifying the deployment scripts, and confirming that the EC2 instance is up-to-date, you can determine whether the code was successfully pushed and deployed. If there are issues, the logs should provide helpful error messages for debugging.