Github Actions: Build NextJS Project in Different Directory - next.js

I'm wondering how I would go about building my project in a sibling directory to the existing repo. The reason for this is that I will occasionally get errors when builds fail and leave something messed up in the build directory. It seems like it would be far more ideal to build in a separate directory, then if the build succeeds, move all files to the actual running directory and restart PM2. I know I can use working-directory in the .yml, but I'm not sure how exactly to write this to ensure that there won't be any downtime. If this isn't a good solution and anyone has any other ideas, I am open to them. Here's my current deploy file:
name: Staging Deploy
on:
push:
branches: [ "main" ]
jobs:
build:
runs-on: Staging
environment: Staging
strategy:
matrix:
node-version: [16.x]
# See supported Node.js release schedule at https://nodejs.org/en/about/releases/
steps:
- uses: actions/checkout#v3
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node#v3
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- run: npm install
- name: Create env file
run: |
touch .env
...create env file with repo secrets
- run: npm run build --if-present
- name: Restart PM2
id: restart_pm2
run: pm2 reload reponame
continue-on-error: true
- name: Start PM2
if: steps.restart_pm2.outcome != 'success'
run: pm2 start pm2.config.js```

Modify the pm2 reload step to reload the app from the running directory. You can do this by specifying the path to the running directory as the working directory for the reload step. For example:
name: Restart PM2
id: restart_pm2
run: pm2 reload reponame
working-directory: .
continue-on-error: true
By following these steps, you should be able to build your project in a separate directory and move the built files to the running directory without any downtime. It's a good idea to test this process on a staging environment before deploying to production to ensure that everything is working as expected.

Related

AWS Amplify - Automating Testing For A Dev Environment with Hosting

Problem: A variety of tutorials from AWS for integrating automated testing with CI/CD look to integrate the testing stage after, or within the build process by using a localhost:3000 server.
However, as AWS Amplify developers know, the local environment can sometimes offer a different user experience to deploying to a development environment, and using that environment with AWS Amplify's hosting service.
Therefore, how do I add testing not only at the build stage with localhost:3000, but also for the development environment's hosted url?
I'm looking to build all my resources (backend and front-end), with a git push to the code commit repository.
Idea of Stages:
Source
Build
Test
Deploy Cloud Formation Stacks
Test
Roll back if failure
Current amplify.yml:
Note: this currently does not work so please do not copy it for your build. Please refer to the hyperlink above.
version: 0.2
frontend:
phases:
preBuild:
commands:
- npm ci
build:
commands:
- npm run build
artifacts:
baseDirectory: .next
files:
- '**/*'
cache:
paths:
- node_modules/**/*
test:
phases:
preTest:
commands:
- npm ci
- npm install wait-on
- npm install pm2
- npm install mocha mochawesome mochawesome-merge mochawesome-report-generator
- npx pm2 start npm -- dev
- 'npx wait-on --timeout 300 http://localhost:3000'
test:
commands:
- 'npx cypress run --reporter mochawesome --reporter-options "reportDir=cypress/report/mochawesome-report,overwrite=false,html=false,json=true,timestamp=mmddyyyy_HHMMss"'
postTest:
commands:
- npx mochawesome-merge cypress/report/mochawesome-report/mochawesome*.json > cypress/report/mochawesome.json
- npx pm2 kill
artifacts:
baseDirectory: cypress
configFilePath: '**/mochawesome.json'
files:
- '**/*.png'
- '**/*.mp4'

Azure App Service deployment Github Actions: Error: Deployment Failed with Error: Error: No package found with specified pattern

I have a dotnet core app I am trying to deploy to Azure with GitHub actions CI/CD. However, the app is not on root repository but rather inside of another folder MYAPP. So I had to update working-directory of build and publish jobs but now I keep getting this error:
Run azure/webapps-deploy#v2
Error: Deployment Failed with Error: Error: No package found with specified pattern: ./published
My project structure is as such
├── .github/workflows
├── MYAPP
├───── MYAPP.sln
├───── MYAPPTESTS
├───── MYAPP
├─────────── MYAPP.csproj
├── docs
├── OtherFolder
└── README.md
My YML file is as below
name: Build and deploy ASP.Net Core app to Azure Web App - myappdeploy
on:
push:
branches:
- main
workflow_dispatch:
env:
AZURE_WEBAPP_PACKAGE_PATH: './published'
jobs:
build:
runs-on: windows-latest
steps:
- uses: actions/checkout#v2
- name: Set up .NET Core
uses: actions/setup-dotnet#v1
with:
dotnet-version: '6.0.x'
include-prerelease: true
- name: dotnet build and publish
working-directory: ./MYAPP
run: |
dotnet restore
dotnet build --configuration Release
dotnet publish -c Release -o ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
- name: 'Run Azure webapp deploy action using publish profile credentials'
uses: azure/webapps-deploy#v2
with:
app-name: 'myappdeploy'
publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_7894EB5E4C174F72A5EDE9C64B658907 }}
package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
What am I missing?
Thanks
Instead of working directory I have tried adding .deployment to root repository.
[config]
project = ./MYAPP
However this file was not read and the pipeline would say that it can't find .sln file. I have also tried adding Project app setting on Azure App Service configuration but still the pipeline would not work.
I have tried removing the package parameter of the azure/webapps-deploy#v2 and the pipeline runs successfully however I instead get the error when accessing the website:
You do not have permission to view this directory or page
Also, none of the routes of my app can be found (404)
When running the solution locally there are no issues.. and when deploying manually to an app service through Visual Studio GUI there are also no issues. However, this is not a proper solution as GitHub CI/CD is needed.
For anyone who might come into the same issue, I had to specify where the .sln is during dotnet build and where the .csproj is for dotnet publish. Also remove working-directory
- name: dotnet build and publish
# working-directory: ./MYAPP
run: |
dotnet restore
dotnet build MYAPP/MYAPP.sln --configuration Release
dotnet publish MYAPP/MYAPP/MYAPP.csproj -c Release -o ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

How can I use a .zip build file and create a release asset with a GitHub action?

I am having issues wrapping my head around GitHub actions. I currently use WPack.io to build and create a distributable .zip archive of my WordPress theme. I want to be able to take this .zip and have it at the top level as a release asset upon creating a release in GitHub. Currently if I locally run the build and archive commands, it will create a .zip of my theme in the /builds directory. I understand I can use these commands in GitHub actions upon a release, however I am stuck with the part where I would be able to move /builds/theme.zip up to the top level. Here is what I have so far.
# This is a basic workflow to help you get started with Actions
name: CI
# Controls when the workflow will run
on:
# Triggers the workflow on push or pull request events but only for the "main" branch
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout#v3
- name: Install dependencies
run: |
npm install
- name: Run WPack Build
run: |
npm run build
- name: Run WPack Archive
run: |
npm run archive
- name: Release
uses: softprops/action-gh-release#v1
if: startsWith(github.ref, 'refs/tags/')
with:
files: ${{ github.event.repository.name }}.zip
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Firebase hosting using Old webpack bundle when deployed via GitHub Actions

I'm trying to create a GitHub-Action that first uses Webpack to create a bundle.js file and then deploy my index.html and newly created bundle.js to Firebase hosting.
First I just pushed my bundle.js in my GitHub repository, but I since removed it via "git rm --cache public/bundle.js" (not sure if this is the exact command) and added bundle.js to my .gitignore.
The action does work (no error or crash) but it seems that Firebase does not use the newly packaged bundle.js, but instead uses an old version that might be cached somewhere?
firebase-hosting-pull-request.yml:
name: Deploy to Firebase Hosting on PR
'on': pull_request
jobs:
build_and_preview:
if: '${{ github.event.pull_request.head.repo.full_name == github.repository }}'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- run: npm ci && npm run build
- uses: FirebaseExtended/action-hosting-deploy#v0
with:
repoToken: '${{ secrets.GITHUB_TOKEN }}'
firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT_PROJECTLIBRARIAN }}'
projectId: projectlibrarian
npm run build in this case executes webpack --mode=production
My index.js (which is webpack'd into bundle.js) only contains a single log statement which I changed to test the GitHub-Action.
Link to the Repo if it helps someone
I'm wondering if I need to clear some kind of GitHub actions cache? or maybe the Firebase deploy action script I'm using isn't doing what I think it should be doing? What confusing me the most is where does Firebase get the old version of bundle.js!
Ok I have found two changes that fixed the problem.
Add channelId: live in my workflow yaml
Reload the site with the "Empty chache and Hard reload" developer option.

How to add working directory to deployment in GitHub actions

I recently moved into GitHub actions, so what I'm trying to do is host my react project in firebase when a push is done. And I used GitHub actions to this CI/CD process. And this is the main.yml that I have right now.
name: Build and Deploy
on:
push:
branches:
- master
jobs:
build:
name: Build
runs-on: ubuntu-latest
steps:
- name: Checkout Repo
uses: actions/checkout#master
- name: Install Dependencies
working-directory: ./my-app
run: npm install
- name: Build
working-directory: ./my-app
run: npm run build
deploy:
name: Deploy
needs: build
runs-on: ubuntu-latest
steps:
- name: Checkout Repo
uses: actions/checkout#master
- name: Deploy to Firebase
uses: w9jds/firebase-action#master
with:
args: deploy --only hosting
env:
FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
And I somehow manage to set the working directory when npm installation and project building. But in deployment I'm keep getting this error,
So what I have understood is, this error occurs due to the working directory problem. So my current project structure looks like this.
. (root of my GitHub repository)
└── my-app
├── firebase.json <-- Git Hub action must point to this sub-dir
└── my-app-mobile
├── packages.json
So how should I do this within my firebase deployment process? If I'm wrong with the problem, What would be the problem and the answer? It seems I can't use working-directory: ./my-app with uses:
I looked at the documentation for the firebase CLI and didn't see any way to set the path to your firebase.json via a CLI parameter. There is, however, an environment variable that stores the root directory. It's in the context of predeploy and postdeploy hooks though, so I'm not sure if the CLI will respect it.
$PROJECT_DIR — The root directory containing firebase.json
https://firebase.google.com/docs/cli#environment_variables
The w9jds/firebase-action you are using is just a wrapper around the CLI. I'm not sure if this will work but you could try setting the project directory as follows. The reason the variable is set in a separate step is because you cannot evaluate expressions in env sections. See this answer for more detail. Container actions like w9jds/firebase-action will have access to the variable without passing it directly via env.
- name: Set project dir environment var
run: echo ::set-env name=PROJECT_DIR::"$GITHUB_WORKSPACE/my-app"
- name: Deploy to Firebase
uses: w9jds/firebase-action#master
with:
args: deploy --only hosting
env:
FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
If that doesn't work, an alternative is to fork w9jds/firebase-action and add a PROJECT_PATH parameter to the entrypoint.sh script here:
https://github.com/w9jds/firebase-action/blob/master/entrypoint.sh
Update: I raised a PR to add a PROJECT_PATH parameter to w9jds/firebase-action. You can now use the action as follows.
- name: Deploy to Firebase
uses: w9jds/firebase-action#master
with:
args: deploy --only hosting
env:
FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
PROJECT_PATH: ./my-app

Resources