Guys (and girls) I really need some help with the CI here. I am totally lost

[SpenceKonde]

I already have a huge to to list and everypme arpimd me is telling me I need to relax and then I tell them what I have to do and how far behind it is.;

Let me make this 100% clear:

Without working CI, ATTinyCore 2.0.0 will never be released and thje project will be dropped. Sorry - this project is too big to maintain without it. That means all the new features will never be released.

I am begging for help.

[bctstkla]

I really wish I had the expertise and was able to help, hopefully some else can. I just wanted to let you know that I tremendously appreciate everything you've done. Playing with the attiny's (that you made possible) has brought me much joy. Thank you.

[prandeamus]

I second this. It's a wonderful project but unfortunately I too have zero knowledge of github CI. Is there any forum where such people hang out, maybe?

[founfabug]

The project is fabulous. And huge. If the desired assistance is not forthcoming, consider reducing the scope of the project to only cover areas where dedicated testing and bug-reporting assistance is available. If this is manageable, and leaves sufficient value, the 2.0 project can continue with a more narrow scope. This can expand later if additional resources step in with the needed expertise.

Burnout is real, but more importantly, if it's not fun, it won't get done.

And thank you for your work, I have functioning devices that would otherwise still be in a box.

[hmeijdam]

I have no clue what the acronym "CI" stands for.

Do you need help with Critical Issues, a Capital Investment, Common Interface, Configuration Item, Counter Intelligence, Community Involvement, Code Inspection, Control Interface,

or just a Crazy Idea?

Maybe I can help you with that, even not understanding the question. If this starts to feel like work instead of a passion/hobby, I would suggest to mothball V2.0.0 for now. Don't throw it away, yet. Who knows in a week/month/year from now, something or someone changes making this hurdle go away. Take your time back. It's yours.

My 2 cents.

[prandeamus]

I assumed it was Continuous Integration.
https://docs.github.com/en/actions/automating-builds-and-tests/about-continuous-integration

[prandeamus]

Is it feasible to pick a subset of platforms, and focus on beta testing and delivery of ATTinyCore for those platforms only, with the others stated as alpha? My sense is that the design choices made are sound in themselves, but unfortunately have resulted in combinatorial explosion in a couple of areas.

To start the ball rolling: could we agree on 3 or 4 devices to support, get them into the field, and bring the others into the fold in a rolling program? After all 1.x is still out there so no one is completely out in the cold. x5 and x8 interest me personally but I'm surely not typical.

[designer2k2]

Hello,
(no CI expert here, new to this topic)

first thanks for this project, i used it so many times and want it to stay around for longer!

Could the way other projects handle it work also here?
By looking at DigistumpArduino it could be a close fit?

This workflow: https://github.com/ArminJo/DigistumpArduino/blob/master/.github/workflows/TestCompile.yml
Its compiling all examples inside the Arduino IDE using the latest core from the repo, while excluding some examples on purpose.
That sounds like a solid test to start with?

The other way around, testing a project using ATTinyCore works great. Im doing it here, maybe thats a help: https://github.com/designer2k2/BerlinUhr/blob/main/.github/workflows/main.yml

[designer2k2]

Yes i also see warnings as errors.

Some more progress, i defined the GPIO0 in the sketch and now there is one chip tested green 👍
https://github.com/designer2k2/ATTinyCore/actions/runs/3515327484/jobs/5890446812
ATTiny24 is good, not even a warning 😄

But all others have issues, for example ATtiny85 is missing "pins_arduino.h" see here: https://github.com/designer2k2/ATTinyCore/actions/runs/3515327484/jobs/5890448094

ATTiny26 has something wrong with the fqbn: https://github.com/designer2k2/ATTinyCore/actions/runs/3515327484/jobs/5890453276

Also there are quite some with issues around software serial, ATTiny84 for example: https://github.com/designer2k2/ATTinyCore/actions/runs/3515327484/jobs/5890446305

@SpenceKonde would you take a look on the output and give some priorities? Like you mentioned above the ones with build in UART, the 85 and 167?

Also for me its now not so clear where the errors are from, is it the 2.0.0 development or a wrong defined CI?

[designer2k2]

the ATtiny85 mentioned above now works, the folder´s seem to be case sensitive.

With this PR here #734 it gives 12 out of 36 fully working builds and many failing on just one or some examples.

@SpenceKonde How would you like to proceed from here?

[prandeamus]

I notice that some of the compilation failures are "just" warnings generated by #warnings directive

"This is the CLOCKWISE pin mapping - make sure you're using the pinout diagram with the pins in clockwise order."

Is it appropriate for CI tests to fail for the #warning? If you're adopting a "treat warnings as errors" approach, which many C/C++ programmers do, it might signal that the #warning directive isn't necessarily applicable here. It's thoughtful to remind users to pick the right pin mapping, but this directive might be causing more problems than it solves. There's no way that CI compilation can react in a meaningful way to this warning statement.

Compare to an error message like error: 'GPIO0' was not declared in this scope" which presumably is showing a genuine error that would be resolved by, say, rejigging #defines in source code.

