In my case (I want to use Marlin for a BTT SKR V1.4), I am supposed to start by executing the workflow for skr1p3 (MarlinBuilder/skr1p3.yml at main · V1EngineeringInc/MarlinBuilder · GitHub). However, I don’t understand how to execute this workflow in GitHub. Is there an explanation somewhere on how to run the workflow in GitHub?
Is there a good explanatory video that can help me understand the process?
In the end, thanks to the workflows, I already have an almost perfect version of Marlin, where I can make final adjustments in VS Code, right?
The workflows run by themselves once a day. So if you wanted a file those are all found in the actions tab, then you can unzip and edit that.
If you want to make a new board and add it to the list that we run every night, that is where the workflows come in. I am not super excited to add boards though so it needs to be a very common board. You can fork the repo and add anything you want to your own repo though.
Ok, I understand. So, if I want to have the latest version of Marlin for my MPCNC, I can download it from the workflows for my board and drivers. However, I also need to make specific changes in the code myself each time. For example, I have a different display that I need to adjust every time. There must be a smarter solution for this, right?
wouldn’t the smarter solution be to clone the repo and then in the workflow, have it update to the main repo it was cloned from and add your changes and rebuild? kind of like what he suggested earlier?
The smaller revisions of marlin happen every six months or so. The major revisions are way further apart.
I let people know if there are any CNC specific changes or tuning I change. In all honesty, there is nothing I see on the horizon to even think you need to worry about updating very often.
So you kinda need to decide how much work you want to do for once a year or 18 months when there is a tiny change that I feel is worth an upgrade.
As to why we run the nightlies…so we can help Marlin know when they nuke a board or CNC/laser config setting since they are printer focused.
I would not mess with the build products from the workflows. If marlin hasn’t released a new version of the firmware, then you don’t want it. Tracking the development version is just going to give you headaches.
What you should do (for yourself) is just download the closest source code from MarlinBuilder releases. Then make the couple of edits you need to make it work for you. In 6 month or a year or whatever, there may be a new version and if you felt like it, you could download the new version and make the same edits. 98% of the work is in building and testing the new version, so making sure you can auto apply the changes for yourself isn’t worth it.
If there were a lot of people with the same configuration, then someone can edit the workflows to create configs and releases for new configs. That would mean a new version of marlin would automatically generate a new build. But someone still needs to test it. If it breaks and it isn’t a core configuration, we’re just going to drop it.
For me, the topic of “programming” (adapting Marlin) is completely new. I thought it would be smartest for me to always be up to date with Marlin. But now I understand that the easiest way for me is to download a configured Marlin firmware version from the release page and adapt it. I was a bit confused by all the different versions of Marlin.
Thank you for your quick and good support. It really helps a lot!
Since the changes don’t happen very frequently, it’s easy to forget (between updates) what you changed or why. I strongly suggest adding a comment in your copy of the source code at the end of the line with a date and quick explanation. For example:
#define FAST_PWM_FAN ; enabled by TT on 5/24/23, see config.adv for additional settings
Now when you compare your version to the “new” version in a year and a half, you’ve got a reminder of what you changed, and maybe why.
If you want to learn git (which is separate from github), it is possible to track all changes in git as well. The whole git history is included with the source. Well, the correct git hash is included. The code was checked out with a depth of 1 to save on space.
But adding your name to any change is also a good move.
