I want to manage my cypress tests in a separate repository (Not in the same front-end application project). moving the tests to a new project is not an issue but I want to know how can I handle the CI/CD process after moving the project. as I would like to have the following features
I'm using the 'GitHub Actions as the CI/CD.
|--front-end project
|--front-end-branch-1-0
|--front-end-branch-1-1
|--cypress tests project
|--cypress-tests-branch-1-0
|--cypress-tests-branch-1-1
At the moment it is possible to execute tests in any cypress branch against any environment (eg. dev, qa or stagging) but I would like to know the possibility to do the following if we maintain a separate GitHub repository
Tests should be able to execute on a PR on the front-end project (tests should be able to execute on the updated source code) in this case how can we trigger the tests in a specific branch of the cypress project (Eg. 'cypress-branch-1-0')?
How can we execute cypress tests on a specific branch on a front-end project (Eg. front-end-branch-1-1)? Is there a way to trigger tests from a specific branch in cypress test project (Eg. 'cypress-branch-1-1')
Appreciate any suggestions
We currently have a similar set up, even though it is not ideal to have cypress tests in a separate repo.
We currently have a spin up PR environment for our front end PRs. The front end repo PRs use the main branch of our cypress repo for e2e tests.
If there are tests needed to be updated, then we have a developer open a PR with the changes in the cypress repo and then update the baseUrl to use the spin up PR environment for the front end PR.
It can be a rather confusing for developers to make changes to both repos and can hurt your confidence the nightly runs when cypress tests have not been updated to match the front end repo. Not to mention different rules that will be needed for each PR to be merged into each repo.
we're working through a setup at my work and I want to see if anyone has any advice/best practices for what we're doing here.
We have code in a git repo for our ui library that produces an npm package (in an internal private registry). That package then gets pulled into the git repos for each of the main products. The question is about versioning the package.
Because we're going from a parallel dev process (git) to linear package versions, which then gets pulled back into another parallel dev process (product git repos), there's an opportunity for code from the library to be accidentally released to production:
Change A is made to the library, produces v1.0
Change B is made to the library, produces v1.1
The library version in a product is updated to v1.1 to access Change B
Product change, and v1.1, is released; Change A in v1.0 is accidentally included
Does anyone have any advice, best practices, or alternate workflows we could keep in mind? The main thing is, we want the UI library stored in one repo but able to be pulled into multiple other repos.
Thank you!
I like to have a visual cue of the current GIT branch I am working on and have that set up in my IDE (I currently use VIM but I know VSCode also does this). I like/need it so much that I would really also like to see it in my development build when serving locally.
I currently do this manually with a label that I update by hand each time I create a new branch to work on. However, I often forget to do this and subsequently confuse myself.
I'm wondering whether it would be possible to pull this information from GIT and show it in my UI in the same way VSCode does?
Specifically I am using Vue 3 and Typescript but I guess that is not super relevant to the general problem.
Anyone have a feel of how you would do this?
If you are using Webpack as a bundler, there is a git-commit-info-webpack-plugin which can write some Git info (branch name, last commit date/hash/author) into a json file on each build.
Just import the json file into your app and use it....
Hey all so I have an app that I am working on which I am creating using Next.js.
Almost every single time I make a change the server auto compiles with the new changes which are fine. However most of the time the pages just fail to render properly.
Sometimes it takes minutes to render them properly and I have to constantly restart the server manually multiple times just to get the pages to load properly. Does anyone know what could be causing this?
I don’t currently have a next.config.js file would I need to create one and add some settings to fix these problems?
And also the page routing does not work in production builds. The index.js page loads fine but none of the routes work when I click on a link they all end in a 404. Even if I type the URL in the browser.
I solved the issue months ago I am just adding the solution I used. It seems to be some sort of git bug maybe some of the files are getting cached somewhere on git or on Netllify which is corrupting it I’m not sure. The only way I managed to it working was to create a brand new git repo and then deploy it to a new site from git on Netlify.
Copy the project into a new folder in preparation for setting up a new repo and delete the git file with its history
CD into the folder which has the next app (frontend in my case) and delete the node_modules, .next, next.config.js and package-lock.json file
Make sure that all of the components in the pages folder are lower case and not camelcase
run npm install
Setup the new project for git and then deploy it to a NEW git repo. For whatever reason my existing repo fails to get the routing working despite multiple tests and duplicate projects being identical. The only difference was that the new repos I tested only had a master branch whereas my main repo also had a develop branch. And there were only a few commits whereas my main repo had over 80 commits.
Deploy to Netlify as a new site from git
As my project was in a subfolder called frontend I had to set the base directory to frontend and then run the commands next build && next export
I currently have ReactJS + NodeJS/ExpressJS + Webpack onto EC2, Amazon Web Services (AWS) under one project and would like to get it deployed together at once, in one project.
What are some suggestions on how to go about doing so? Done the research, and I've only seen tutorials on deploying one in specific, whether it be just ReactJS or just NodeJS. Any insights or leads would be greatly appreciated.
Will accept/upvote answer. Thank you in advance
You don't "deploy" ReactJS, it's just a static file or files like any other JS libraries in your applications. You also don't deploy Webpack. Webpack should run on a developer machine (or in CI/CD stack or build system).
As for the NodeJS part just use Elastic Beanstalk.
I do not commit builds to source control. I see that a lot and it can make things easier, but you can also forget to rebuild as you have to do it manually, and it adds a lot of bloat to your repo.
I believe builds should be run as part of the deployment process. Assuming you are using git, you can add script hooks/post-receive in a remote repo there. When you push to that remote, the script will run. This is where I do my webpack build.
You may want to look into https://github.com/git-deploy/git-deploy for context, but I do this manually.
In my projects, on the deployment machine I do git --init --bare /var/git/myproject.git then add the script in /var/git/hooks/post-receive. The hook checks out the code into /var/www/myproject, runs the build, which fills in the /var/www/myproject/build. Then it removes the old /var/www/myproject/public and renames build to public. And done.
I'm coming from more of an operations background and would say that if your goal includes keeping that site up as much as possible then use Packer to generate AMI's and CloudFormation to build an Application Load Balancer (the newer, cheaper brother of ELB) in front of an AutoScalingGroup which keeps the EC2 instances up and running.
I'm currently working on a large scale project doing exactly what you describe. First off, there are so many different ways to do this, so what you really need is some general guidelines to get started, then we can dig a little deeper into details when some initial decisions are made, if you'd like. If you've already got the app deploying and running in two separate steps, but are just looking to combine those, I can definitely help. I'd just need to know how you're currently building/deploying. If you're just getting started on building your pipeline and need to set up the process from scratch, then read on:
First off you'll want to set up some kind of build server that will install your npm dependancies and run your webpack build. Most likely you'll want a separate webpack config that's just for your build server, this'll give you a build optimized for production or qa/staging environments. This config should split out vendor files that you won't update all the time, pull out seperate css files with extract text plugin and uglify the files. If you have an isomorphic React app, or are using es6 features not supported in your version of node, then you'll need a webpack build for your server code as well. This is really different from the hot reloading build you'll want to have on your local machine while you're actually coding the app. I'll be happy to show some examples if you'd like of our webpack config files for both local development and our CI build. You may also need a build.sh or makefile to do something with the compiled .js files that your webpack build creates, but that'll depend on your deployment which I'll cover later. You can run your production build locally as your getting your config just right and fire up the app from those files to test it's all working. Additionally, since you'll likely want to be able to automate all of this, you probably want to run your tests and linting right before you build your app, we run eslint and mocha/jdom to run our enzyme/expect specs as part of our build. Once that's all working nicely, you'll most likely want to set up a build server that can run your builds automatically. My team is using Jenkins for this, which is a little more work to set up, but it's free (aside from the ec2 box we run it on). There are also a ton of subscription based build/continuous integration servers, such as Travis and CodeShip. There's plenty of articles on the pros and cons of these different products and how to set them up. The bottom line is you'll want to have a build server that can pull down your code from source control, install npm deps, lint, test and build your app. If anything fails it should fail your build and if your build succeeds you'll have some sort of archive that you'll later deploy to an ec2 instance. In our shop we use a build.sh file to tarball up our build archive (basically a folder with our node server files as well as our minified client files, css files and any fonts or images needed to run the app) and upload it to an S3 bucket that we deploy from. We like this fairly old school method because the tarball will never change, so we have ultra reliable roll backs.
What you do with your build archive will depend on how you want to do deployments. We have a custom deployment system using puppet, but there are plenty of products that do this such as elastic beanstalk, that would be much easier to set up. You'll want some kind of process supervisor to actually run your node app, so unless you have a dev ops team that wants to build custom pipelines, using AWS built in features will probably be the easiest way to get started. As usual, there are so many ways to do this, but the basic principal is that you need something to download your build archive and run/supervise your node process. You also may want to be able to create and configure ec2 boxes on the fly (Puppet, chef, etc.), or even use containers (Docker) which allow you to move complete stacks around as single units. Using automation to create and configure servers is crucial if you need to scale your app, but it is complicated and may not be necessary for smaller projects. This is definitely an area where you can start simply and add complexity later on, as long as you have good long term goals and make sure to take the necessary step to prepare for future complexity.
All of this can get you pretty far in the weeds, so it's best to find the simplest thing that will serve your needs as you get started and then add complexity as real life situations demand so. I'll be happy to elaborate on any of these details if you provide a little more context about how big and well funded of a project your working on. If it's a little side project to learn the tech, I'd have very different advice then if you're trying to build an app that'll have a lot of traffic and/or complex features.
This could get 100 different answers and they could all end up being good ideas. First, you mention react + nodejs - keep in mind that these solve different tasks. React is going to be frontend and served out via static files. Nodejs is focused more around the server-side and would be the code that serves data. They can easily work together. You might use Express for the webserver (nodejs) to serve the HTML/React pages.
Unfortunately, I saw that you mentioned webpack, so you are going to have to 'build' your application with something - either via webpack, gulp, grunt, etc. This is where source control and build servers are great - but if you're new to it, it might be more complex than you need.
If you have just basic EC2 images as webservers and only 1-2, then the biggest hurdle is just pushing up your code. Something like https://deploybot.com/ could work as it can push your git repo down to multiple hosts via ftp, etc. If you wanted to get a bit fancier, you could look at something like Jenkins or some of the other items.
Docker is a great choice and if you are going to be dealing with multiple developers, server environments, deployments - it's worth the time. Otherwise, keep it simple and just get your code on the EC2 instance ;).