Force maven to output color #873

mihnita · 2022-08-13T03:08:13Z

This is a minimal change, but to me it feels very brute force and ugly.

Is this the right way?
And do we want to expose some user preference so that they might disable it?
Maybe some users have some kind of automation monitoring the console looking for stuff, and this might break it.

@HannesWell
What do you think?

Thank you,
Mihai

laeubi · 2022-08-13T05:42:11Z

@mihnita as mentioned in the recent discussion, I think there should be a way for to programmatically query if a console will support ANSI colors, for example like this in the UI:

then M2E should query the flag and act accordingly to a new User setting drop-down:

HannesWell

Thank you @mihnita. That's a good location. 👍🏽

But as @laeubi said, we should not always add that flag. Otherwise, in case the coloring is disabled, we might see all the ANSI escape-sequences and we don't want that.

@laeubi do we really need that configurable? Simplify enabling that flag when the console is colored seems sufficient to me? I cannot imagine that one wants to see the escape-characters and having black-and-white Maven printout if console colors are enabled also seems irrelevant to me. And it would save us another preference.

Besides that I wonder if the VM arguments -Djansi.force=true and -Djansi.passthrough=true are necessary? At least the m2e-chromatic extension has it? Or is this obsolete with the integration into Eclipse?
https://github.com/sidespin/m2e-chromatic/blob/master/m2e.chromatic.core/src/main/java/io/sidespin/eclipse/m2e/chromatic/internal/ColoredMavenLaunchParticipant.java

Another thing we have to keep in mind is that the MavenConsoleLineTracker has to be adjusted to consider the ANSI escape-sequences when creating links to the project etc. I have done that a while ago already but back then coloring support was only possible with external plug-ins and we didn't want to provide support for external plug-ins.

It was #535. When reading through it, I just noticed you know that already. A lot has changed since then :D So I think I will revive that PR to address the handling of escaped printout in the Tracker. After this is done. But I wonder if there is now a better way to do what was done there. But lets discuss this there.

mihnita · 2022-08-13T20:12:40Z

Thank you @laeubi

Adding the Auto / Never / Always options is easy (working on it)

But there is a problem with the support per console.
Good or bad, my decision long ago was that the plugin will hook in all the consoles that extend StyledText.
So the enabled / disabled status is global, for all the consoles.

So right now I can't think of a way to query if a console supports ANSI colors or not.
This is something that might change for the next release (depending on what you, the Eclipse experts, think it is best).
But I don't see this happening for 2022-09, it is too much of a change too late in the game.

Some options for this feature (enable colors for maven output):

Drop it for now.

We do nothing for 2022-09. People can still define the parameter style.color=always as documented here
https://mihai-nita.net/2020/08/23/force-maven-colors-in-eclipse-console/

Pros: zero work, we don't shake the boat so close to a release, and we have time to get it right the next release.
Cons: people don't get colors in this release (unless they do some manual work)
It is the current status, without the need to explicitly install a plugin.

Have just the Always / Never option (no Auto)

Pros: not intrusive at all. Basically one UI widget + the current code + one if statement
Cons: if the ANSI processing is disabled and the (fixed) setting for Maven is "always" then one will see "junk" (the escape sequences). And if the ANSI processing is enabled and Maven is "never", then one will see no styled output (like today).

Add a way to programmatically query if a console ANSI processing is currently enabled or not (globally)

That way we can check the status and implement Auto.

Cons: the most work, close to a release.
I am not sure how to do inter-plugin communication to implement that programmatical query
And if the decision is to make that setting per console for the next release then we use a query that will be soon deprecated / removed.

I don't have a strong opinion, but I will go the option 2 and update this PR with that, to save time if we go in that direction.
And that is not throw away work no matter if the decision is 1 or 3 in the end.

HannesWell · 2022-08-13T20:31:32Z

