| Age | Commit message (Collapse) | Author |
|---|
|
|
|
af83/4962-when-WorkbenchImport-is-deleted-also-delete-associated-Referential-if-ready-false
4962 when workbench import is deleted also delete associated referential if ready false
|
|
objectid_support handles reading and writing object_ids
objectid_formater_support gets the right formater class
include these concerns in chouette models
Remove StifNetexAttributSupport modules because these are handled by the new objectid concerns
Add a objectid and formater classes for each format type
Add objectid formats to the factories
Modify somes specs for object_ids but there are still a number of failling tests
|
|
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
|
|
Refs #4516
|
|
Refs #4516
|
|
If the `NetexImport`'s associated `Referential` has `ready: false`, when
the `NetexImport` is destroyed, also destroy the `Referential`.
This prevents a case where users get an invalid `Referential` as a
result of an import, but because of the `ready: false`, it doesn't
display on the website, so they can't see what the problem is.
Refs #4962
|
|
|
|
Return `true` from this method by default. If the `#update` call fails,
then it will return `false`, but in all other cases, we should return
`true`. That way, when the
`Api::V1::ComplianceCheckSetsController#validated` endpoint is called,
it will respond with the `ComplianceCheckSet` object instead of:
{"status":"error","messages":[]}
with no error messages.
Refs #4757
|
|
If any associated resources have the "IGNORED" status, this shouldn't
affect the outcome of a "successful" status. Allow the
`ComplianceCheckSet` to be "successful" even if some `Resource`s are
"IGNORED".
Refs #4757
|
|
We should return the result of the `ActiveRecord` `#update` call, so
that we can determine if there was an error saving the
`ComplianceCheckSet` record.
Refs #4757
|
|
This reverts commit b7477e28f90c961079c7b12c4992071cbc11b2d6.
This logic isn't right. We should return true/false based on the result
of `update`, as in, whether the value was able to be updated, instead of
on the contents of the status.
|
|
Ensure that `#update_status` always returns a boolean value. We'll be
using this to determine whether the updated status was 'successful' or
not. Hmmm. Wait. That's not right. We want to return true from the
update, we don't care about the status. The error case should be when
the `update` fails. Darn.
Refs #4757
|
|
Move the successful `ComplianceCheckResource`s to the end so that these
tests fail if we don't wait until the end of a loop through the resoures
before updating the status to 'successful'.
Refs #4757
|
|
Add test cases for status update when `ComplianceCheckResource` are
"ERROR" and "WARNING". If a single Resource is "ERROR" or "WARNING",
then the `ComplianceCheckSet` becomes "failed" or "warning".
Refs #4757
|
|
Initial spec that checks the correct status field change when all
`ComplianceCheckResource`s are successful.
Refs #4757
|
|
On successful status update, respond with the `ComplianceCheckSet`
object attributes. Otherwise, respond with an error JSON.
Refs #4757
|
|
Get the `ComplianceCheckSet` from the URL and call its `#update_status`
method.
This doesn't currently work all the way. We need to send a real
response.
Refs #4757
|
|
This route will be called by the Java application when ComplianceCheck
validation is completed.
It will perform post-validation work, primarily updating statuses.
Refs #4757
|
|
If the `Import`'s associated `Referential` has `ready: false`, destroy
that `Referential` when the import is destroyed.
Aaand looking back at the task it turns out that's not what I was
supposed to do. Right, it does seem a little weird in retrospect.
Instead we want to delete the `Referential`s of child imports.
Refs #4962
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4755 page for validate referential
|
|
|
|
add specs
|
|
|
|
4802 referential model normalisation
|
|
|
|
CR 3rd (and hopefully last) part
- more typo corrections
- reactivating deactivated specs
- fixed reactivated specs
|
|
af83/4782-create-worker-for-compliance-check-copy--rb201710301748
4782 create worker for compliance check copy rb201710301748
|
|
CR 2nd part
- typos
- unnecessary `class: Referential` removed from referentials_factory
- regrouping of referential_suite related model specs
|
|
CodeReview:
- Exchange fr and en translation files for referential_suites
- Consistent usage of `jeu de donées` and `espace de travail` dans les *fr.yml
Fixes: #4802@0.2h; Replaying former work. To identify spec regression
Step 3: Added validation of reference_suite#new/current
Made all specs pass
|
|
The `ComplianceControlSetCopyWorker` depends on
`ComplianceControlSetCopier#copy` to return the `ComplianceCheckSet`
that it creates.
Refs #4782
|
|
Step 2: Added validation of reference->workbench->organisation consistency
Made all specs pass
Chased bug #4826
|
|
Filter Feature Spex of ComplianceControlSet#show implemented
|
|
ComplianceControl.subclass_patterns [amend me] [skip-ci]
|
