-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use GitHub actions #290
base: develop
Are you sure you want to change the base?
Use GitHub actions #290
Conversation
I'll have to look over that in more detail in the near future but definitely looks nice. I don't think the build failure part is all that useful, given we're talking Python and there isn't any real compiling going on and there isn't enough typing information in Gremlin's code yet to use it to catch issues. Though getting a sort of nightly builds is probably the most valuable part of this. In that way getting potential fixes in and easily tested without me having to spin up a VM and package everything will make development in that regards much easier. There is also a chance that I may start using https://build-system.fman.io/ to build and package Gremlin. The main reason is that this supposedly does all the annoying stuff to create an installer. The hope is that the installer this results in has fewer bugs than the current one. There are a few issues with the current one I haven't gotten to fixing and if this other tool fixes them it might be worth swapping. Though I haven't looked at this yet. |
I'm not sure if it's visible to everyone, but the build that fires off on push does upload the installer as an artifact to the action run. That would give you the 'nightly builds' effect you're looking for. Alternately, I believe you can set these things to run on a schedule. Perhaps get it to only make a build if there's been a commit since the last one. If I get the time and you're interested, I could see about changing this process to do scheduled and release builds instead of push and release. I had a glance at fbs, as an aside. Got to say it doesn't sound super impressive on their front page. Handy yes, but you already have a better solution to what they say they're doing (WiX is more pain to set up but produces a better result than NSIS, IMO). Could be there's more under the hood than their claim on the page, of course. |
As an experiment I decided to see if I could set up the Joystick Gremlin build process using GitHub Actions CI/CD. Current config is set to build the exe and installer on every push except creation of releases, the idea being if a commit causes the build to fail you'll know about it. It does the same and attaches the resulting MSI file to the release when a release is published, saving the effort of having to do that manually.
The process takes about 3 minutes on average, and free accounts get 2000 minutes of Actions per month, so if you're not using them for anything else you could do over 600 commits a month and not run out.
Could be further tuned to taste. E.g. could make it so it only does a full build when committing to master (or develop in this case?)
This was an educational exercise for me, so if you don't want to make use of it, that's fine.
As an aside, I made a change to generate_wxs.py to handle filenames with + in them, since for some reason all even building with python 3.5 -- which is the earliest GitHub Actions supports -- would end up pulling in tcl/tk.