We can change that to published, no problem.
I definitely would like to stick to one at a time. When the compositions get released, I was planning on reworking it so we have clear jobs for releases vs. nightlies vs. PRs. In those, I would like to choose which Marlin version makes sense for each. In the meantime, we could try to incorporate some context to try and automatically filter the matrix based on the trigger.
Re: EDIT: I don’t understand what you’re asking here.
Also, I did manage to fat finger it, and set the release to the wrong branch, and the jobs had kicked off before I realized it. So I deleted and remade the release. On the second set of jobs, they all had errors like, “Too many api calls”. So I reran them and they succeeded the second time.
It would be really cool if you didn’t have to edit any files to do a release. The src/core/version in repository will have a version set to something like: 431-unstable.
Release build will update that file to contain the git tag on the fly e.g. 431-rc1 or 431 once a final is released.
The other nitpick I was referring to was these lines MarlinBuilder/.github/workflows/archim.yml at main · jeffeb3/MarlinBuilder · GitHub which limit builds to pushes and PRs to just the “main” branch. I assumed you introduced these to stop useless tag builds when a release is created.
Now thinking more about it, maybe one shouldn’t edit this file at all. The build could in-principle automatically determine it using something like
ver=`git name-rev --tags --name-only $(git rev-parse HEAD)`
[ "$ver"x = "undefined"x ] && ver=XX-unstable # Means we're not on a tag
No. I introduced those so it didn’t run 10 builds at the same time. This was before the release trigger.
My thinking is that a PR into main would trigger a build, because otherwise, how would we know if it worked. And I always want the latest merged code to have a fresh test on main. I don’t really care about the rest. Are you having issues because your main is anttix-dev?
Yeah, that would be awesome. In this case, we aren’t talking about the Marlin version, but the V1 version. That would be really great. I can imagine naming the versions only the V1 version, and just putting in a comment, or leaving it in the zip name which marlin branch it came to.
I can easily imagine a situation where we want to RC or release v600, and most of the boards work fine in 2.1, but Ramps needs to stay back at 2.0.9, and having the release have a name independent of the Marlin version would be helpful in that case.
I feel like the tag name must be somewhere in the github.event.release struct.
Another alternative are the manual triggers, where you can define a specific variable, and that could also create the prerelease.
I’m willing to bet that ${{ github.event.release.tag_name }} works.
Dumb question: Why do we need to build with arduino given that platformio is perfectly capable of targeting 8bit AVRs? Is this because we want to test that it works and building in VSCode is more involved?
Perhaps we can update platformio.ini to include board specific defaults before zipping to make it so that compile and upload buttons in VSCode work when the project in unzipped.
That is how I do it for the builder, specifically because it will work right away for the end user.
Yes. I don’t have a good sense of what is easy or hard for beginners. But people seem less intimidated by arduino. More importantly, it has been working well for us.
Predicting the future is a fool’s errand, however given that most Marlin core developers seem to be using platformio these days, I’d not be surprised if it became perpetually broken from now on and they would eventually drop support for building with it altogether. It’s harder to target multiple toolchains especially in the embedded space.
I don’t have a windows machine at hand, I’m wondering if any1 has used this: https://github.com/zkemble/AVRDUDESS
Seems to be “alive” and maintained.
It would be nice to be able to just flash hexes. We definitely need good instructions for that. I wish there was a way to do it through a browser. I hate installing these one off apps.
Yeah, unfortunately COM port access is not really something browser vendors feel comfortable exposing without making people jump through all kinds of hoops …
Betaflight can flash an avr processor through usb.
Oh, but that is a chrome extension.
Does it still work? I recall google tightening screws on what extensions can do … and there’s a link below that seems to indicate it is indeed discontinued.
https://www.cnydrones.org/betaflight-configurator-no-longer-a-chrome-extension-where-to-get-it-now/
Took some exploration to figure out how to do inline if-s in workflows but here we go.
I have one more possible contribution. Changing what upstream branch is used based on what triggered the build.
This is probably temporary until we get workflow composition to work. Looks pretty ugly but not toooooo bad 
Those both look like good solutions to me. Thanks for those. I’m on my phone, but I can merge them later.
No worries. I’m not too sure about the second one, maybe it should just build bugfix-2.0.x for nightlies and stable (2.0.6) for everything else including PRs. That would not be as ugly code wise and I’m not sure how much value building PRs against next unstable actually brings.