Hi guys, I would like to contribute and add github actions to build the project, run tests (if any) and release the binaries if both the previous steps succeed.
My current plan is to create one on the master branch since is the only shared branch, but I would like to consider the introduction of a develop branch where all the code can get tested before ending up on the release branch (aka master).
The option of having a release branch also works ( Question on using "Git flow" ) as it’s the same process just with different branch names.
Let me know what you think and if it’s something you would consider as well as if I can start with this and have a card on https://open.codecks.io/unity-open-project-1 possibly under a new DevOps deck.
Whilst I like this idea, I think it’s too early in the development in order to setup any automated builds and unit tests. Once we pass the pre-production stage we can look in to this and see what’s possible
I also would love to work on Unit testing as this would help in speeding up the process of testing where any PR broke any functionality before merging.
@RunninglVlan That is one other advantage of automating the build early on.
I do like the idea there, but at the moment the whole project seems to be stuck at the template code and I can’t foresee any automation to be implemented anytime soon.
Now you’re speaking my language, @L4ZZA . My day job is building/testing server infrastructure with CI/CD pipelines, but I haven’t explored this with Unity or with any general game development process. This is really interesting and I would love to learn how this is applied to games, so I’m adding my comment here to follow.
It’s not too early for an automated process of building the Project. I would say it’s essential to have it as soon as possible since it will automate many small tasks which everyone should do before pull request but isn’t since it’s a open source project with many different levels of experience.
Just a simple build pipeline to confirm that noone breaks anything by adding some stuff is the least at this stage. A build which confirms that it can be built on Selected target and that it starts up properly. Far too many times have I’ve been involved with GameJams which we only ran the game in the Editor and then when Building it for real Nothing worked. Since then, that is one of the preperations which I make before entering a GameJam. Setup A CI flow for the project.
At this moment we’re having 18 pull requests waiting to get into master - having a basic build running would give us an indicator on which to prioritize.
Since @L4ZZA , @rcabreraortiz and @RunninglVlan seem to have some knowledge in this area maybe they could come up with basic editor script which we later on expand upon in order to have a first setup.
Pros for getting the CI / CD Started now:
Basic protection in the beginning for everyone to use
Common tasks are automated and can be run locally
Build Project with correct settings
Future Test Cases ( Not Unit Tests )
Game Levels
Gives Devs a local build before making pull request
Choose Test Cases to be run on Build
Historical Releases
Data can be generated in order see which areas should be supported
Instead of waiting for approval on small fixes we could maybe have an automated process?
Checks on small annoying stuff which is easy to forget
Linting (See that we are having right now)
Unity Version Handling
Art Asset checks - correct formatting and stuff
Cons for CI / CD
Someone to be responsible in the long term of the DevEnv
Data Storage handling - Logs etc.
Only using Actions may not be sufficient
Getting a Test Case up and running will also work as a semi-showcase in regard of how the project works.
