-
Notifications
You must be signed in to change notification settings - Fork 10
Build Pipeline
Our new build pipeline is powered by GitHub Actions.
This project's purpose is delivering custom engine builds with a pre-defined schedule.
Our build configurations currently consists of Win64 & Linux builds seperately.
- Synchronize our current active branch with changes from upstream branch of Epic, and push automated merge commit.
- Fetch 3rd Party dependencies and required binary files with Epic's GitDependencies tool.
- Generate VS solution, check if it's getting generated without any problem
- Execute Installed Build BuildGraph command, and wait until this long build job finishes, which also packages and submits to GCS.
This pipeline is triggered per week, on the Friday nights when Epic finishes their weekly work on the engine source code.
This project's purpose is reducing workload of programming team by automating as much as possible number of jobs.
This build configuration is one of the vital parts for future of our development. It does a regular build check, and additional C++ static code analysis powered by Jetbrains's Resharper InspectCode tool. With each commit on the repository, this build will be triggered, and run the steps defined below
This build configuration also includes pull requests.
The purpose of this build configuration is automating synchronization between main branches, and doing proper versioning with proper changelogs.
This synchronization process is dictated by our Release Procedure.
This pipeline works with the schedule explained in our release procedure wiki page. If any kind of conflict happens, they will be resolved manually by programming team leads. After end of the merge, a tag with minor version update will be created, and the automatically generated changelog from merge messages will be pushed into Discord #release-notes channel & Discourse automatically with help of their APIs.
This pipeline works with the schedule explained in our release procedure wiki page. If any kind of conflict happens, they will be resolved manually by programming team leads. After end of the merge, a tag with major version update will be created, and the automatically generated changelog from merge messages will be pushed into Discord #release-notes channel & Discourse automatically with help of their APIs.
This pipeline works with the schedule explained in our release procedure wiki page. If any kind of conflict happens, they will be resolved manually by programming team leads. After end of the merge, a tag with release version update will be created, and the automatically generated changelog from merge messages will be pushed into Discord #release-notes channel & Discourse automatically with help of their APIs.
After this merge & version release, Actions will trigger a playable public game build job, tagged with the same release version in the repository.
With not having a place on versioning procedure, purpose of this automated merge is keeping the versioning pipeline updated with changes from creative team. There won't be any scheduling for this job, and will be manually triggered when programming team needs new additions in promoted branch.
This merge pipeline is used to update the trunk branch with the latest changes coming into main, through a promoted merge or feature branch merges.
This pipeline's purpose is generating a public API documentation to be used as a reference while programming.
This generates documentation on every promoted code change.
This pipeline is triggered after a merge to stable, and uses PBSync to interact with Dispatch, the command line interface for the Discord store, uploading a DRM protected build to Discord.
For internal playable builds, this is triggered after a change to promoted,
to continously test art changes and reflect the current state of the game build
to the entire team.