You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CI: new job which fails if a file contains FIXME (#5121)
When working on a big PR, sometimes you have something you know you need to fix
before merging. With this CI job, just add a FIXME comment and you'll be forced
to address it before all CI can pass.
We intentionally allow CI to make tarballs for a commit and publish npm packages
even with FIXME, because you may want to test out a build of an incomplete PR.
Change existing TODO comments to FIXME. Document this requirement in
CONTRIBUTING.md and make the text about PRs with failing tests a bit gentler.
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -74,7 +74,7 @@ For significant changes to a repository, it’s important to settle on a design
74
74
75
75
It’s important that every piece of code in Apollo packages is reviewed by at least one core contributor familiar with that codebase. Here are some things we look for:
76
76
77
-
1.**Required CI checks pass.** This is a prerequisite for the review, and it is the PR author's responsibility. As long as the tests don’t pass, the PR won't get reviewed.
77
+
1.**Required CI checks pass.** This is a prerequisite for the review, and it is the PR author's responsibility. As long as the tests don’t pass, the PR won't get merged. If you're having a challenge getting tests to pass, feel free to ask for help. In addition to running tests, CI will fail if you add the words FIX and ME without a space within them in any file; this lets you add comments during the development process that you can't forget to address before merging.
78
78
2.**Simplicity.** Is this the simplest way to achieve the intended goal? If there are too many files, redundant functions, or complex lines of code, suggest a simpler way to do the same thing. In particular, avoid implementing an overly general solution when a simple, small, and pragmatic fix will do.
79
79
3.**Testing.** Do the tests ensure this code won’t break when other stuff changes around it? When it does break, will the tests added help us identify which part of the library has the problem? Did we cover an appropriate set of edge cases? Look at the test coverage report if there is one. Are all significant code paths in the new code exercised at least once?
80
80
4.**No unnecessary or unrelated changes.** PRs shouldn’t come with random formatting changes, especially in unrelated parts of the code. If there is some refactoring that needs to be done, it should be in a separate PR from a bug fix or feature, if possible.
0 commit comments