Btw. did you manage to solve your problems with the m2e setup you mentioned in eclipse-platform/eclipse.platform.debug#50 (comment)?
At the moment it does not work out of the box because after the m2e-2.0 release the connector implementations have not yet been updated.
What usually helps is after provisioning your m2e workspace using the M2E Oomph setup to run a build. There are predefined launch-configs that should do the job. m2e-core -- build should do the job, but if you want to be really sure run the m2e-maven-runtime -- generate-OSGI-metadata before.

mihnita · 2022-08-13T21:56:04Z

Btw. did you manage to solve your problems with the m2e setup you mentioned

Yes, I did :-)
I've found this documented somewhere:

mvn generate-sources -f m2e-maven-runtime -Pgenerate-osgi-metadata -Dtycho.mode=maven

mihnita · 2022-08-13T21:58:29Z

Added 2 more commits (will squash after review)

One fixes two problems, one functionality and one i18n, 100% independent of this color work.
I recommend doing it no matter if we go with option 1.

The second one implemented option 2 proposed above.

This is the UI:

mihnita · 2022-08-13T21:59:22Z

I am looking into the build failures.
I suspect that some test is looking at the output and the escape sequences make the output different from what was expected.

mihnita · 2022-08-13T22:07:17Z

[ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:2.7.4:compare-version-with-baselines (check-no-version-regression) on project org.eclipse.m2e.launching: Only qualifier changed for (org.eclipse.m2e.launching/2.0.0.20220813-2151). Expected to have bigger x.y.z than what is available in baseline (2.0.0.20220705-1221) -> [Help 1]

HannesWell · 2022-08-13T22:21:17Z

I am looking into the build failures. I suspect that some test is looking at the output and the escape sequences make the output different from what was expected.

Yes probably something like in #535 has to be done. I'll look into it tomorrow it is late now where I live. :)

Besides that I wonder if the VM arguments -Djansi.force=true and -Djansi.passthrough=true are necessary? At least the m2e-chromatic extension has it? Or is this obsolete with the integration into Eclipse? https://github.com/sidespin/m2e-chromatic/blob/master/m2e.chromatic.core/src/main/java/io/sidespin/eclipse/m2e/chromatic/internal/ColoredMavenLaunchParticipant.java

Have you seen this question from me? Maybe it was list between the other ones.

github-actions · 2022-08-13T22:30:23Z

Unit Test Results

594 tests 586 ✔️ 9m 14s ⏱️
  93 suites     6 💤
  93 files     2 ❌

For more details on these failures, see this check.

Results for commit 19cba76.

♻️ This comment has been updated with latest results.

mihnita · 2022-08-14T05:03:23Z

The other failures are in m2e-core-tests, which is a git module.
Not sure how can I tie in a single PR the fixes in this repo with the ones in the other repo (the submodule).

But the patch would be something like this:

diff --git a/org.eclipse.m2e.tests/src/org/eclipse/m2e/tests/launch/MavenLaunchDelegateTest.java b/org.eclipse.m2e.tests/src/org/eclipse/m2e/tests/launch/MavenLaunchDelegateTest.java
index f34c527c..ce111c43 100644
--- a/org.eclipse.m2e.tests/src/org/eclipse/m2e/tests/launch/MavenLaunchDelegateTest.java
+++ b/org.eclipse.m2e.tests/src/org/eclipse/m2e/tests/launch/MavenLaunchDelegateTest.java
@@ -127,18 +127,20 @@ public class MavenLaunchDelegateTest {
     ILaunchConfiguration configuration = getLaunchConfiguration("projects/444262_settings");
     try {
       performDummyLaunch(configuration);
-      assertArrayEquals(new String[] {"-B"}, runner.getConfiguration().getProgramArguments());
+      assertArrayEquals(new String[] {"-B", "-Dstyle.color=always"},
+          runner.getConfiguration().getProgramArguments());
 
       // relative preference path to global settings is relative to eclipse home 
       mavenConfig.setGlobalSettingsFile("settings_empty.xml");
       performDummyLaunch(configuration);
-      assertArrayEquals(new String[] {"-B", "-gs", new File("settings_empty.xml").getAbsolutePath()},
+      assertArrayEquals(
+          new String[] {"-B", "-Dstyle.color=always", "-gs", new File("settings_empty.xml").getAbsolutePath()},
           runner.getConfiguration().getProgramArguments());
 
       // specifying -gs within goals overrides global settings from  configuration
       configuration.getAttributes().put(MavenLaunchConstants.ATTR_GOALS, "clean -gs other_settings.xml");
       performDummyLaunch(configuration);
-      assertArrayEquals(new String[] {"-B", "clean", "-gs", "other_settings.xml"},
+      assertArrayEquals(new String[] {"-B", "-Dstyle.color=always", "clean", "-gs", "other_settings.xml"},
           runner.getConfiguration().getProgramArguments());
 
     } finally {
@@ -153,12 +155,13 @@ public class MavenLaunchDelegateTest {
     try {
       mavenConfig.setUserSettingsFile(new File("settings_empty.xml").getAbsolutePath());
       performDummyLaunch(configuration);
-      assertArrayEquals(new String[] {"-B", "-s", mavenConfig.getUserSettingsFile()},
+      assertArrayEquals(new String[] {"-B", "-Dstyle.color=always", "-s", mavenConfig.getUserSettingsFile()},
           runner.getConfiguration().getProgramArguments());
 
       configuration.getAttributes().put(MavenLaunchConstants.ATTR_USER_SETTINGS, "settings.xml");
       performDummyLaunch(configuration);
-      assertArrayEquals(new String[] {"-B", "-s", "settings.xml"}, runner.getConfiguration().getProgramArguments());
+      assertArrayEquals(new String[] {"-B", "-Dstyle.color=always", "-s", "settings.xml"},
+          runner.getConfiguration().getProgramArguments());
     } finally {
       mavenConfig.setUserSettingsFile(null);
     }

mihnita · 2022-08-14T05:11:31Z

I've also looked at MavenConsoleLineTracker.java and yes, I can see how that can be a problem :-)

Warning: for a proper fix running with an external maven produces different results than the embedded one.

Embedded:

External

Every color change means one or more (hidden) ANSI sequences.

mihnita · 2022-08-14T05:15:46Z

And to confirm: -Djansi.force=true and -Djansi.passthrough=true are not needed.

laeubi · 2022-08-14T05:45:14Z

do we really need that configurable?

At least maven allows to configure that: https://issues.apache.org/jira/browse/MNG-6220 with the options -Dstyle.color=(auto|always|never) so it seems valid to replicate this.

I cannot imagine that one wants to see the escape-characters and having black-and-white Maven printout if console colors are enabled also seems irrelevant to me.

Who knows? At least users can't complain that we force them to see all these fancy colors :-)

But there is a problem with the support per console.
Good or bad, my decision long ago was that the plugin will hook in all the consoles that extend StyledText.
So the enabled / disabled status is global, for all the consoles.

I think it would be useful to adjust that, but that's just for the next release maybe but still something to keep in mind any maybe prepare right now.

So right now I can't think of a way to query if a console supports ANSI colors or not.

The ANIS-Console stores it somewhere, and m2e could read it from the "somewhere" until there is a better choice.

But the patch would be something like this:

I think unless we can know that ANSI is really enabled we should default to not enabling colours,

Beside that you can:

Fork the test repo
create a branch with a fix
Change the gitmodules file to point to your repo + branch

mihnita · 2022-08-14T17:58:12Z

The ANIS-Console stores it somewhere, and m2e could read it from the "somewhere" until there is a better choice.

It is stored in the preferences.
I considered the idea to read from there, but I dropped it.
Because I am reading some preferences from other plugins in my plugin, and noticed that (at times) they are not changed "real time". So my guess is that there is some kind of caching / delayed writing going on.

I'll give it a try though.

mihnita · 2022-08-14T19:34:27Z

Added support for auto, reading the preferences.

Disclaimer

I was unable to test the functionality end to end, as the Ansi support is in eclipse.platform.debug, which is not sync-ed in the m2e-core dev setup.

I started with a new installer and cloned both repos, but I was unable to build them together without errors.

So I did it "by pieces"

Took 2022-09 M2, updated org.eclipse.ui.console_3.11.300.*jar with one I built, enabled/disabled ansi and checked in what file that goes.
Tested the m2e-core functionality with the file above modified "by hand". The change is not reflected immediately, but if I restart Eclipse it works
I tested the "update live" part in a 2022-06 Eclipse, with the standalone ANSI plugin (the old one) and a very simple "spy" plugin. And checked that reading the prefs as I do it in this code reflects the change as it happens.

mihnita · 2022-08-14T23:27:32Z

I managed to get both m2e-core and eclipse.platform.debug to build together and to start an Eclipse session.
So I managed to test that things work properly all the

Combinations of auto/always/never
ANSI Support enabled / disabled
Embedded and External maven
Both with Run As -- Maven install (no options, defaults to Auto) and with a Run Configuration

I've also created a PR for m2e-core-tests (tesla/m2e-core-tests#180)
But since is a different PR than this one, the changes don't end up together in the same Jenkins session.
So the CI still fails.
That is the part that I am not sure how to handle, not git modules in general.

Thanks,
M.

HannesWell · 2022-08-14T23:29:56Z

Added support for auto, reading the preferences.

Disclaimer

I was unable to test the functionality end to end, as the Ansi support is in eclipse.platform.debug, which is not sync-ed in the m2e-core dev setup.

You can modify M2E's target platform to include the 4.25-I-builds repo that contain the master from the night of o.e.eclipse.debug.
Just go to m2e-target-platform/target-platform.target and replace https://download.eclipse.org/eclipse/updates/4.24/ by https://download.eclipse.org/eclipse/updates/4.25-I-builds/. Then just reload a few times, re-run the set up and a few restarts also might help until PDE really has reloaded the TP. This can be a bit messy some time...
But eventually you should be able to test this change with the latest o.e.debug version.

And to confirm: -Djansi.force=true and -Djansi.passthrough=true are not needed.

Thanks for confirming. But it looks like the org.fusesource.jansi:jansi is still required in the maven-runtime. To bad I hoped we could drop that because it causes extra effort in the build (the native libs are not Mac-signed). Do you know why this is still required? Or did I test it wrong?

I will have a look at the test on Thursday evening. Sorry for the delay but this weekend I wanted to complete a new feature for PDE that has to be completed until tomorrow evening.

HannesWell · 2022-08-14T23:42:30Z

I've also created a PR for m2e-core-tests (tesla/m2e-core-tests#180) But since is a different PR than this one, the changes don't end up together in the same Jenkins session. So the CI still fails. That is the part that I am not sure how to handle, not git modules in general.

you can update the .gitmodules file in the m2e-core repo to point to the PR branch of your fork, in this case this should be:

[submodule "m2e-core-tests"]
	path = m2e-core-tests
	url = https://github.com/mihnita/m2e-core-tests.git
	branch = master

Just push the updated file to this PR and Jenkins should pick that up.

HannesWell · 2022-08-14T23:44:22Z

I've also looked at MavenConsoleLineTracker.java and yes, I can see how that can be a problem :-)

Warning: for a proper fix running with an external maven produces different results than the embedded one.

Any idea why the coloring is different?

laeubi · 2022-08-15T05:01:50Z

Any idea why the coloring is different?

I think this can be investigated independent of this change but maybe:

different maven versions
different maven jars included
any OS specific things
different maven options?

laeubi

Some minor remark.

org.eclipse.m2e.core.ui.tests/src/org/eclipse/m2e/core/ui/tests/ConsoleTest.java

org.eclipse.m2e.launching/src/org/eclipse/m2e/internal/launch/MavenLaunchDelegate.java

org.eclipse.m2e.launching/src/org/eclipse/m2e/ui/internal/launch/MavenLaunchMainTab.java

org.eclipse.m2e.launching/src/org/eclipse/m2e/internal/launch/ColorOutput.java

mihnita · 2022-08-15T08:22:58Z

But it looks like the org.fusesource.jansi:jansi is still required in the maven-runtime

From all I know, jansi does a couple of things:

Gives one a friendly way to use ANSI sequences. Using red() and bold() instead of "\033[31m" and "\033[1m"
Converts the ANSI escapes to calls to SetConsoleTextAttribute and other native Windows APIs, as the old cmd.exe does not support ANSI
Wrapping native APIs to detect if the output goes to a terminal or is a redirect (isatty)
Depending on the detected environment, call Windows Console APIs, pass-through the ANSI escapes "as is", or remove them (if the output redirects to a file)

Functionality 2 and 3 require native code.

This documents what jansi.passthrough, jansi.strip, and jansi.force do
https://fusesource.github.io/jansi/documentation/api/org/fusesource/jansi/AnsiConsole.html#wrapPrintStream-java.io.PrintStream-int-

I don't know how Maven uses jansi.
It might be that they use it to do the "auto" part (which is calling isatty, so requires the native code)
And it might be that not calling it with style.color=auto might not need the native code at all.

laeubi

Looks good 👍

mihnita · 2022-08-15T09:11:23Z

Any idea why the coloring is different?

Not really...
I can do some digging.

laeubi · 2022-08-15T09:12:28Z

Any idea why the coloring is different?

Not really... I can do some digging.

I think we should first finish this PR so not mixing too much concerns :-)

mihnita · 2022-08-15T09:43:07Z

Sorry, I don't manage to make the m2e-core-tests end up in this PR.
Here is a PR to tesla/m2e-core-tests: tesla/m2e-core-tests#182

mihnita · 2022-08-15T09:43:34Z

I think we should first finish this PR so not mixing too much concerns :-)

Agree :-)

mihnita · 2022-08-15T22:56:06Z

@HannesWell

I'm trying to go through the blockers for this PR.

GitHub complains about unaddressed change request.

When I click "See review" it takes me to this comment:
#873 (review)

Thank you @mihnita. That's a good location. 👍🏽

But as @laeubi said, we should not always add that flag. Otherwise, in case the coloring is disabled, we might see all the ANSI escape-sequences and we don't want that.

...
It was #535. When reading through it, I just noticed you know that already. A lot has changed since then :D So I think I will revive that PR to address the handling of escaped printout in the Tracker. After this is done. But I wonder if there is now a better way to do what was done there. But lets discuss this there.

I think it rises a few items:

not always add that flag. Auto. Configurable.
=> I think this was addressed
I wonder if the VM arguments -Djansi.force=true and -Djansi.passthrough=true are necessary?
=> Answered, I think they are not needed. I can test on Win, Linux, MacOS if needed
the MavenConsoleLineTracker has to be adjusted to consider the ANSI escape-sequences
=> 100%. But should it be in this PR?

And the fixes for the test failures in m2e-core-tests, which I can't seem to make them part of this PR.
I've created a PR here: tesla/m2e-core-tests#182

So maybe you can just merge them "almost at the same time?" :-)

Or clone my 2 PRs and create one, as you seem to know how, but I don't manage to do.

Last: where can I update the help?
Probably a screenshot, and the description of the new option?
Is there such a thing? I couldn't find one.

Not blocker for this PR, but needs to be done.

Thanks,
Mihai

HannesWell

Thank you @mihnita, yes all previous remarks are addressed or should/can be addressed separately.

I did a deeper review and found one point that probably has to be corrected. See the attached review.
I also looked into to tests and tried them. They look good. 👍🏽 I will submit them close before this PR is about to be submitted.

Can you also please squash the changes of this PR into two commits:

Changed threads label-commit just as it is (you can use git's interactive rebase to reorder commits)
All the changes for the coloring support squashed into one with an message+description that covers the commit as a whole (e.g. version bumps don't have to be mentioned in the squashed commit message).

org.eclipse.m2e.launching/src/org/eclipse/m2e/internal/launch/MavenLaunchDelegate.java

mihnita · 2022-08-17T02:21:54Z

I've explained why preferencesService.getBoolean(... false ...) would not work.

If you agree with that, then the commits are merged and ready to submit.

If you have an idea how to handle that, then I'm listening :-)

My ideas:

Some kind of tri-state, or another flag saying "ANSI is installed", but that means the ANSI part should run at least once for this to work.
Improve isAnsiProcessingEnabled() to do something like this:

private boolean isAnsiProcessingEnabled() {
    if (isAnsiSupportInstalled()) {
        return false; // ansi support not present
    } else {
        return preferencesService.getBoolean(ANSI_SUPPORT_QUALIFIER, ANSI_SUPPORT_KEY, true, null);
    } else {
}

And isAnsiSupportInstalled() would use some "trick" to detect the ANSI functionality.
I need to check what. Maybe Platform.getExtensionRegistry() and scan the extensions?

Thanks,
Mihai

mihnita · 2022-08-17T03:58:33Z

OK, I can't find a way to detect ANSI support.
It is now part of org.eclipse.ui.console, and it is internal.

But org.eclipse.m2e.core.ui requires the org.eclipse.ui.console bundle (bundle-version="3.4.0")
The ANSI support is present since 3.11.300.

I've tried, and something like this would work:

boolean isAnsiConsoleInstalled() {
    Bundle consoleBundle = Platform.getBundle("org.eclipse.ui.console");
    if (consoleBundle == null) {
        return false
    } else {
        Version ver = consoleBundle1.getVersion();
        Version ansiVer = new Version(3, 11, 300, "v20220624-0445");
        return ansiVer.compareTo(ver) >= 0;
    }
}

Would need to only do it once and cache the result, and the documentation for Platform.getBundle says it is slow.
And recommends FrameworkUtil.getBundle, which takes a class from the bundle, not a name.
Faster, but introduces a direct dependency.

What do you think?
M.

laeubi · 2022-08-17T04:39:16Z

What do you think?

I think that looks like a very good "hack" to the current problem and the performance penalty is really something we can ignore here. We do not expect user to fire up maven builds in the range of thousands or more withing seconds ...

With UI to make color output optional and with support for `auto / always / never` (auto : color if ANSI is enabled)

mihnita · 2022-08-17T05:56:29Z

Added isAnsiSupportInstalled(), line 346 of MavenLaunchDelegate.java

It is almost 100% what I described before, but added a workaround for the case when one is developing and the qualifier of org.eclipse.ui.console is "qualifier". That only makes a difference if the version is 3.11.300.qualifier, otherwise compareTo does not even get to the qualifier part.
Should be very rare. But it affected me :-), so it is not impossible that others might also be affected.

HannesWell

Added isAnsiSupportInstalled(), line 346 of MavenLaunchDelegate.java

It is almost 100% what I described before, but added a workaround for the case when one is developing and the qualifier of org.eclipse.ui.console is "qualifier". That only makes a difference if the version is 3.11.300.qualifier, otherwise compareTo does not even get to the qualifier part. Should be very rare. But it affected me :-), so it is not impossible that others might also be affected.

Agree that this is looks good for now. Platform.getBundle(String) is not the fastest thing on earth but also not the slowest and given that it is only called once per launch nobody will notice it.

However I consider to build M2E against the 4.25-I-builds soon (maybe even this evening). Then we could simply lift the minimum required version of the console bundle and just remove that 'hack. Because as you asked, I don't think it is possible to install M2E without it being present.

If we release M2E before the Eclipse 2022-09 release then it is definitely targeted for that release so that should be fine to have requirements on that. Maybe we even have some more connectors adapted to M2E 2.0, but that is another story.

I have merged to adjustments of the m2e-core-tests and started a fresh build that should automatically pick them up. If that is green, this is ready to go.

Thanks again, @mihnita!

HannesWell · 2022-08-17T07:36:14Z

Jenkins Build is green (GH-build does not automatically fetch the latest submodule master and therefore fails, but that's ok).

So this is ready. Thank you @mihnita, great work!

HannesWell requested changes Aug 13, 2022

View reviewed changes

laeubi reviewed Aug 15, 2022

View reviewed changes

org.eclipse.m2e.launching/src/org/eclipse/m2e/internal/launch/ColorOutput.java Outdated Show resolved Hide resolved

laeubi approved these changes Aug 15, 2022

View reviewed changes

mihnita requested a review from HannesWell August 15, 2022 22:43

HannesWell requested changes Aug 16, 2022

View reviewed changes

org.eclipse.m2e.launching/src/org/eclipse/m2e/internal/launch/MavenLaunchDelegate.java Show resolved Hide resolved

org.eclipse.m2e.launching/src/org/eclipse/m2e/internal/launch/MavenLaunchDelegate.java Outdated Show resolved Hide resolved

Force maven to output color

19cba76

With UI to make color output optional and with support for `auto / always / never` (auto : color if ANSI is enabled)

HannesWell approved these changes Aug 17, 2022

View reviewed changes

HannesWell mentioned this pull request Aug 17, 2022

Adapt MavenLaunchDelegateTest to not yet present console coloring tesla/m2e-core-tests#183

Merged

HannesWell merged commit 4bb08d3 into eclipse-m2e:master Aug 17, 2022

HannesWell mentioned this pull request Aug 17, 2022

[Console] Support content detection for ANSI-escaped console text #535

Merged

HannesWell added this to the 2.0.0 milestone Oct 22, 2022

Force maven to output color #873

Force maven to output color #873

Conversation

mihnita commented Aug 13, 2022

laeubi commented Aug 13, 2022

HannesWell left a comment

Choose a reason for hiding this comment

mihnita commented Aug 13, 2022

HannesWell commented Aug 13, 2022

mihnita commented Aug 13, 2022

mihnita commented Aug 13, 2022 • edited Loading

mihnita commented Aug 13, 2022

mihnita commented Aug 13, 2022

HannesWell commented Aug 13, 2022

github-actions bot commented Aug 13, 2022 • edited Loading

Unit Test Results

mihnita commented Aug 14, 2022

mihnita commented Aug 14, 2022 • edited Loading

mihnita commented Aug 14, 2022

laeubi commented Aug 14, 2022

mihnita commented Aug 14, 2022

mihnita commented Aug 14, 2022

mihnita commented Aug 14, 2022

HannesWell commented Aug 14, 2022 • edited Loading

HannesWell commented Aug 14, 2022

HannesWell commented Aug 14, 2022

laeubi commented Aug 15, 2022

laeubi left a comment

Choose a reason for hiding this comment

mihnita commented Aug 15, 2022

laeubi left a comment

Choose a reason for hiding this comment

mihnita commented Aug 15, 2022

laeubi commented Aug 15, 2022

mihnita commented Aug 15, 2022

mihnita commented Aug 15, 2022

mihnita commented Aug 15, 2022

HannesWell left a comment • edited Loading

Choose a reason for hiding this comment

mihnita commented Aug 17, 2022

mihnita commented Aug 17, 2022

laeubi commented Aug 17, 2022

mihnita commented Aug 17, 2022

HannesWell left a comment

Choose a reason for hiding this comment

HannesWell commented Aug 17, 2022

mihnita commented Aug 13, 2022 •

edited

Loading

github-actions bot commented Aug 13, 2022 •

edited

Loading

mihnita commented Aug 14, 2022 •

edited

Loading

HannesWell commented Aug 14, 2022 •

edited

Loading

HannesWell left a comment •

edited

Loading