This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See crosstool-NG for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
I forgot to give you the result build link: https://travis-ci.org/jmlemetayer/crosstool-ng/builds/80602525 2015-09-16 13:44 GMT+02:00 Jean-Marie Lemetayer <jeanmarie.lemetayer@gmail.com>: > Hi, > > I have made something proper in a new branch `travis_ci`. Here is the > new `.travis.yml`: > https://github.com/jmlemetayer/crosstool-ng/blob/travis_ci/.travis.yml > > The white-list stuff is commented because I am not developing in > master for now. It should be uncommented before to create the pull > request. > > I have selected only few samples. I think it is better to begin with > few of them, and after add other tested samples (much easier to have a > 'all green status'). > > I have add an `after_failure` handle to display the last 500 lines of > 'build.log'. Personally, I will decrease this to the last 200 lines. > > Bryan, regarding the two-part test. I think it might be a good idea to > split this into: > > 1. A quick build test with a small set of configured samples (or > maybe no samples at all) which could be handle automatically by > travis-ci on each commits / pull request. > 2. A manually trigger longer test with all samples (and maybe > other things to test all combinations) which can be handle by jenkins > or buildbot on private servers. > > Regards, > JML > > ps: I also have a server which can be used to do jenkins/buildbot > distributed builds. > https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds > http://buildbot.net > > 2015-09-16 1:21 GMT+02:00 Bryan Hundven <bryanhundven@gmail.com>: >> Jasmin, >> >> On Tue, Sep 15, 2015 at 3:46 PM, Jasmin J. <jasmin@anw.at> wrote: >>> Bryan, >>> >>>>> May I suggest, that you add a "cat .config" before the "./ct-ng build.2", >>>>> so that we can see what was really built. >>>> >>>> Technically, the .config is in the first 100-ish lines of the build.log >>>> Not sure that having it in the logs twice would be helpful. >>> when you look to >>> https://travis-ci.org/jmlemetayer/crosstool-ng/jobs/80447516 >>> there is no build.log printed and I guess it would be a lot, if we do this. >>> >>>> We also could add the various CT_LOG_* options to be able to be passed >>>> to ct-ng, so for instance you could do: >>>> >>>> ct-ng <sample> >>>> CT_LOG_DEBUG=y CT_LOG_LEVEL_MAX="DEBUG" ct-ng build.2 >>> I don't know how much lines this will be at the end. It is always a trade >>> off ... . >> >> one line of: >> >> export CT_blah_blah >> >> in kconfig.mk for each option. >> >>> What I have seen in the log is, that mostly the latest package versions are >>> used. I suggest to add some configs with preset gcc/binutils/... versions to >>> test older packages, too. >> >> Rather then confusing users with different samples using different >> versions, why not just create a separate git repository with the >> samples, then clone the test samples before running the test. Just a >> thought. >> >>> But keep in mind also, that travis-ci will try to build each commit on any >>> branch per default. Before we add travis-ci to master, we should add more >>> restrictions. >>> >>> One could be: >>> # whitelist >>> branches: >>> only: >>> - master >>> >>> To skip a build (from the docu page): >> >> Sure. >> >>> If you donât want to run a build for a particular commit, because all you are >>> changing is the README for example, add [ci skip] to the git commit message. >>> >>> Commits that have [ci skip] anywhere in the commit messages are ignored by >>> Travis CI. >>> >>> Pull Requests only: >>> Another solution might be restricting the build to Pull Request and do not >>> build Pushes. We need to check if that is usable. >>> >>> BR >>> Jasmin >> >> >> All very good info! :) >> >> I think the only downside to travis-ci is that while the build may be >> successful, the toolchain itself can still be totally useless. >> >> What I am looking at is a two part test. One part builds crosstool-ng. >> The second part runs the dejagnu gcc test-suite. The results from that >> test vary, depending on options used and target. >> >> When I researched travis-ci previously, it wasn't able to do this (it >> would take longer then there storage limitations and timeout >> restrictions. >> >> So I started looking at getting a server and setting up jenkins-ci, so >> that I can be in control of the test environment, and a much larger >> storage restriction and no timeouts for tests. (I mean obviously we >> would want to say that the test is dead if it took longer then X >> minutes/hours.) >> >> Just my 2cents... >> >> -Bryan -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |