Setting up CI

[darksylinc]

UPDATE:

• Setup all major branches and not just v2.2
• Building on MSVC 2015
• Building on Linux
• Testing Pull Requests are followed
• Building on macOS or iOS (probably hardest to setup, low priority)
• Running Unit Tests (not yet writtten)
• Deploying nightly builds

ORIGINAL:

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.

[Ybalrid]

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 master branch
I have set this up here for example : https://github.com/Edhebi/cpp-sdl2/commits/gh-pages We overwrite the last commit on that specific branch to put these files online : https://edhebi.github.io/cpp-sdl2/doc/

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

[yildiz-online]

It is also possible to cross-build linux-windows on travis if you want to have mingw64 builds
https://travis-ci.org/yildiz-online/component-native-ogre3d/builds/563964602

[Ybalrid]

mingw is not a recommended compiler for Ogre on Windows, but I don't see why we shouldn't test all the platforms we can anyway

[darksylinc]

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
This can miss a few build errors (when a file forgets to include a header) but it can also catch build errors that only show up when using unity builds.

[yildiz-online]

What is the goal of the CI?
-nighty build to check for regression?
-deploy and release a build version?
-compile changes commited by the dev?

Depending on the use case, it may or may not be necessary/desirable to speed up the build.

[Ybalrid]

@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? 😂), so nightly don't have the build speed issue.

Same goes for releases. Only the guy that publish the release cares if it takes ages to run...

[darksylinc]

Hi!

After countless tries, it lives!
https://ci.appveyor.com/project/MatiasNGoldberg/ogre-next

The build succeeds! (MSVC 2015 for now)

What is the goal of the CI?
-nighty build to check for regression?
-deploy and release a build version?
-compile changes commited by the dev?

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 current samples just need to be ran with a command line option that would make the following:

• Run the sample for N frames
• Capture M frames
• Optionally run a set of SDL scancodes provided from a file to test different things (e.g. prerecorded)
• Return non-zero on error
• Have a script watch these processes for timeouts, return codes, and later compare the pictures against groud-truth

The configuration file would look like the following:

{
	"tests" :
	{
		"Sample_PbsMaterials" :
		{
			"frame_length" : 50,
			"capture_frames" : [0,5,38],
			"recorded_input_stream" : "optional_binary_file_containing_recorded_keys.bin",
			"frames" :
			{
				"1" :
				{
					"keys" : ["F1",["CTRL","F2"],"PAGEUP"]
				},
				"2" :
				{
					"keys" : ["PAGEUP"]
				},
				"3" :
				{
					"keys" : ["PAGEUP"]
				}
			}
		}
	}
}

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.

Depending on the use case, it may or may not be necessary/desirable to speed up the build.

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.
Consuming != wasting.
If we have to consume that amount, then it's ok. But not taking the time to think it through to optimize our stuff makes my blood boil.

I will setup something similar for Travis-CI (same kind of freely usable service they have Linux and Mac images).

Yes, I see people use Travis for *nix builds. I noticed AppVeyor has Ubuntu images. Is this too recent? Are they useless? Just asking.

[darksylinc]

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 master branch

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.

[Ybalrid]

• GitHub pages : there are "user pages" and repo pages, so technically that could be hosted at "ogrecave.github.io/ogre-next/"

• AppVeyor's ubuntu : It is fairly new. I haven't tested it. Generally I turn to Travis for Linux and Mac since they have both. The fact that obviously part of the code is different for each OS (not even including shaders written in Metal that are only "built" when being loaded at runtime). Travis has the advantage of making it fairly simple to install a bunch of packages on the VM without even having to put the "sudo apt install" stuff in the pre-build commands makes it easy to setup.

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 so we can show the world we are the cool kids on the block you know

[darksylinc]

I already beat you to that ff7788d hehe.

I just pushed the master branch one, but I need to access AppVeyor to set that branch up

[darksylinc]

@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:
sudo apt-get install libfreetype6-dev libfreeimage-dev libzzip-dev libxrandr-dev libxaw7-dev freeglut3-dev libgl1-mesa-dev libglu1-mesa-dev

[Ybalrid]

@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 gh-pages branch here, and sure enough, this website is up :

https://ogrecave.github.io/ogre-next/

And is separated to this one (the ogre v1 repo)

https://ogrecave.github.io/ogre/

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 😉

[Ybalrid]

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 ninja package to the list of the build deps, as the scripts are using it instead of GNU make (good choice, I really like ninja, it is generally faster too 😉)

[paroj]

I also saw that you pushed a gh-pages branch here, and sure enough, this website is up :

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.

[Ybalrid]

Thanks @paroj, that's going to be useful! 😄

[darksylinc]

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.

[paroj]

@paroj you should've received an invitation request from ogre-next-buildbot

confirmed that yesterday

[darksylinc]

I see the confirmation for the Travis application, but unfortunately Travis still refuses because the bot user is still not "part" of the Organization i.e. it's not listed in https://github.com/orgs/OGRECave/people

[darksylinc]

OFFS Travis! How many times do I have to request authorization?

@paroj

[darksylinc]

I see you fixed it!
Thanks!!!

[DavidYKay]

Do you guys need a hand getting Travis to build OGRE 2.X for Linux?

It looks like Travis is already doing so, but the top of the issue indicates it's yet to be done. Let me know.