#19891: Travis CI support
-------------------------------------+-------------------------------------
Reporter: marko@… | Owner: dokterbob
Type: | Status: assigned
Cleanup/optimization | Version: master
Component: Testing framework | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: Travis, CI, testing | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 0
Needs tests: 0 | UI/UX: 0
Easy pickings: 1 |
-------------------------------------+-------------------------------------
Comment (by dokterbob):
TLDR; Single commit everytime Travis tests break should be no problem, but
if it is will work on Travis repo.
@apollo13 The talk just now at DjangoCon made me remember this issue and
read the related thread on the mailinglist. Have had no time to actually
discuss on the dev' list but will present some arguments here.
Personally I don't think it's elegant having a seperate repository just to
keep a couple of commits out of the public timeline. Most Travis issues
can be easily fixed in a fork/pull request as the exact same tests are run
under the exact same circumstances there - part of the point of having
Travis there in the first place.
Having a seperate repo with just a config file potentially makes the tests
more fragile as a change to the Travis config could cause tests to fail
for no clearly apparent reason.
If I could talk you guys into having Travis support in the main Django
repo I will to the following:
1. Pick up old work; rebase my branch to current master.
2. Disable e-mail and IRC notifications for core dev's piece of mind.
3. Run the tests again a couple of times to see if anything breaks.
4. Create a single cute litte patch so there'll no 'fixing Travis' in the
public timeline for now.
Anyways, if the core devs do decide to go with a split-repo approach to
Travis I'm willing to work on it during DjangoCon EU and will either
finish it or leave it 'open' by the beginning of the sprints (will take
train on friday). What I need to do this is:
1. (Temporary) access (directly or indirectly, through pull req's) to a
`travis-support` GH repo.
2. A quick overview of what happened on this since the latest sprint from
apollo13.
3. Clear instructions on what the new approach will entail, what the goals
are and what the conditions are under which it will be committed.
Having Travis for Django still seems like a really good idea which could
significantly increase the (quality of) contributions. In any case, I'm
walking around on DjangoCon until friday afternoon. If you have questions
or want to work on me with this one, poke me. If you are a core dev and
want to discuss, poke me. If you're not a core dev, poke a core dev to get
this in (preferably before the sprints). Then, during the sprints, we'll
see quick enough whether Travis will prove to be a curse or a blessing but
I'm counting on the latter to be the case.
--
Ticket URL: <https://code.djangoproject.com/ticket/19891#comment:19>
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].
For more options, visit https://groups.google.com/groups/opt_out.
