| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Thanks again to Robert. Today I learned what the `x` flag is. It ignores
whitespace inside the regex pattern. This way we can add spaces to make
the pattern more readable and still match what we were matching before
when the code was more condensed. Nice!
Refs #4951
|
|
Thanks to Robert for suggesting `(?:...)`. I didn't know that syntax,
happy I learned something new. Here, I had used parentheses for the "or"
(`|`), but didn't need the captured value. To do the "or" without
capturing, you can use the `?:` inside the start of the parentheses.
Refs #4951
|
|
Robert wisely recommended using `\s` just in case somehow tabs end up in
the `schema.rb` file.
Refs #4951
|
|
Apparently the Jenkins server runs Ruby 2.2.0.
Sample log output:
/usr/bin/ruby2.2 -I/var/lib/jenkins/workspace/stif-boiv-branches/vendor/bundle-201746/ruby/2.2.0/gems/rspec-core-3.5.4/lib:/var/lib/jenkins/workspace/stif-boiv-branches/vendor/bundle-201746/ruby/2.2.0/gems/rspec-support-3.5.0/lib /var/lib/jenkins/workspace/stif-boiv-branches/vendor/bundle-201746/ruby/2.2.0/gems/rspec-core-3.5.4/exe/rspec --pattern spec/\*\*\{,/\*/\*\*\}/\*_spec.rb
WTF? I thought we were all using Ruby 2.3.
Here's the error:
/var/lib/jenkins/workspace/stif-boiv-branches/spec/db/schema_spec.rb:38: syntax error, unexpected << (SyntaxError)
<<~EOS
^
/var/lib/jenkins/workspace/stif-boiv-branches/spec/db/schema_spec.rb:40: syntax error, unexpected ':', expecting keyword_end
Diff: #{diff}
^
Convert the tilde-heredoc to a dash-heredoc to make Jenkins happy.
Refs #4951
|
|
Change the matching logic to support better diff output. Here, we
construct two in-memory string versions of the `schema.rb` file, one
with the original content, and another with the pseudo-expected values.
Of course, the expected values are generated, not real, but this at
least gives devs and idea of what the problem is. Additionally, it also
gives the line numbers where the expectation fails from RSpec's default
multi-line string differ.
This version looks at the file line-by-line instead of streaming it and
feeding it through `#grep` and `#grep_v`, so I imagine performance is
worse (assuming Ruby uses C-implementations for those functions), but as
far as I know there's no way to get line numbers using `#grep`. Since
the `schema.rb` file is generally small relatively speaking, this should
be fine.
Refs #4951
|
|
Some of our tables don't have IDs. These shouldn't fail on type `bigint`
because they don't exist in the first place.
Refs #4951
|
|
This enables us to add custom formatting to the failure message. For
now, the logic works the same way as before. The offending lines are
compared to an empty array and appear in the output. We're missing line
numbers. I think we'll want to actually compare to an entirely new
in-memory version of the schema ideally so that it can output the right
line numbers and corrections.
The differ is based on Alexey Shin's:
https://stackoverflow.com/questions/32477104/rspec-custom-diffable-matcher#32479025
Refs #4951
|
|
These were my initial tests for how to do the verification of `bigint`
types. Now that the code has been ported to Ruby, we can get rid of
these lines.
Refs #4951
|
|
We use `bigint`s by default for all primary and foreign keys in the
application.
Using `bigint`s provides two advantages:
* Matching the Java application, which expects `bigint`s
* Providing support for large integer identifiers
Here, we add a spec that checks the `schema.rb` file with line-by-line
string matching to validate that no primary or foreign keys use
non-`bigint` types.
The test is a bit rough at the moment, but it works against the
temporary migration included in this commit. It should be reworked,
though, to include line numbers of the problem fields.
Refs #4951
|
