diesel-rs/diesel
1
1
Fork 0
mirror of https://github.com/diesel-rs/diesel.git synced 2024-10-04 09:39:24 +03:00
Code Issues Packages Projects Releases Wiki Activity
13123d620d
diesel/.travis.yml

63 lines
2.6 KiB
YAML
Raw Normal View History

Add travis
2015-11-26 22:11:57 +03:00
language: rust
Make sure Travis uses an up to date version of `sqlite` I have no clue why this changes based on the value of `sudo: required`. Without it, Travis uses 3.7. With it, Travis uses 3.8. Fixes #167
2016-02-01 22:55:53 +03:00
sudo: required
Setup travis in a way that doesn't use ancient SQLite versions The version that is in the container infrastructure is from 2011. We use `sqlite3_errstr` which was added in 2012. The switch to the "trusty" infratstructure bumps it to 3.8, which is relatively recent. This exposes a legitimate bug related to nul bytes in string fields that for some reason not replicating for me locally.
2016-01-31 20:40:02 +03:00
dist: trusty
Add travis
2015-11-26 22:11:57 +03:00
rust:
Get the build working on stable and beta This introduces syntex as a dependency on stable, which will pre-process the appropriate files for annotations. We need to document this process somewhere. Fixes #15
2015-11-29 00:23:04 +03:00
- stable
- beta
Follow convention for new AST pointers Old empty() method removed in https://github.com/rust-lang/rust/commit/9108fb7bae11f18715d971eeae1e5ca84662e1ee
2016-04-28 15:39:16 +03:00
- nightly-2016-04-25
Get the build working on stable and beta This introduces syntex as a dependency on stable, which will pre-process the appropriate files for annotations. We need to document this process somewhere. Fixes #15
2015-11-29 00:23:04 +03:00
- nightly
Add travis
2015-11-26 22:11:57 +03:00
addons:
Actually give travis the ability to upload docs
2015-11-28 22:41:21 +03:00
postgresql: '9.4'
Add travis
2015-11-26 22:11:57 +03:00
before_script:
First pass at schema inference This macro takes a database connection at compile time, inquires about the schema, and invoke the `table!` macro for you automatically. This is an early pass, and it doesn't support any types from third party crates, or custom primary keys (I'm not even 100% sure that it won't error some of the time on types that we do support). Right now we're going off of the type name and capitalizing it to find the right type. I'm unsure if we'd be better off using the OID (and then the aliases would be `Oid6342 = Array<Json>` or whatever). We do need to decide that before 1.0, as it'll be a breaking change for third party crates. I've had to do some funkiness in our tests, where basically I set up the schema on a separate database from where our tests run. This is because our suite assumes that we can rely on the id 1, which means the table has to be created in that test. I cannot drop the tables before the tests run, because on nightly I don't have a place to execute code after compilation finishes. As such, this doesn't actually make our tests look much cleaner, but once we refactor to work w/ persistenct schema we should be able to remove a lot of code.
2015-12-04 23:46:01 +03:00
- pip install 'travis-cargo<0.2' --user
- export PATH=$HOME/.local/bin:$PATH
- psql -c 'create database diesel_schema;' -U postgres
Add travis
2015-11-26 22:11:57 +03:00
script:
- |
Enable the chrono feature for documentation The `FromSql` impls aren't getting documented as is.
2016-04-03 01:07:24 +03:00
(cd diesel && travis-cargo doc -- --features "postgres sqlite chrono" && echo "docs.diesel.rs" > target/doc/CNAME) &&
Improve our test coverage for our time types The first attempt at adding support for `chrono::NaiveDate` was completely incorrect. This was in part due to the fact that I never tested for some known values. Combined with the fact that I've discovered quickcheck is testing a much smaller set of values than I thought (which would likely expose some bugs), I wanted to make sure that our existing tests for real values are at least valid. The quickcheck tests need to eventually be updated, as `PgDate` will not in fact round trip for values below -200000ish (earlier than Julian era), it will silently insert null.
2016-01-15 21:37:47 +03:00
if [[ "$TRAVIS_RUST_VERSION" == nightly* ]]; then
Remove hard dependencies on `libpq` and `libsqlite3` All code which *directly* depends on these has been moved to a separate module and placed behind a cfg attr. There is still a ton of PG specific stuff hidden in the expressions module that simply isn't marked as such. I had to rework how we do our boilerplate type impls, as `sqlite` and `postgres` need to be able to co-exist in the same compile pass (even just for generating docs). While this PR is pretty large, it ultimately mostly comes down to clerical work. Fixes #159.
2016-02-02 21:18:51 +03:00
(cd diesel && travis-cargo test -- --no-default-features --features "unstable chrono $BACKEND")
Improve our test coverage for our time types The first attempt at adding support for `chrono::NaiveDate` was completely incorrect. This was in part due to the fact that I never tested for some known values. Combined with the fact that I've discovered quickcheck is testing a much smaller set of values than I thought (which would likely expose some bugs), I wanted to make sure that our existing tests for real values are at least valid. The quickcheck tests need to eventually be updated, as `PgDate` will not in fact round trip for values below -200000ish (earlier than Julian era), it will silently insert null.
2016-01-15 21:37:47 +03:00
else
Remove hard dependencies on `libpq` and `libsqlite3` All code which *directly* depends on these has been moved to a separate module and placed behind a cfg attr. There is still a ton of PG specific stuff hidden in the expressions module that simply isn't marked as such. I had to rework how we do our boilerplate type impls, as `sqlite` and `postgres` need to be able to co-exist in the same compile pass (even just for generating docs). While this PR is pretty large, it ultimately mostly comes down to clerical work. Fixes #159.
2016-02-02 21:18:51 +03:00
(cd diesel && travis-cargo test -- --no-default-features --features "chrono $BACKEND")
Improve our test coverage for our time types The first attempt at adding support for `chrono::NaiveDate` was completely incorrect. This was in part due to the fact that I never tested for some known values. Combined with the fact that I've discovered quickcheck is testing a much smaller set of values than I thought (which would likely expose some bugs), I wanted to make sure that our existing tests for real values are at least valid. The quickcheck tests need to eventually be updated, as `PgDate` will not in fact round trip for values below -200000ish (earlier than Julian era), it will silently insert null.
2016-01-15 21:37:47 +03:00
fi &&
Move all database related functions into their own module
2016-02-04 19:20:57 +03:00
(cd diesel_cli && travis-cargo test -- --no-default-features --features "$BACKEND") &&
Run codegen's tests on CI These tests were broken by https://github.com/sgrif/diesel/pull/103, but the tests aren't run on Travis currently
2016-01-18 20:37:43 +03:00
if [[ "$TRAVIS_RUST_VERSION" == nightly* ]]; then
Update .travis.yaml * Set the correct database url for sqlite * Use Backend config for codegen tests
2016-03-01 11:59:31 +03:00
(cd diesel_codegen && travis-cargo test -- --no-default-features --features "nightly $BACKEND")
Run codegen's tests on CI These tests were broken by https://github.com/sgrif/diesel/pull/103, but the tests aren't run on Travis currently
2016-01-18 20:37:43 +03:00
else
Update .travis.yaml * Set the correct database url for sqlite * Use Backend config for codegen tests
2016-03-01 11:59:31 +03:00
(cd diesel_codegen && travis-cargo test -- --no-default-features --features "with-syntex $BACKEND")
Run codegen's tests on CI These tests were broken by https://github.com/sgrif/diesel/pull/103, but the tests aren't run on Travis currently
2016-01-18 20:37:43 +03:00
fi &&
That's not how shell works
2015-12-06 16:55:41 +03:00
if [[ "$TRAVIS_RUST_VERSION" == nightly* ]]; then
Initial SQLite support This commit adds all of the guts for SQLite3 support to Diesel. There are several outstanding issues which will need to be resolved before this is ready to be merged into master. This commit will not be merged into master until these issues have been resolved. Ultimately the most difficult remaining problem which we need to address is the lack of a `DEFAULT` keyword. I will detail why this is a problem and what I think we can do to solve it in a separate issue. SQLite has a fundamentally different mechanism for handling bind parameters than pretty much every other backend out there, where the function you call differs based on the type, rather than sending an array of bytes and telling the backend how to interpret it. `FromSql` had to be updated to address this (see https://github.com/sgrif/diesel/commit/8a330299443354575e48fcbe8f386024e239fe51 for details on that). I have not applied the same change to `ToSql`, as it was possible to shoehorn SQLite into our existing structure. While this may end up changing in the future, I do not believe it is necessary for 0.5. I'm not super happy about the structure of `StatementIterator`, `SqliteRow`, and `SqliteValue`, as ultimately the `Row` is a giant lie and `Statement` is the the value that maintains all of the state. Ultimately this comes out of the weird interaction between the fact that `Row#take` returns a reference, but sqlite's C api doesn't actually return a single value that works in that sense (and really doesn't have the concept of a row at all). As with much of our code overall, this can probably be cleaned up in the future by having the `Backend::RawValue` directly be a reference for `Pg`. I need to figure out a way to accomplish this without adding a lifetime to the `Pg` struct. I've broken our test suite into postgres specific and general where possible, but this is a *very* incomplete process. There are several modules which are entirely scoped to PG that do not need to be, which can be addressed independently in later PRs. Additionally, the entire `expression` module needs to be for expressions which are specific to PG. I do not believe that SQLite has anything specific to it which is not also supported by PG. Fixes #39 (mostly. Enough to close the issue at least)
2016-01-23 22:34:21 +03:00
(cd diesel_tests && travis-cargo test -- --no-default-features --features "unstable $BACKEND")
Update the travis build to work on nightly We need to exclude default features when `unstable` is included, or we'll end up having syntex in codegen, but trying to use rustc_plugin from tests
2015-11-29 01:18:21 +03:00
else
Update the local test script to handle #226
2016-03-28 02:09:32 +03:00
(cd diesel_tests && travis-cargo test -- --no-default-features --features "with-syntex $BACKEND")
Move `compile-fail` to a separate suite I want to write some tests confirming that PG expressions don't compile on SQLite. These are only meaningful when tested against Diesel with both SQLite *and* PG enabled, which we explictly don't want to do in the main test suite.
2016-02-03 17:43:58 +03:00
fi &&
if [[ "$TRAVIS_RUST_VERSION" == nightly* ]]; then
(cd diesel_compile_tests && travis-cargo test)
Update the travis build to work on nightly We need to exclude default features when `unstable` is included, or we'll end up having syntex in codegen, but trying to use rustc_plugin from tests
2015-11-29 01:18:21 +03:00
fi
Get travis up and running, on the latest nightly Wow, so apparently we don't built on stable or beta, not because of the compiler plugins, but because `For<i32> for i64` isn't on stable, and `For<i32> for f64` is only on nightly. Additionally, there was a breaking change in compiler plugins *tonight*, which I've updated for (and am pointing at a local branch for dependencies until it gets fixed upstream). Sorry for the breakage folks, I know it's a pain. Update to tonights nightly, it's now the only thing we work on, because I don't know how to make travis go to last nights. We'll be on stable by the end of the week.
2015-11-28 02:25:09 +03:00
env:
Initial SQLite support This commit adds all of the guts for SQLite3 support to Diesel. There are several outstanding issues which will need to be resolved before this is ready to be merged into master. This commit will not be merged into master until these issues have been resolved. Ultimately the most difficult remaining problem which we need to address is the lack of a `DEFAULT` keyword. I will detail why this is a problem and what I think we can do to solve it in a separate issue. SQLite has a fundamentally different mechanism for handling bind parameters than pretty much every other backend out there, where the function you call differs based on the type, rather than sending an array of bytes and telling the backend how to interpret it. `FromSql` had to be updated to address this (see https://github.com/sgrif/diesel/commit/8a330299443354575e48fcbe8f386024e239fe51 for details on that). I have not applied the same change to `ToSql`, as it was possible to shoehorn SQLite into our existing structure. While this may end up changing in the future, I do not believe it is necessary for 0.5. I'm not super happy about the structure of `StatementIterator`, `SqliteRow`, and `SqliteValue`, as ultimately the `Row` is a giant lie and `Statement` is the the value that maintains all of the state. Ultimately this comes out of the weird interaction between the fact that `Row#take` returns a reference, but sqlite's C api doesn't actually return a single value that works in that sense (and really doesn't have the concept of a row at all). As with much of our code overall, this can probably be cleaned up in the future by having the `Backend::RawValue` directly be a reference for `Pg`. I need to figure out a way to accomplish this without adding a lifetime to the `Pg` struct. I've broken our test suite into postgres specific and general where possible, but this is a *very* incomplete process. There are several modules which are entirely scoped to PG that do not need to be, which can be addressed independently in later PRs. Additionally, the entire `expression` module needs to be for expressions which are specific to PG. I do not believe that SQLite has anything specific to it which is not also supported by PG. Fixes #39 (mostly. Enough to close the issue at least)
2016-01-23 22:34:21 +03:00
matrix:
- BACKEND=sqlite
Go back to printing errors and then exiting 1 This was removed earlier because if a diesel_cli test started failing, it would abort the entire test suite because it exited with a status code of 1, which rust interprets as a problem. Now, because we shell out all our tests that ever hit this part of the code, we can go back to printing errors and exiting 1. This presentation is much nicer than a panic.
2016-03-13 18:04:18 +03:00
DATABASE_URL=/tmp/test.db
Initial SQLite support This commit adds all of the guts for SQLite3 support to Diesel. There are several outstanding issues which will need to be resolved before this is ready to be merged into master. This commit will not be merged into master until these issues have been resolved. Ultimately the most difficult remaining problem which we need to address is the lack of a `DEFAULT` keyword. I will detail why this is a problem and what I think we can do to solve it in a separate issue. SQLite has a fundamentally different mechanism for handling bind parameters than pretty much every other backend out there, where the function you call differs based on the type, rather than sending an array of bytes and telling the backend how to interpret it. `FromSql` had to be updated to address this (see https://github.com/sgrif/diesel/commit/8a330299443354575e48fcbe8f386024e239fe51 for details on that). I have not applied the same change to `ToSql`, as it was possible to shoehorn SQLite into our existing structure. While this may end up changing in the future, I do not believe it is necessary for 0.5. I'm not super happy about the structure of `StatementIterator`, `SqliteRow`, and `SqliteValue`, as ultimately the `Row` is a giant lie and `Statement` is the the value that maintains all of the state. Ultimately this comes out of the weird interaction between the fact that `Row#take` returns a reference, but sqlite's C api doesn't actually return a single value that works in that sense (and really doesn't have the concept of a row at all). As with much of our code overall, this can probably be cleaned up in the future by having the `Backend::RawValue` directly be a reference for `Pg`. I need to figure out a way to accomplish this without adding a lifetime to the `Pg` struct. I've broken our test suite into postgres specific and general where possible, but this is a *very* incomplete process. There are several modules which are entirely scoped to PG that do not need to be, which can be addressed independently in later PRs. Additionally, the entire `expression` module needs to be for expressions which are specific to PG. I do not believe that SQLite has anything specific to it which is not also supported by PG. Fixes #39 (mostly. Enough to close the issue at least)
2016-01-23 22:34:21 +03:00
- BACKEND=postgres
Go back to printing errors and then exiting 1 This was removed earlier because if a diesel_cli test started failing, it would abort the entire test suite because it exited with a status code of 1, which rust interprets as a problem. Now, because we shell out all our tests that ever hit this part of the code, we can go back to printing errors and exiting 1. This presentation is much nicer than a panic.
2016-03-13 18:04:18 +03:00
DATABASE_URL=postgres://postgres@localhost/
Actually give travis the ability to upload docs
2015-11-28 22:41:21 +03:00
global:
travis-cargo doesn't pass --features unstable on nightly-date for us
2015-12-06 16:59:31 +03:00
- TRAVIS_CARGO_NIGHTLY_FEATURE=""
First pass at schema inference This macro takes a database connection at compile time, inquires about the schema, and invoke the `table!` macro for you automatically. This is an early pass, and it doesn't support any types from third party crates, or custom primary keys (I'm not even 100% sure that it won't error some of the time on types that we do support). Right now we're going off of the type name and capitalizing it to find the right type. I'm unsure if we'd be better off using the OID (and then the aliases would be `Oid6342 = Array<Json>` or whatever). We do need to decide that before 1.0, as it'll be a breaking change for third party crates. I've had to do some funkiness in our tests, where basically I set up the schema on a separate database from where our tests run. This is because our suite assumes that we can rely on the id 1, which means the table has to be created in that test. I cannot drop the tables before the tests run, because on nightly I don't have a place to execute code after compilation finishes. As such, this doesn't actually make our tests look much cleaner, but once we refactor to work w/ persistenct schema we should be able to remove a lot of code.
2015-12-04 23:46:01 +03:00
- secure: NmCM1VNEzid6bROA7tXV1R63n9S9KvY1etXsDzd1608cvjRnG3ZDAWXISbY1BxqrvleElreUJOvz/3TSQCHivpT2ezeyk2sntYtZpw0TWbz1SQMAPNWPTjP3bNQzpmNwfU4p6ui6qIOnQza4JxOu3SZSveNlehDBPkkS+52R7Zw/EPdwi9jTYJArV2+8pnEsQECAdRLttbtA2JBl3hZ4VHfGpHRZyeULn63UzyVbQVzQ3NVhqyQUKTPdpUciQTI3fZEkfaWuLV8QPPa5026/yJEEi2Fsl3r7fyY8ia67k4Zo9THlPVD0YOUlkWuZWwvkxNA8RQSVPv4FidEpwbxG8y6nAra4CjwiEChcpFhZJtrH7ZrXO/tJk7vtc5CFVWUsQtNX92QY1QFdPxwYNBSICLyUN+A+BQURwvQgxdcJsJyQmh5Ed7yuavcAinVq7fPeOyBWcPL5mt17no16aG1rzvXSUnD0aH7F3S3DHkoM9P9iHgJMLk+2YNmJtFescBxCeG8bA7t5bw0kQNH5KUWAD1uYpC9ikB3NVdlc+q17dKTAe4rcYA+sIO+UGudvpmLWT0lXtEMqDfxfCmyICDESs9bNfueCGJEAnfTBNunsJqR7rMUvjNndS2/Ssok6c/0Yfb9X8cM9nI4QLAj/+hClqdYphmpCjuC34bWxFSt/KJI=
Allow failures on travis nightly
2015-12-06 02:40:00 +03:00
matrix:
allow_failures:
Swing and a miss on first travis config.
2015-12-06 03:01:24 +03:00
- rust: nightly
Upload docs from travis
2015-11-28 22:32:35 +03:00
after_success:
Ensure that we are *actually* able to compile without PG While the tests were passing previously, we didn't actually build if you compiled without libpq installed on your system. This corrects those issues, and the failures that resulted from it. There are several places where I'm legitimately unsure how the code compiled before this change. I've had to do some janky things to codegen to make it actually work, as there's an issue where cfg attrs aren't properly applied inside of `include!`. This is why the dummy version has to exist, and why it warns instead of errors. It might make sense to just define the macro as a no-op in the future.
2016-02-03 00:31:18 +03:00
- "(cd diesel && travis-cargo --only stable doc-upload)"
Only build travis on master For some reason the build badge uses *all* branches and not just master. I can't remember if this fucks with PRs or not, but we'll find out
2015-12-04 00:23:14 +03:00
branches:
only:
- master
- ಠ_ಠ
Setup travis in a way that doesn't use ancient SQLite versions The version that is in the container infrastructure is from 2011. We use `sqlite3_errstr` which was added in 2012. The switch to the "trusty" infratstructure bumps it to 3.8, which is relatively recent. This exposes a legitimate bug related to nul bytes in string fields that for some reason not replicating for me locally.
2016-01-31 20:40:02 +03:00
- diesel-sqlite-support
Add Travis notifications to the contributors gitter room
2016-01-18 20:22:16 +03:00
notifications:
webhooks:
urls:
Update the travis webhook URL (the other doesn't appear to be working) It's possible the blank line was the problem as well
2016-01-18 20:35:36 +03:00
- https://webhooks.gitter.im/e/1d32e0ad32841bd56b02
Add Travis notifications to the contributors gitter room
2016-01-18 20:22:16 +03:00
on_success: change
on_failure: always
on_start: never
Reference in New Issue Copy Permalink