[builder]: fix release mode

arturo-lang / arturo

Simple, expressive & portable programming language for efficient scripting

http://arturo-lang.io

MIT License

703 stars 32 forks source link

[builder]: fix release mode #1581

Closed RickBarretto closed 6 months ago

RickBarretto commented 7 months ago

We need to check why this is breaking things

Type of change

[ ] Code cleanup
[ ] Unit tests (added or updated unit-tests)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (implementation update, or general performance enhancements)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation (documentation-related additions)

drkameleon commented 7 months ago

That's very weird to be honest...

We had --define:NOERRORLINES for release builds?!

I mean - if I'm not mistaken - release builds are meant to be the ones created by the release workflows (when we make a release on GitHub) + NOERRORLINES means... suppress all error lines (which was there - supposedly again lol - only for the now-obsolete "packaging" functionality).

I don't get it... I'll have to investigate a bit more ;)

RickBarretto commented 7 months ago

NOERRORLINES means... suppress all error lines (which was there - supposedly again lol - only for the now-obsolete "packaging" functionality).

Ohhh, that explains a lot! So this was my mistake, sorry.

As I explained on the server, those are the flags we pass to the compiler when releasing:

https://github.com/arturo-lang/arturo/blob/master/.config/who.nims#L4-L13

drkameleon commented 7 months ago

A good point out of all this is that we have to find a viable way to make sure that our release workflow works fine (that is triggered only when we push a new tag/release, and "releases" the new version)... but without the need to push a new tag.

I mean... I've literally been thinking that when we actually release the new version, I have no idea if the corresponding workflow works. But it would obviously be far better to know ahead of time, whether it does work or not I mean...

Any ideas? 😉

RickBarretto commented 7 months ago

Any ideas? 😉

I'll investigate it better. There should be any way to put some trigger as pre-requirement before do some actions on Github.

I've been thinking about it due to .skip and partial tests. I have to think and investigate it better.

But that would be great:

Only run tests when code have been changed (documentation not included)
Only run full suite-tests right before merge
- Merge requires a full-suite test have been run
Run release tests at least once a month
Releases requires full-suite release-test being run right before

Let's see if I find something...

drkameleon commented 6 months ago

Ready to merge! 🚀