#19891: Travis CI support
--------------------------------------+------------------------------------
Reporter: marko@… | Owner: gcc
Type: Cleanup/optimization | Status: assigned
Component: Testing framework | Version: master
Severity: Normal | Resolution:
Keywords: Travis, CI, testing | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by apollo13):
Replying to [comment:26 gcc]:
> Please could you tell me why you don't want config stuff in the repo?
As I already said on the mailinglist: I don't want to have commits in
Django's timeline saying: "And another fix for travis, oh and another one
for travis again". It's bad enough that they require me to add a
.travis.yml, CI shouldn't be bound to a repo like this.
> * is dangerous (security risk to Travis and hence our reputation),
Why would that be a security risk?
> * is unreliable (might go away suddenly with no warning),
More unreliable than Travis? Also once we deploy this we will either fetch
from dp.com or similar, so it surely won't just go away.
> * makes it impossible to test new configs if you don't have write access
to the repo where they're stored, and
No, you just have to change the environment variable in your branch and
point to your server.
> * eliminates them from version control, or at least separates them into
a different repo or VCS for no reason that I can see.
The main idea for this split was to be able to version them in a separate
repository; after all CI-config depends on the one running the CI and
shouldn't be in the main repo.
> What's crazy about them?
Cause it's completely fragile, if travis changes from /var/ramfs to
something else your builds start failing.
> Will look into the email issue, but I'm not sure we can do anything
except creating a new account with a /dev/null email address and making it
a collaborator on the django repo.
I doubt that will help, Travis (at least that's how I understood it) looks
at the email addy of the commits that got pushed to the repo and then bugs
people accordingly.
> Why is splitting the PG tests not an option?
Cause it introduces more complexity, this should be a last resort.
--
Ticket URL: <https://code.djangoproject.com/ticket/19891#comment:27>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/073.8ba83a34d95d34646f9282c65fe933ef%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
