Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Setting up CI #21
Now that we're in Github, we could take advantage of CI integrations!
We have a few dedicated HW for CI, I'm trying to reach David Rogers who is managing those, to get access to these servers.
If we can't, then we'll just use whatever free cloud plans are available.
I'm particularly interested in CI that can follow Pull Requests.
I am willing to help with that. Since you merged #22, did you open an AppVeyor account and add this repo to your account? The rest should be automatic for having at least one windows build, even if it take an hour to run, it's still a starting point...
Once you create the AppVeyor project for this repo, it will pickup the appveyor.yml file in the root directory and use theses instructions.
Builds should appear on this URL https://ci.appveyor.com/project/darksylinc/ogre-next (darksylinc as the username on AppVeyor...).
I will setup something similar for Travis-CI (same kind of freely usable service they have Linux and Mac images).
You know that if you are willing to host the Doxygen documentation on GitHub pages on this repository, it's quite doable to also have a CI service push an updated generation of the HTML documentation at each successful build of the
To do that, an encrypted GitHub access token with the rights to the repo/the organization has to be stored on the Travis-CI side in an ENV var. This token is obviously not accessible for the pull request builds for obvious security reasons
It is also possible to cross-build linux-windows on travis if you want to have mingw64 builds
OK I've looked a bit into all this stuff.
I tried the on premise option but it is HELL to setup. I gave up. There's 0 documentation and many things don't make sense.
It would seem we'll need to cache the Dependencies. And maybe the CMakeCache.txt file to speed up CMake configuration.
Right now we're using build_ogre_Visual_Studio_14_2015_x64.bat which is wrong because it will clone from Mercurial repo, instead of building directly what Appveyor automatically cloned for us.
To speed up the compilation process, we may not really need to test both Debug & Release, just Debug could be enough (I'm sure I'm going to regret this one day...)
Another cmake option that can drastically speed up build time is -D OGRE_UNITY_BUILD=1
@DarkSlark The "just run that batch script" thing I did was just to test stuff. CI should probably take different steps than the "Okay, get me started using this thing on toolchain X" scripts does.
I also tried AppVeyor "on prem" on a Windows VM some time ago. It's horrendous, and we shouldn't use it.
If we have our own hardware, we can probably setup Jenkins + a windows build slave and we can execute the scripts we want and use the visual studio we want (you may still want to check compatibility of changes and pull requests against old versions. IIRC, you really want the code to be buildable with 08?) and run the tests we want.
I suppose (haven't checked, but 10 seconds of googling result in countless guides like that one) that the integration with GitHub will not be hard enough.
@yildiz-online I think we specially want here to compiles new commit pushed to development branches, and to build pull request. Maybe even execute some tests on them. For this, faster builds are desirable
Sure, for nightly builds we don't care if it takes 1 hour per versions. Nightly are supposed to occur when everybody's sleeping. (Too bad, the earth is wrong, and contributors are all over the globe right?
Same goes for releases. Only the guy that publish the release cares if it takes ages to run...
After countless tries, it lives!
The build succeeds! (MSVC 2015 for now)
The goal right now is to test the code builds. I regularly develop in Linux, I test on Windows but I sometimes forget.
But most importantly, to test Pull Requests. PRs should run in all 3 platforms we support, and our contributors usually just test their own platform.
Over time we could, and I want to, add unit tests. We have 80% of the infrastructure there.
The configuration file would look like the following:
Anyway, that's on my wishlist I guess.
I suppose deploying in the future nightly builds would be cool, but I'll left that to setup to someone else.
TBH the reason is that I'm an eco-friendly freak. I get an itch when we consume electricity for nearly an hour when the energy consumption could be reduced by 4x with a few smart tweaks.
Yes, I see people use Travis for *nix builds. I noticed AppVeyor has Ubuntu images. Is this too recent? Are they useless? Just asking.
AFAIK Github only allows one GH pages per user (in this case, 'OGRECave'), correct me if that's wrong or it has changed.
I talked about this a week ago, Pavel puts other stuff on gh-pages (aside from docs) and he's worried automation may break that.
I'm going to open a silly pull request that is obviously breaking the build, just to check that the thing is getting built, and that silly patches that aren't even working are red-flagged
also, I'm gonna add you that "build passing" sticker to README.md
@Ybalrid could you do the same you did with AppVeyor but with Travis?
It helped me save time, so I can just setup travis, and add a build script that works directly on the git repo instead of downloading from hg.
I'm used to Ubuntu 18.04 if that's an option. Some apt packages may be needed:
@darksylinc Sure! I will prepare Travis-CI on my fork and PR you the little configuration file, either later tonight or tomorrow morning (speaking CEST time)
For the setup thingy, Travis is a little bit different, it's a "GitHub app" you need to go add to your account. But the principle is the same (commit/pr trigger a webhook that start build, CI service parses file in root directory of repo, then spin up VMs according to configuration, then follow the scripts in that same file)
Thanks for pasting the dependency list!
I will point the build steps to install those and then execute one of these deploy scripts. Then you can spend less time goofing around the YAML syntax they stupidly use and just tweaking the build script so that it's the most efficient you can.
I also saw that you pushed a
And is separated to this one (the ogre v1 repo)
There are probably a few things we may want to edit on that website (like, having it mention ogre-next instead of Ogre, giving a link to v1 in case somebody landed there by mistake, adopt the new flat and classy banner logo and all that stuff)
I'm happy to contribute to that too
BTW, you can check the "pull request are followed" Item in your first post todolist, we know that #23 and #24 triggered a build for every single new commit pushed to my branches after the PR was submitted
Edit: working on Travis setup. We need to add the
that was me, so you can set-up whatever automation for docs you like. Also updated the references on ogre3d.org. The old location is still there for reference. However the v2.2 docs should go here.
I haven't forgotten about this, it's just Travis-CI won't recognize our repo from user ogre-next-buildbot even though that user is admin of the repo. Apparently Travis needs the user to be part of the organization that owns the repo.
@paroj you should've received an invitation request from ogre-next-buildbot to join OGRECave organization. If you haven't, then just add that user anyway.