My issues were all on master. I've always been able to work on release-2.x in IntelliJ or Eclipse without any issue.
I'll have to check out master and see if it works now. I have it on the back burner to try to figure out an improved status logger life cycle. On Thu, Dec 23, 2021 at 9:34 AM Carter Kozak <cko...@ckozak.net> wrote: > I haven't had a test flake locally in the last 6 months (at least), if we > see flaky tests I'm in favor of fixing them rather than working around them. > > fwiw the non GitHub-actions tests work great on the release-2.x branch in > my experience, when they aren't overwhelmed accessing build nodes anyhow. > That said, I would prefer to get everything workin on GitHub actions as it > seems to be the gold standard these days. > > > Last time I tried I couldn't get the mainline code to load in IntelliJ > or Eclipse because of the packing changes that were in progress. > > I find release-2.x works nicely with IntelliJ idea when I set the > project-level sdk to jdk8. the master branch may be another story. I have > an INFRA ticket open to switch the default branch to reduce confusion: > https://issues.apache.org/jira/browse/INFRA-22641 > > -ck > > On Thu, Dec 23, 2021, at 12:25, Tim Perry wrote: > > Is it worth marching those tests with @Ignore and filing a Jira for each > > one? That does seem to set a bad precedent though. > > > > Last time I tried I couldn't get the mainline code to load in IntelliJ or > > Eclipse because of the packing changes that were in progress. Did that > get > > fixed? If so, I might be able to carve out some time to look at a couple > > tests if you point me in the right direction. > > > > Tim > > > > On Thu, Dec 23, 2021 at 7:24 AM Volkan Yazıcı <vol...@yazi.ci> wrote: > > > > > Since, there are some tests which occasionally constantly fail, we use > > > `-Dmaven.test.failure.ignore=true` in `verify` goal. This causes a > build > > > with test failures to be marked green. The 3rd party component, > > > `scacap/action-surefire-report@v1`, is used to feed these failures > back > > > into GitHub Actions status with some pretty printing. But since the PR > is > > > opened by a user who doesn't have commit rights, the 3rd party > component > > > fails to mark the failures due to insufficient privileges. In > > > `.github/workflows/main.yml`, I had introduced the `if: > github.repository > > > == 'apache/logging-log4j2'` line to work around this, but apparently > it is > > > broken again. > > > > > > I totally share your frustration, same here. Though sparing time to fix > > > this is pretty difficult nowadays. > > > > > > I also need to confess, in those brief moments of insanity, I > contemplate > > > nuking all those flaky tests. This will simplify the CI magic a lot and > > > enhance our confidence in the tests. > > > > > > On Tue, Dec 21, 2021 at 3:10 AM Gary Gregory <garydgreg...@gmail.com> > > > wrote: > > > > > > > After getting https://github.com/apache/logging-log4j2/pull/646 in > what > > > I > > > > think is a good state, I have no idea if it is safe or not to merge > > > because > > > > the 1st build GitHub shows is red: > > > > > > > > > > > > https://github.com/apache/logging-log4j2/runs/4589771553?check_suite_focus=true > > > > > > > > I don't use GH actions the way we do here and I'm not sure why we > need > > > the > > > > publish test result set when anyone can just look at the build logs. > > > > > > > > Gary > > > > > > > > > >