(Just my two pennies' worth)

On reflection, I think a better choice here would be to use #pragma message, not #pragma warning. If the compiler options are sent to -WError then you'll never pass the compilation process. Maybe it's possible to tell gcc to have -WError and turn off the warning-to-error conversion for that specific pragma, but it seems like a lot more convenient to use message, not warning. @SpenceKonde opinions?

[SpenceKonde]

I agree with your assessment

Is the syntax for that just #pragma message "blah blah blah"?

The reason it's a warning is that I didn't know any other way to get the compiler to print messages that I really want the users to see (I don't know if it's been doing in current release, but next release will do what DxC and mTC do: When you specify "no warnings" in the preferences, we put our hands over our ears and start singing :-) (I do this because the Arduino IDE defauts to showing no warnings. Which is FUCKING PERVERSE and IDIOTIC, because 9 times out of 10 when a warning comes up via any method other than a #warning, it's a bug in your sketch, your sketch isn't going to work, and the IDE should bloody tell you that you're about to upload code that's probably broken when it knows it!!) (warnings from #warning are generally a lot less likely to be actual problems with this core, largely because when things were written, #warning was the only way i knew to make sure something would be printed when they were debugging, if this #pragma message thing will let me print messages, there are probably warnings in all three cores that should be changed. Because usually if my code is #warning you, it's because you're doing something dangerous, but quite possibly intended. There are very few cases of #warnings I issue on any of the three cores where the thing being #warned about is "probably" not intended, yet there is a possibility that it is (like builtin compiler warnings - if AVR-GCC were a table-saw, you would get a warning not an error before sawing your own arm off).

And the arduino IDE turns off the warnings, so you'd chop your arm off, and then find out there was a problem only when your found that the buttons pressed by the sawn off arm didn't seem to get pressed, and you'd then put in some print statements, and the return values would keep coming back all stained red. Finally it would dawn on you that you may have chopped your arm off, and you'd put in something like

if (arm) {Serial.println("Arm present before calling saw.cut()");} else {Serial.println("Arm not present before calling saw.cut()");}
saw.cut();
if (arm) {Serial.println("Arm present after calling saw.cut()");} else {Serial.println("Arm not present after calling saw.cut()");}

and get output of

Arm present before calling saw()
Arm not present after calling saw()

and realize you must be cutting your arm off.

And then you realize warnings are disabled, enable them, and see that the compiler was trying to warn you that you were passing a variable of type limb_t to saw.blade(), implying a deprecated (-fpermissive) conversion to lumber_t. Yes, that could be intentional, and the limb_t might not be from your own member variable limbs[] - maybe you're a murderer, and you're iterating over victim.limbs[], casting the values you get back to firewood_t so you can pass them to fireplace.burn() to dispose of the body, and your fireplace buffer isn't big enough to fit a whole person_t struct, but that's a corner case; usually the only objects of limb_t in scope are your own, while the murderer should explicitly cast the limbs he's severing to an appropriate type. Or really he should be using the bonesaw subclass of saw instead of tablesaw anyway, which was designed for this....

Anyway, yeah, if there is a way to turn those #warnings into a message that isn't a warning, that's like, much better.

[designer2k2]

I also cannot understand why warnings are off by default in the Arduino IDE :-(

yes its: #pragma message "this is a message"

The CI currently does not fail on warnings, here the attiny24 passes while getting the compiler warning about the clockwise pin mapping: https://github.com/SpenceKonde/ATTinyCore/actions/runs/3725743800/jobs/6318742687

[prandeamus]

I hear the frustrations about the Arduino environment and the way that warnings and messages are handled. It's a tricky one because a warning only has value after you set up a project or make a configuration change. (e.g. Are you sure you're using the clockwise pin mapping...?) However let's say that developer has read the warning, and "yup, I do want the clockwise pin mapping". The message is then redundant, having done its reminder job but the developer has to then condition him/herself to ignoring it. Which doesn't seem right. Also, if someone does want to enable -WError in future, it's going to screw the compile. So my vote is for #pragma message and some extra bold italic underscore in the documentation maybe?

[SpenceKonde]

I'm with you on this. How do I make a message other than a #warning???

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: ***@***.***

On Mon, Dec 19, 2022, 04:29 prandeamus ***@***.***> wrote: I hear the frustrations about the Arduino environment and the way that warnings and messages are handled. It's a tricky one because a warning only has value after you set up a project or make a configuration change. (e.g. Are you sure you're using the clockwise pin mapping...?) However let's say that developer has read the warning, and "yup, I do want the clockwise pin mapping". The message is then redundant, having done its reminder job but the developer has to then condition him/herself to ignoring it. Which doesn't seem right. Also, if someone does want to enable -WError in future, it's going to screw the compile. So my vote is for #pragma message and some extra bold italic underscore in the documentation maybe? — Reply to this email directly, view it on GitHub <#715 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW7Q6XS3TWDANLWWIDLWOATH7ANCNFSM56RGC2MA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[prandeamus]

Change #pragma warning foobar to #pragma message foobar, I believe

https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html

[prandeamus]

Oh $DEITY I must think before I post... Ignore the URL.

[SpenceKonde]

I do not have #pragma warning in the code, inhave #warning.

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: ***@***.***

On Mon, Dec 19, 2022, 09:42 prandeamus ***@***.***> wrote: Change *#pragma warning foobar* to *#pragma message foobar*, I believe https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html — Reply to this email directly, view it on GitHub <#715 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW6VA3MZLTQUHMWNYYTWOBX35ANCNFSM56RGC2MA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[prandeamus]

I think #warning and #pragma warning are equivalent(?)
So change #warning foobar to #pragma message foobar
?

[designer2k2]

here is a example with this #pragma message:
#pragma message "ESP32 based board, Pin 8"

https://github.com/designer2k2/xmas-tree/actions/runs/3529651216/jobs/5920854817