Making DevBuilds

This page is about making Build of the Day (BOTD) builds. Regular "DevBuilds" happen automatically for each commit and can be browsed here. BOTD builds are created by promoting a normal build to a BOTD status, but see the extra needed considerations below.

When to make a build

BOTDs are usually made once a week. If there is no progress since the last build, a new build should not be made. The builds are usually the responsibility of the programming team lead, but when not available some other programmer can do the build, but in that case any new PRs to be merged should have at least one other person accept them to ensure that no very major bugs or serious style problems are added to the BOTD.

Before considering making a build, any translations updates should be merged (a PR by the translations bot). If you have admin access to weblate you should first push all changes from there to ensure all the latest translations make it into the PR. Note that translations PRs must be merged normally! That is without squashing. If translation PRs are squashed weblate will get messed up and require admin access to the translations site to be able to solve that situation. This should really be avoided as it is a pain, especially if there are unmerged translations as those will need to be rescued from the translations site before force clearing it to ensure no intended translations get rolled back. So merge normally any translation update PRs to avoid problems (after approving them). If a translation update PR breaks line change format or is missing keys (this causes CI to fail), after merging the changes a new PR (or a direct commit to master) should be made where the only change is the running of the translations update tool. This should be merged immediately to not allow the broken translations commit to be latest in master for too long.

After translations PRs any small PRs that were waiting for additional verification can also be merged as long as there was some review on them (or they are by a senior programming team member).

Finally it is time to inspect the master branch commits to see if a new build can be made. Note that it can take tens of minutes for CI build backlog to clear and the latest master branch commit get an automated CI build. The steps for determining if it is time to make a build are as follows (this can be started while waiting for a build to finish):

1. Find the previous BOTD commit hash beginning from https://dev.revolutionarygamesstudio.com/builds
2. Find the commit in the commit history (for example online: https://github.com/Revolutionary-Games/Thrive/commits/master
3. Start drafting the build notes by writing a line or two of text about each commit after the last BOTD's commit
4. If there's nothing to put down in the notes (or just like one dependency library update or a singular "Updated translations" line) then that means not enough has happened to warrant a new build. So if there is no reason to make a build the following steps should not be done.

Putting out the build

Once it's been determined that there's enough changes to put out a build and the notes about what has changed since the last BOTD are collected, follow the next steps:

1. Look at the latest master branch commit hash and verify it is now on the builds page at https://dev.revolutionarygamesstudio.com/builds
2. Click on that build on the DevCenter and click the edit button on that page to start putting in the build nodes
3. Put the build notes in the edit field and break them up to lines (there's a check against too long lines to ensure the lines fit neatly everywhere they are displayed). Ensure you follow the right format regarding "-" (see the section on that later on this page). Hit save once done.
4. Now just check that everything seems fine, the build has the right hash, there's two sibling builds (Windows and Linux) for the build. All the changes are listed in the DevBuild description on the DevCenter
5. Finally press the button to make the build the "build of the day" on the bottom of the page
6. The build should change into BOTD status clearing out the old build and locking modification of the build info. The development discord bot should also post a notice about the new BOTD.

Then it is done. For good measure it is good to open the Thrive Launcher and try to play the latest BOTD to make sure it downloads the new build and shows the new build notes. Also testing that the BOTD build starts and doesn't run into immediate issues would be good, but it is very rare that the automated builds system has created a broken build.

Once a build is out a new post should be sent to the patrons to let them know. This needs different arrangements beforehand if no people with access to the Patreon page are available.

Build notes format

The build notes are written like the following:

- A thing that changed
- Change text that is too long for a single line
  that continues like this
- Updated translations

Note that translations update should always be notes as "- Updated translations"