-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Process + workflows for testing UI PRs against specified backend branch #1538
Comments
Document this process in Developer/contributing docs... |
The Gateway needs to additionally be able to pull in a Backend image, as was added to the UI. |
Does the gateway have tests that rely on a live backend? |
Ah, no, you're right! It's the Backend that pulls in the Gateway for some of its e2e tests! |
@Mythicaeda thanks for pinging me on this today - I added one more PR #1624 to handle your last comment + add docs to |
Background
We don't have a good process today for dealing with changes/features that require both an
aerie-ui
frontend PR and anaerie
backend PR (oraerie-gateway
PR). When the UI PR is submitted, the e2e test suite will fail because it is run against thedevelop
version of the backend (ie. it uses Docker images taggeddevelop
) which does not have the changes from the backend feature branch.The only ways to work around this today are:
docker-compose-test.yaml
on the UI branch to point to a different Docker tag temporarily - works, but then the PR is not safe to merge until you switch it back - otherwise would change the test branch for everyone on merge.develop
backend +develop
UI should always work together.Proposed Process
After discussing with a few devs, here's what I'm proposing as the process for this scenario:
___AERIE_IMAGE_TAG___="name-of-my-backend-branch"
docker-compose-test.yaml
& used as the tag name for theaerie
images during e2e testingaerie-gateway
branch you would put___GATEWAY_IMAGE_TAG___="name-of-my-gateway-branch"
If this is done correctly, all test suites should be able to pass on the frontend PR. You will still have to merge the backend PR before the frontend PR or else tests will fail in the merged
develop
branch but at least this avoids the unsafe workarounds mentioned above.The text was updated successfully, but these errors were encountered: