-
Notifications
You must be signed in to change notification settings - Fork 15
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
Conversation
09fd32d
to
b7be051
Compare
b7be051
to
7f42ae5
Compare
version: '>= 486.0.0' | ||
install_components: 'cloud-firestore-emulator' | ||
|
||
- name: Start Firestore emulator |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
Looks good, just nits / questions! |
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".