-
Notifications
You must be signed in to change notification settings - Fork 152
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
Adds a graphql validation script to force deploys #3061
Conversation
Alternative take, should this happen on a PR to release instead? |
I switched this to use Danger to give a warning instead |
Looks like Danger got removed from CI, so I've added back travis for running Danger on this repo |
b077074
to
5e0341b
Compare
85c451b
to
1aa3e73
Compare
This is really cool! thanks @orta as always! |
1aa3e73
to
b6de4a9
Compare
b6de4a9
to
f2cab46
Compare
this is really useful!! merge on green |
.circleci/config.yml
Outdated
@@ -9,7 +9,7 @@ jobs: | |||
- checkout | |||
- run: | |||
name: Acceptance Tests | |||
command: 'yarn install && yarn acceptance src/test/acceptance/*.js' | |||
command: "yarn install && yarn acceptance src/test/acceptance/*.js" |
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.
random q - is there any reason for this diff? Do we prefer single quoted strings in circle ci config files?
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.
prettier does yml files, so these are the same code standard as the rest of front-end apps
@@ -0,0 +1,2 @@ | |||
language: node_js | |||
script: yarn danger ci |
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.
@orta I see that in #3061 (comment) you mentioned that danger got removed from CI, but can you elaborate? I'm just wondering if there's a way that we can modify the configuration for Circle than introduce another build system for this project.
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.
Yep, could be done, but it's simpler this way as it doesn't have to run inside docker and Travis is more reliable than Circle for Danger (due to the way they both handle ENV vars)
That said, this could also be ported to peril (instead of looking in the node modules, pull out the GraphQL schema from the git repo) but this should be enough for now.
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.
Hah, nice, looks like that is the way to go - the graphql schema for reaction was removed last week, artsy/reaction#1631
} | ||
|
||
// Breaking change check for Metaphysics production when deploying | ||
if (danger.github.pr.base.ref === "release") { |
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.
I know a conversation topic during our recent platform practice meeting was checking for "dependencies in prod" before code hits staging as well, as such, ensuring that we never have staging code that shouldn't be deployed production.
Thoughts on updating this to run on PRs to master
-- providing the staging check?
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.
I'm interested in this^ too, but am OK with enforcing this on staging->release merges to start (and we can extend based on how that goes and how often it's an obstacle).
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.
I'm wary that this will "break" builds that have nothing to do with metaphysics, so happy to do this as-is now and can look at making a tighter loop for when people either update reaction or other builds
buildClientSchema, | ||
printSchema, | ||
buildSchema, | ||
findBreakingChanges, |
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.
so there's first class support for this in graphql-js
? Very cool!
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.
Yeah, I was surprised too!
8014c71
to
999d53a
Compare
999d53a
to
a901042
Compare
This script detects breaking changes between Reaction's schema and the one currently on prod.
The current one (where metaphysics prod is a week out of date) looks like: