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.
Related
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.
I have an Angular CLI project, which is a large single-page app. This app is divided into multiple feature modules that are lazily loaded.
What I'd like to be able to do is to go into the subdirectory of one of my modules and run just the tests for that module. The idea is to have our CI server be able to detect which module(s) have changed and only run the tests for those module(s).
Is there a way to do this? I tried running ng test from within the module subdirectory, but that didn't seem to do it. Hopefully there is a way to do this.
A quick hack for this may be to change all your tests from it( to xit( this will exclude them from the test.
I got a question regarding build controllers of Visual Studio.
I got a project where I run multiple C# unit test. I currently implemented Javascript Unit tests to the project and I want to let the unit test be part of the build.
Several tutorials are available on the internet. One of them I used as guideline towards running JS intergrated within my TFS which is running on a buildserver.
The problem that I have is that the tutorial is saying that I should check in the files (of Chutzpah) and add the source file to the build controller. Here is my problem. Due to the fact that I do not want to affect all the other unit tests and build processes I can not modify the build controller. I can change any build definition but I can not change the "Version Control Path to custom Assemblies". So I was wondering is there alternative method where I still can make sure that JS unit tests are part of the build but not changing the version control path for the whole project?
I hope I stated my situation clear enough.
You can enable your build process to leverage binaries that you have
uploaded to your Team Foundation Server, for example:
Assemblies that contain your custom workflow activities.
Third-party unit test frameworks. See Run tests in your build process.
Custom MSBuild tasks
To enable your build processes to leverage these kinds of code, upload
the binaries to the folder (or any of its descendant folders) that you
specify in the Version control path to custom assemblies box. MSDN
So, if you haven't configured this path of your build control. It's easy, you just need to set a sever path. This will not affect other unit tests and build processes cuase they didn't even use this path before.
If there is aleady a server path, you just need to add the files mentioned in the tutorials into the source control with the same path. Just like a share folder, when the build definitions need the file, the build control will automatically find and call it in this path. When you set or modify the value in this box, the build server automatically restarts to load the assemblies.
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.
If I fork a project, and make changes on it, how can I let Travis build the project?
I forked it, it will wait until I make a pull request to give me the build status, but I should test it independently to make the pull request? Because the icon (build|passing) follows the initial project, and not the forked one.
You go to travis-ci.org, log in (using your github account) and then follow the following simple guide:
Enable your projects below by flicking the switch, add a .travis.yml to your project, and push a new commit to GitHub.
This will lead to your own travis build, independent of the original project and you won't have to wait for any pull requests to be merged.
You'll find the specifications for your .travis.yml on docs.travis-ci.com if you want to do further changes, since you forked a project that already contains one you're all set for now.
Once this is all setup you can adapt the URL in the readme.md file to point to your travis build