Rather than reviving this dead topic I am starting fresh here.
It has been sitting on my todo list since December, and I finally got around to poking at this automatic builder again.
@anttix, I couldn’t fork your repo, because you forked it from Marlin, and I already have a fork for Marlin. I also wanted to do it a little differently, but with a similar goal at the end. The major difference is that I don’t commit Marlin to my repo at all. I just check it out in the workflow, configure it, build it, save the firmware file, and zip the Marlin folder and save the zip. I pick which branches to build against manually in the matrix, which is currently set to 2.0.5.4 and bugfix-2.0.x.
I have been playing with it for about a week for an hour here or there. It seems to be working pretty well. There are a few hiccups, but it’s generally cranking.
There’s no guarantee this will end up being the defacto configuration tool for Ryan’s firmware. It is a lot harder to tinker with one firmware at a time, but it also does keep the multitude of configurations a bit more consistent.
I still need a good way to provide the artifacts, especially ones that have been “released”. I am wondering if it is worthwhile to make a simple js tool to lead users to the right firmware version. There is an endless amount of automation this opens up if we let it.
Maybe someone knows this. I’d like to be able to make each board it’s own workflow, without having the same text copy/pasted in each file. Is there a way to include another workflow file? I am half tempted to create a workflow file that generates more workflows.
The last one will stick. We are using the marlin scripts for changing the options. We could write our own and add in some features to error check. I think we only use 3 major scripts. Set option, enable, and disable. So it wouldn’t be a huge task.
I’m going to poke again at the archim configurations with this arduino package. It might be nice to actually have it build the other configurations in arduino too, if they can, to make sure that isn’t broken.
In file included from Marlin/src/module/../inc/../HAL/./DUE/HAL.h:35:0,
from Marlin/src/module/../inc/../HAL/HAL.h:26,
from Marlin/src/module/../inc/MarlinConfig.h:30,
from Marlin/src/module/stepper.h:44,
from Marlin/src/module/stepper.cpp:80:
Marlin/src/module/stepper.cpp: In static member function 'static void Stepper::set_directions()':
Marlin/src/module/../inc/../HAL/./DUE/fastio.h:69:25: error: 'DIO107_WPORT' was not declared in this scope
volatile Pio* port = (DIO ## IO ## _WPORT); \
^
Marlin/src/module/../inc/../HAL/./DUE/fastio.h:157:30: note: in expansion of macro '_WRITE'
#define WRITE(IO,V) _WRITE(IO,V)
^~~~~~
Marlin/src/module/stepper/indirection.h:92:30: note: in expansion of macro 'WRITE'
#define Z_DIR_WRITE(STATE) WRITE(Z_DIR_PIN,STATE)
^~~~~
Marlin/src/module/stepper.cpp:393:28: note: in expansion of macro 'Z_DIR_WRITE'
#define Z_APPLY_DIR(v,Q) Z_DIR_WRITE(v)
^~~~~~~~~~~
Marlin/src/module/stepper.cpp:445:7: note: in expansion of macro 'Z_APPLY_DIR'
A##_APPLY_DIR(INVERT_##A##_DIR, false); \
^
Marlin/src/module/stepper.cpp:462:5: note: in expansion of macro 'SET_STEP_DIR'
SET_STEP_DIR(Z); // C
^~~~~~~~~~~~
Marlin/src/module/../inc/../HAL/./DUE/fastio.h:69:25: note: suggested alternative: 'DIO10_WPORT'
volatile Pio* port = (DIO ## IO ## _WPORT); \
^
Marlin/src/module/../inc/../HAL/./DUE/fastio.h:157:30: note: in expansion of macro '_WRITE'
#define WRITE(IO,V) _WRITE(IO,V)
^~~~~~
Marlin/src/module/stepper/indirection.h:92:30: note: in expansion of macro 'WRITE'
#define Z_DIR_WRITE(STATE) WRITE(Z_DIR_PIN,STATE)
^~~~~
Marlin/src/module/stepper.cpp:393:28: note: in expansion of macro 'Z_DIR_WRITE'
#define Z_APPLY_DIR(v,Q) Z_DIR_WRITE(v)
^~~~~~~~~~~
Marlin/src/module/stepper.cpp:445:7: note: in expansion of macro 'Z_APPLY_DIR'
A##_APPLY_DIR(INVERT_##A##_DIR, false); \
^
Marlin/src/module/stepper.cpp:462:5: note: in expansion of macro 'SET_STEP_DIR'
SET_STEP_DIR(Z); // C
^~~~~~~~~~~~
Marlin/src/module/../inc/../HAL/./DUE/fastio.h:70:30: error: 'DIO107_PIN' was not declared in this scope
The environment was not set to what I have, DUE_archim. For whatever reason I could not figure out how to change all the configs or add a file change (using github.com) so I just tested one.
Something is funky about these builders. I split them up to try arduino, and I don’t have archim in the platformio build anymore, so it didn’t test your change. But then, your change isn’t on my branch. So I did something wrong.
Right. I think 2.0.6 is imminent, but because something with the stm32 builder broke after 2.0.5.3 was released, they opted to freeze the version of the stm32 stuff to something in the past, to make 2.0.5.4 work.
This is taking a really long time. So one thing I’d like to do is break this into smaller workflows, and then filter them on the files involved, so we aren’t building the skr again when we change the archim build settings. It will also leave us with nicer notifications, I hope. Something like “Archim workflow is failing” instead of “everything is failing”.
Oh man. I thought I was going crazy for a minute. I was diving deep down. But it turns out, the arduino builder is working, and bugfix-2.0.x is broken on the archim builds with arduino. I tried building it myself, and it broke.
