Skip to content

Conversation

@Les-Wet
Copy link
Contributor

@Les-Wet Les-Wet commented Dec 23, 2025

As discussed in issue 17, simple CI/CD for the unbricked portion of the tutorial would be beneficial. This would also help maintain the target RGBDS and hardware.inc versions (see 125 and 131). This PR implements simple bash scripts for each "snapshot" of the unbricked project. A top-level build script is also provided to build all and report the success or failure of each build. The latter can be easily integrated into a GitHub workflow to make sure that the code in this portion of the tutorial is build-able.

@Les-Wet Les-Wet marked this pull request as draft December 23, 2025 13:33
@Les-Wet
Copy link
Contributor Author

Les-Wet commented Dec 23, 2025

Feedback on my approach would be much appreciated. The individual bash scripts are simple so that they can be consulted by someone just learning game boy assembly (easier than make). They are all identical scripts so we could restructure, but at the risk of the scripts being harder to find for those following the tutorial. hardware.inc is unfortunately harder to maintain with this file structure since it is copied into each sub-folder. Maybe we could make this into a symlink to the version we wish to target? I think it was decided submodules aren't a good idea for this project.

I have not implemented the .yaml file yet for the GitHub workflow. I will tackle that once I get some feedback, should be trivial with the script(s) already in place.

@avivace
Copy link
Member

avivace commented Dec 23, 2025

@Les-Wet is there a reason why this PR includes the work done by @wilkersonrdevon in #83 ? I thought #132 was supposed to continue the work on that

(I just want to be able to work on this without 'including' things we are discussing for in another PR)

@Les-Wet
Copy link
Contributor Author

Les-Wet commented Dec 24, 2025

Yes sorry. This was a result of forking @wilkersonrdevon 's repository. Realized later that his fork had his changes on his master branch as well. This resulted in his changes being present on this branch as well, and didn't realize it until I was testing his scripts. It also had the downside of not having the commits since his contributions, so I had to fast forward it.

Didn't realize until later that there is a much cleaner way to do this. It will require me closing the two PR's however since GitHub only allows one fork of a repository. I will have to fork the main repository instead of his and then merge his changes into a specific branch for commit [83])(#83) then proceed normally for this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants