Skip to content
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

Closed
dandelany opened this issue Aug 22, 2024 · 5 comments · Fixed by #1624
Closed

Process + workflows for testing UI PRs against specified backend branch #1538

dandelany opened this issue Aug 22, 2024 · 5 comments · Fixed by #1624
Assignees
Labels
ci Changes to our CI configuration files and scripts

Comments

@dandelany
Copy link
Collaborator

Background

We don't have a good process today for dealing with changes/features that require both an aerie-ui frontend PR and an aerie backend PR (or aerie-gateway PR). When the UI PR is submitted, the e2e test suite will fail because it is run against the develop version of the backend (ie. it uses Docker images tagged develop) which does not have the changes from the backend feature branch.

The only ways to work around this today are:

  • Manually checkout the backend + UI branches locally - this works but isn't reflected in the PR's automated CI checks so you can't tell when it's safe to merge.
  • Change the 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.
  • Merge the backend PR first, then re-run checks on the frontend PR - works but leaves the system in an unsafe "halfway" state in the meantime until UI PR is merged. The combination of 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:

  • When the backend PR is submitted (or later), you tag it with a GH label called "publish".
    • This causes a GH workflow to publish docker images for the PR branch, tagged with the branch name, and re-publish them anytime the PR is updated with new commits.
    • This could be done automatically for all PRs, but we worry this could create a very large number of published images, so @Mythicaeda suggested we do it selectively.
  • When the frontend PR is submitted (or later), you add a specific string to the body of the PR that looks like ___AERIE_IMAGE_TAG___="name-of-my-backend-branch"
    • When the UI e2e Test workflow is run, it looks for a string like this in the PR body and sets the branch name in an environment variable if so
    • The env var is passed to the docker-compose-test.yaml & used as the tag name for the aerie images during e2e testing
    • Similarly, to specify an aerie-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.

@dandelany
Copy link
Collaborator Author

Document this process in Developer/contributing docs...

@Mythicaeda
Copy link
Contributor

The Gateway needs to additionally be able to pull in a Backend image, as was added to the UI.

@skovati
Copy link
Contributor

skovati commented Aug 30, 2024

Does the gateway have tests that rely on a live backend?

@Mythicaeda
Copy link
Contributor

Ah, no, you're right! It's the Backend that pulls in the Gateway for some of its e2e tests!

@dandelany
Copy link
Collaborator Author

@Mythicaeda thanks for pinging me on this today - I added one more PR #1624 to handle your last comment + add docs to CONTRIBUTING.md - once that's merged we can close this.

@github-project-automation github-project-automation bot moved this from In Progress to Done in Aerie Jan 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci Changes to our CI configuration files and scripts
Projects
Status: Done
3 participants