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
c16ab9cfe8
diesel/.travis.yml

80 lines
3.5 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
Remove `diesel_codegen_old`, unpin nightly This removes the dead code that was laying around as the result of the now defunct pre-macros 1.1 implementation of codegen. I've also unpinned the nightly version, as we should no longer break due to changes in libsyntax. Finally, I've made sure the newly added crates are run as part of the test suite. The removal of `.cargo/config` and the addition of `[replace]` all over the place is to work around https://github.com/rust-lang/cargo/commit/fc0e64262a3c3b461f004d6fa75732ca656e73bd. I'm not sure what our long term plan is yet, as juggling that doesn't sound fun to me.
2016-10-10 19:45:01 +03:00
- nightly
Travis, we don't fail on beta! Also, cache some things. This will become more useful when cargo a workspace is used so there is one central `target/` directory.
2016-09-09 17:58:36 +03:00
cache: cargo
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
Enable MySQL on Travis It is time.
2017-02-10 19:26:41 +03:00
- mysql -e "create database diesel_test; create database diesel_unit_test; grant all on \`diesel_%\`.* to 'travis'@'%';" -uroot
Add travis
2015-11-26 22:11:57 +03:00
script:
- |
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 &&
Ensure that our examples continue to compile as part of our tests Travis of course isn't following the guide, so it won't have set `DATABASE_URL` to what I want nor will it have run `diesel setup`
2016-08-15 19:47:29 +03:00
if [[ "$BACKEND" == postgres ]]; then
Delete `diesel_codegen_syntex` Macros 1.1 is now on 1.15 beta. We will not be releasing a new version until after that beta has launched. Dropping the syntex support from our own code base makes life easier for development.
2017-01-08 19:23:17 +03:00
(cd examples && ./test_all)
Ensure that our examples continue to compile as part of our tests Travis of course isn't following the guide, so it won't have set `DATABASE_URL` to what I want nor will it have run `diesel setup`
2016-08-15 19:47:29 +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") &&
Enable tests for diesel_infer_schema crate
2017-01-20 01:46:32 +03:00
(cd diesel_infer_schema && travis-cargo test -- --no-default-features --features "$BACKEND") &&
Remove diesel_codegen_shared
2017-02-02 23:22:22 +03:00
(cd diesel_codegen && travis-cargo test -- --no-default-features --features "dotenv $BACKEND") &&
That's not how shell works
2015-12-06 16:55:41 +03:00
if [[ "$TRAVIS_RUST_VERSION" == nightly* ]]; then
Delete `diesel_codegen_syntex` Macros 1.1 is now on 1.15 beta. We will not be releasing a new version until after that beta has launched. Dropping the syntex support from our own code base makes life easier for development.
2017-01-08 19:23:17 +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
Delete `diesel_codegen_syntex` Macros 1.1 is now on 1.15 beta. We will not be releasing a new version until after that beta has launched. Dropping the syntex support from our own code base makes life easier for development.
2017-01-08 19:23:17 +03:00
(cd diesel_tests && travis-cargo test -- --no-default-features --features "$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
Add travis build step for clippy
2017-02-10 13:50:36 +03:00
matrix:
allow_failures:
- rust: nightly
include:
Now that clippy is happy, make @sgrif happy, too
2017-02-10 18:19:17 +03:00
- rust: nightly-2017-02-09
Add travis build step for clippy
2017-02-10 13:50:36 +03:00
env: CLIPPY=YESPLEASE
script:
Now that clippy is happy, make @sgrif happy, too
2017-02-10 18:19:17 +03:00
- (cd diesel && cargo rustc --no-default-features --features "lint unstable chrono serde_json uuid sqlite postgres mysql" -- -Zno-trans)
- (cd diesel_cli && cargo rustc --no-default-features --features "lint sqlite postgres mysql" -- -Zno-trans)
- (cd diesel_codegen && cargo rustc --no-default-features --features "lint dotenv sqlite postgres mysql" -- -Zno-trans)
Add clippy to infer schema crate Oops, totally forgot about that one!
2017-02-12 17:34:31 +03:00
- (cd diesel_infer_schema && cargo rustc --no-default-features --features "lint dotenv sqlite postgres mysql" -- -Zno-trans)
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/
Enable MySQL on Travis It is time.
2017-02-10 19:26:41 +03:00
- BACKEND=mysql
DATABASE_URL=mysql://travis@localhost/diesel_test
MYSQL_UNIT_TEST_DATABASE_URL=mysql://travis@localhost/diesel_unit_test
RUST_TEST_THREADS=1
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=
Upload docs from travis
2015-11-28 22:32:35 +03:00
after_success:
Use a cargo workspace
2016-08-19 13:39:12 +03:00
- |
Release v0.10.0 (The one where we work on stable) ![It's happening](http://i.imgur.com/7drHiqr.gif) v0.10.0 drops support for Rust 1.14 and earlier, and adds support for Rust 1.15 (ON STABLE). `diesel_codegen_syntex` has been removed, and is no longer supported. Additionally, this release adds initial support for the JSON data type in PostgreSQL. There is also a new `print-schema` subcommand in Diesel CLI which will show you the code generated by `infer_schema!()`. As always, you can find a full list of what has changed in [the changelog][changelog]. In addition to the Diesel core team, 7 contributors worked on this release. A huge thank you to - Adrian Perez de Castro - Eric Kidd - Georg Semmler - Jake Goulding - Sergio Benitez - Severen Redwood - Stu Black I'd also like to thank everybody who helped this release by opening issues, finding bugs, and asking/answering questions in our gitter room. There were several big features that I had hoped to get done in time for this release, but my daughter inherited my troll gene and decided to come early. If you were hoping for MySQL support, blame Ruby. In the mean time, here is a picture of Ruby. ![baby ruby](https://lh3.googleusercontent.com/7vUZONdvrati-NQXriSqzKQ0CHNz6KRulOSos9kJjzMNV-JI2UT6d4Kxex9fZGO-0GTlLrKHKRwiPaf2v6hCJlCU0IgK5kWd_JWz9nG61FrZfgVARZEqXOmjoXPb5CYrbTg7XlG2VEYlcm6_Lk9oviVPh7mx3gaXgVG6g-OJRHqY_gipU-Y2REPFDoJyPWZ9QoifZH1WDGSPdyYUQ1KWeTfFkxk1Z3VP1bKAyRhsDmnXvSLaWkBQ6r5CpRS2pfVMC0lPVAfPGmrjwmNw7JmFNfscQM5IY0FOqbbwJhPJvLtNb-jOgOQhz07S8HA9BBI_cWzzXXMxbGXzaPpKBYSrioMja3MkXcb1PGB8cG7ERtG_CWwpGriRlFbrj2B0OygkAu4Q6pRiQe6BojpHYp03uyRsmsVxTbQjlH3axed6tNV_IDYSd2vz15gB7yFKUF_Je3spUUdexLmybdPDR29DfD-hBBJfezy0gdzrf7dJMMXWgQ7CW6jH18uydl-iiK3_8Ha8FUuvrjcA-Dvv0nQEXqajcb_NFCpobr92fNQvDCg6UNj3o7E7bv55Oj6sOk7N7xARchy-MmAV8Tzzc1Sx-4GKHhikH5WGMb5AzYSnoNcvWr7mD4vqAF1Wn_60Huz1KCNC5m2aBbPz9G6hBcM3pMe8J5pIM4epvKFvKUKtK98=w792-h1056-no) [changelog]: https://github.com/diesel-rs/diesel/blob/v0.10.0/CHANGELOG.md
2017-02-02 21:17:47 +03:00
if [[ "$TRAVIS_RUST_VERSION" == stable ]]; then
Use a cargo workspace
2016-08-19 13:39:12 +03:00
(cd diesel && travis-cargo doc -- --features "postgres sqlite chrono uuid")
Correctly build docs `travis-cargo doc-upload` assumes that the `Cargo.toml` in the cwd is the manifest for the package being documented, and it also assumes that the docs are present in `target/doc`. There isn't really any way to make both of those things true if we're using a workspace, so let's just move the folder there after we document everything.
2017-02-02 19:48:33 +03:00
mkdir diesel/target
mv target/doc diesel/target/doc
echo "docs.diesel.rs" > diesel/target/doc/CNAME
(cd diesel && travis-cargo doc-upload)
Use a cargo workspace
2016-08-19 13:39:12 +03:00
fi
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
- ಠ_ಠ
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