I've been uploading and deploying my react app to the gh-pages branch using the command git run deploy and for some reason, when I use it again, I get an error saying that run is not a command when it used to recognise it, and now I can no longer update the live website. Anyone know what to do?
I haven't removed anything or added or installed anything. It was shortly after I pushed the latest to github. So I have no idea.
use npm run deploy instead of git run deploy
Related
I created a Gitlab Ci-CD to remove react and react-dom from devDependencies in package.json when i push my code to master.
but as you can see it says that pipline is passed and job is succeeded but when i look at my master branch react and react-dom are not removed from devDependencies and they are still there.
what should i do with that?
A GitLab CI job doesn't change any of your repository files. It pulls a copy of the repository so that it can run a script, test, etc. against it. If the specified job runs successfully without throwing any errors (exit code), then the job succeeds/passes. You can find a more detailed explanation in the GitLab CI/CD documentation.
If you want to make changes to the repository, you need to have the script run to make the changes, then commit the changes, and push those changes to the repository using the standard git commands.
Just remember that you'll have to authenticate using HTTPS or using SSH.
You'll also likely find this StackOverflow answer on pushing to a GitLab repository through a CI job helpful as well.
I have a react(specifically NextJS) web app running on a Linux Azure Web App Server. I have it deployed and working correctly via GitHub Actions. However, I'm having issues finding the most efficient way to deploy the node_modules.
Here's what I've tried.
I've ran the install and build within GitHub Actions and deployed the package as a zip artifact. However, the file was huge due to the node_modules and takes 10+ minutes to deploy.
I've created a postDeploy script to run after deployment that runs an npm install. Not sure if this is the best way to go about it so I reverted this.
For the startup command, I have azure running npm run start:prod. I thought about changing this to npm install && npm run start:prod . I'm not sure if this is a good idea either
What I've settled on so far is I just manually get on the server and run npm install after a deployment. This won't work for CI/CD though.
I've read that azure kudu supposedly detects package.json within the wwwroot folder and will automagically install dependencies but I haven't seen this work, nor could I find any documentation on it. So far, my best idea seems to be to change my startup command to run an install before starting the app but I'm not sure.
Any advice?
There shouldn't be a big difference between GitHub Action and Azure DevOps in that terms. But what should you do actually on your pipeline is run npm run build command and publish only produced output.
Please take a look here how it looks on Azure DevOps.
I'm new to yarn, nodejs and react apps. I've tried running the Sizzy app and it works on my local XAMPP server if I first run yarn start in the cmd terminal and then access via http://localhost:3033, but after a while I have to rerun the same command. I've tried yarn build and then navigating to the build directory but that just loaded a page with a header, it didn't have the same functionality. And the contents of the build directory looks very similar to the contents of the public directory anyway.
I've had a look at this SO post and this one but still unsure why I need to run yarn start everytime.
UPDATE:
I'm still not sure how node, react, and electron fit together and why each is required, much research and learning still to do! Rather than a 'react app' I believe I'm looking at an 'Electron app'. I think if I run the command npm run package-win then I think I should get an exe file and some dlls. But how to instead setup for running on an Apache web server without having to start using the command line, or would you just have to build it with different architecture?
Starting to get a vague understanding from reading this.
If you used the npx create-react-app <app-name> then you just have to change the "start" script in the package.json file as "serve -s build". Run yarn add serve to add For deployment, Heroku is a good choice. Create a Heroku app and connect your git repo to the newly created app. Then go to the deploy tab and deploy your branch.
I am developing a React JS app on a remote server which uses Apache.
In the past I have built a React JS app manually with webpack/babel etc. and then used "npm run dev" to run the app.
With this method I could see any errors on the fly in the terminal and test in the browser automatically through the web browser.
I am now creating a new site with create-react-app which takes care of a lot of the tedious setup for you. One thing I cannot figure out is how to use something similar to "npm run dev". My two options seem to be:
npm run build - This takes a while and I have to rerun it every time I change my code. It does put the updated code in the /build directory which I can link to from my Apache server and see in my browser.
npm start - I can see any errors right away in the terminal, but I cannot see it in my browser because it runs on localhost and does not get compiled to the build directory.
What can I do so that I get the best of both worlds? Having quick rebuilds / error reporting and being able to see remotely through my Apache server?
Or would it be better just to go back to my old manual way of doing things?
I have been trying out Codeship and Heroku for continuous deployment of an AngularJS application I writing at the moment. The app was created using Yeoman and uses bower and grunt. Initially I thought this seemed like a really good setup as Codeship was free to use and I was quickly able to configure this to build my AngularJS project and it offered the ability to add a deployment step after the build. There were even many PaaS providers to choose from (Heroku, S3, Google App Engine etc). However I seem to have become a bit stuck with getting the app to run on Heroku.
The problem started from the fact that all the documentation suggested that I remove the /dist path from my .gitignore so that this directory is published to Heroku post build. This was mainly from documentation that talked about publishing to Heroku from a local machine, but I figure this is all Codeship is doing under the hood anyway. I didn't want to do this as I don't believe I should be checking build output into source control. The /dist folder was added to .gitignore for a good reason. Furthermore, this kind of defeats the point of having a CI server somewhat, as I might as well just push the latest build from my machine.
After some more digging around I found out that I could add a postinstall step to my packages.json file such as bower install && grunt build which would re-run the build on Heroku and hence repopulate all the bower dependencies (something else they wanted me to check in to source control!) and the dist directory.
After giving this a try it became apparent that I would need to add bower and grunt as dependencies in packages.json, which meant moving them from devDependencies which is where they should belong!
So I now seem to be stuck. All I want to do is publish my build artefacts (/dist) the dependencies (/bower_components) and the server.js file that will run the site. Does anyone know how to achieve this with Heroku and Codeship? Alternatively has anyone had any success with this using different tools. I am looking for something that is free and I am willing to accept that it will not be production stable (won't scale to multiple servers etc), but this is fine for now as all I want to do is continuously deploy the app for internal testing and to be able to share the output with non-technical members of my team so we can discuss features we'd like to prioritise etc.
Any advice would be greatly appreciated.
Thanks
Ahoy, Marko from the Codeship crew here. Did you already send us an in app message about this? I'm sure we can get your application building on Codeship and deploying to Heroku successfully.
As a very short answer, the easiest way to get this running would be to add both bower and grunt to your dependencies in the package.json. Another possibility would be to look for a custom buildpack with both tools already installed.
And finally you could also run the tools on Codeship, add the newly installed files to the repository, commit the changes and push this new commit to Heroku. If you want to use this, you'd very probably need to force push the changes though.
Feel free to reach out to me via the in app messenger (lower right corner of the site) and I'd be happy to help you get this working!
I found two ways to get this to work.
Heroku Node Custom Buildpack
Use the mbuchetics Heroku build pack. This works by basically re-building the app once it has been pushed to Heroku.
There were a few tricks I had to employ still to make this work. In Gruntfile.jstwo new tasks needed to be configured called heroku:production and heroku:development. This is what the buildpack executes to build the app. I initially just aliased the main build task, but found that the either the buildpack or Heroku had a problem with running jshint so in the end I copied the build task and took out the parts that I didn't need.
Also in packages.json I had to add this:
"scripts": {
"postinstall": "bower cache clean && bower install"
}
This made sure the bower_components were available in Heroku.
Pros
This allowed me to keep the .gitignore file in tact so that the 'binaries' in the dist directory and the dependencies in the bower_components directory were not committed into source control.
Cons
This is basically re-building the app once it is on Heroku and I generally prefer to use the same 'binaries' throughout the entire build and deployment pipeline. That way I know that the same code that was built, is the same code that was tested and is the same code that was deployed.
It also slows down the deployment as you have to wait for the app to build twice.
CodeShip Custom Script Deployment
Not being satisfied with the fact I was building my app twice, I tried using a Custom Script pipeline in CodeShip instead of the pre-existing Heroku one. The script basically modified the .gitignore file to allow the dist folder to be committed and then pushed to the Heroku remote (which leaves the code on the origin remote unaffected by the change).
I ended up with the following bash script:
#!/bin/bash
gitRemoteName="heroku_$APP_NAME"
gitRemoteUrl="git#heroku.com:$APP_NAME.git"
# Configure git remote
git config --global user.email "you-email#example.com"
git config --global user.name "Build"
git remote add $gitRemoteName $gitRemoteUrl
# Allow dist to be pushed to heroku remote repo
echo '!dist' >> .gitignore
# Also make sure any other exclusions dont apply to that directory
echo '!dist/*' >> .gitignore
# Commit build output
git add -A .
herokuCommitMessage="Build $CI_BUILD_NUMBER for branch $CI_BRANCH. Commited by $CI_COMMITTER_NAME. Commit hash $CI_COMMIT_ID"
echo $herokuCommitMessage
git commit -m "$herokuCommitMessage"
# Must merge the last build in Heroku remote, but always chose new files in merge
git fetch $gitRemoteName
git merge "$gitRemoteName/master" -X ours -m "Merge last build and overwrite with new build"
# Branch is in detached mode so must reference the commit hash to push
git push $gitRemoteName $(git rev-parse HEAD):refs/heads/master
Pros
This only require a single build of the app and deploys the same binaries that were tested during the test phase.
Cons
I've used this script quite a few times now and it seems relatively stable. However one issue I know of is that when a new pipeline is created there will be no code on the master branch so this script fails when it tries to do the merge from the heroku remote. At the moment I get around this by doing an initial push of the master branch to Heroku before kicking off a build, but I imagine there is probably a better Git command I could run along the lines of; 'only merge this branch if it already exists'.