I have a continuously growing website which has automated CI/CD using github actions. The website is build in React and using jest and cypress to do the testing. As for backend i'm using Firebase. Here is the workflow:
Whenever a PR is created, github action will install the dependencies
using yarn
Create a test-build where Firebase emulators is used in order not to populate the prepod Firestore
Create a preprod build with preprod API keys and a preprod Firestore and auth
Test with jest up against the preprod build.
If everything succeed it will publish the website to a temporary url.
All PR's are merged into the developer branch, but here is my question:
It seems very cumbersome and redundant to do the same steps whenever a PR is merged into the dev branch, but as of now, all of above steps are done again, but on the newly merged dev branch. Is that the normal way to do, or is it okay to skip this build, since it has already be done in the pr-merge or the PR?
Your PR branches are tested in isolation, based on a previous dev branch (assuming that's where you forked from). Only if the PR branch was actively rebased against the dev branch, before merging, should you consider not re-running the full build on merges. Otherwise, you could run into a situation where multiple merges are happening, and the diff is clean for the individual PRs, but when put together within the dev branch, it no longer works.
Related
We have a monorepo setup (using lerna) to handle multiple packages. Now when some updates are made to certain packages, the version number are bumped up and published via a jenkins job that also commits back the updated version no. to the branch that was used to run the jenkins build with.
The issue we're currently facing is that when a new version is published from a certain branch say "feature/A", it would update the version of that same package from 1.0.0 to 1.0.1 in this branch. But all the other branches are still at version 1.0.0, and if a user B with branch "feature/B" tries to run a the same publish jenkins job, they see an error stating that version 1.0.1 already exists and so the publish fails.
So we're looking for a way that allows the user to run a local script or lerna command on their branch "feature/B" locally that pulls the latest version from registry and updates the version in local their to 1.0.1, so that when user B pushes this code and runs the publish job, he is able to publish 1.0.2 successfully.
An equally helpful solution would be if somehow we can ask lerna to skip already existing package version nos and just publish the next version no. i.e skip for 1.0.1 and directly go to publish 1.0.2.
Similar question to - How to manage canary version bump in monorepo with lerna from different branches
We are currently manually updating the package version nos locally when we encounter this issue which isn't ideal and we would like to automate this.
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.
I currently use Vue at my startup and right now, we don't have a CI system so each week, everything we're releasing gets merged to a release branch andI manually build the assets from there. The result bundle gets merged into master and becomes a part of production. I'll be away for a weeks and I want to ensure that if another developer has to make a frontend change, they build the assets properly. Some of them use a different operating system so is there a way I can ensure it will build the bundle as expected from my package.json?
I've googled around for an answer but have yet to turn up anything of use. Does anyone know why attempts to run ember test at best result in a message that reads:
Built project successfully. Stored in "/Users/.../tmp/class-tests_dist-H42JePnK.tmp".
If your tests won't run at all, here are a few things to look for:
Check for a testem.js file. It is essential and contains the instructions and configurations that the Ember CLI needs. Deleting it will cause your app to build and 0 tests to run.
Check to make sure your testem.js file is valid/complete. You can test this by doing ember init and then choosing option d (diff) to see what is different between your app and a brand new app.
Your tests are also available in the normal browser. Go to http://localhost:4200/tests and see what happens there. Perhaps it will give some clues.
Similar to above, try ember test --server and see if you get different results.
Create a fresh app with ember new and try doing ember test. It can sometimes be easier to compare a fresh app instead of doing the ember init diffing.
Try switching the browser you are using for testing (unlikely to be the problem in this case, but sometimes works). For example, run the tests with headless Chrome instead of PhantomJS. The most recent release of the Ember ClI has the testem configuration that you need to try headless Chrome.
How can I get ember-cli tests running on Sauce Labs? Testem has an example configuration, but I don't know how to translate that into the ember-cli compiled tests since the testem.json gets packed into the build when tests run.
I tried doing an ember build --env=test and then putting "test_page": "dist/tests/index.html" in my testem.js and just running testem ci --port=8080 as it is in the example, but that gives me 0 tests run.
I believe I have this mostly solved (some issues remain with individual browsers). For posterity you can view my solution here*:
The things that seem to be necessary:
Use NVM to manage node on OSX, things only started to work when I stopped having to sudo random junk.
Don't use localhost, I used localtest here for the hostname, but you can use anything - sauce and localhost don't get along very well.
The command is ember test --port=8080 --host=localtest
I put my sauce stuff in a different testem config file so I can still run ember test on my dev machine.
Hopefully having a starting place saves someone else from doing all of the wrong things I did originally.
*You probably don't need all of that, as we're currently using ember-cli api stubs to mock our API during development so we need to run a separate instance of ember serve.