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

dev: Add round-trip test for Recurser collection #64

Merged
merged 5 commits into from
Aug 9, 2024
Merged

Conversation

jdkaplan
Copy link
Collaborator

@jdkaplan jdkaplan commented Aug 6, 2024

I want to be able to experiment with Pairing Bot locally, which means I'll need some way to run Firestore without also running all of Google Cloud. It turns out that there's an emulator inside of gcloud which is made exactly for this purpose!

The Firestore Go SDK we're using automatically supports using this via the FIRESTORE_EMULATOR_HOST environment variable.

Changes

This sets up a single round-trip test to prove that this all works. I left space to add more because I'll be collecting them in the future as I learn about how Firestore works (and how we use it!).

I also made these tests run on PRs to the dev branch. I intend to treat them as non-blocking there, but I do think it's nice to know that we've broken unit tests before deploying, even if it's just to the test bot.

I also added a dev.sh script to help me remember how to start the emulator. It uses the same variable as the SDK so something like direnv makes it "just work".

@jdkaplan jdkaplan force-pushed the jdkaplan-db-tests branch 2 times, most recently from 09fd32d to b7be051 Compare August 6, 2024 17:02
@jdkaplan jdkaplan marked this pull request as ready for review August 6, 2024 17:05
@jdkaplan jdkaplan linked an issue Aug 6, 2024 that may be closed by this pull request
.github/workflows/go.yml Outdated Show resolved Hide resolved
version: '>= 486.0.0'
install_components: 'cloud-firestore-emulator'

- name: Start Firestore emulator
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, huh, jobs run in parallel by default!

Do we need to impose an order on these? Will the emulator keep running in the background even after the job is done?

If the answer is "we need to submit this and try it to see", that's fine :D

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's already an order imposed because steps run sequentially even though their containing jobs run in parallel. (The YAML diff doesn't make this very easy to see, but I only appended to the one existing job.)

That said, I did consider splitting jobs.build and jobs.test. But go build is so fast that all it would really do is cause setup-go module-cache issues between the two jobs.

@cceckman
Copy link
Collaborator

cceckman commented Aug 7, 2024

Looks good, just nits / questions!

@jdkaplan jdkaplan merged commit 8bc7df4 into dev Aug 9, 2024
1 check passed
@jdkaplan jdkaplan deleted the jdkaplan-db-tests branch August 9, 2024 20:16
@jdkaplan jdkaplan mentioned this pull request Aug 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create a testing environment for Pairing Bot
2 participants