Skip to content
This repository has been archived by the owner on Apr 21, 2023. It is now read-only.

Move to Maven/Tycho for projects and build infrastructure #1445

Closed
LorenzoBettini opened this issue Jan 23, 2023 · 62 comments
Closed

Move to Maven/Tycho for projects and build infrastructure #1445

LorenzoBettini opened this issue Jan 23, 2023 · 62 comments
Labels
Milestone

Comments

@LorenzoBettini
Copy link
Contributor

See also eclipse/xtext-lib#499 and eclipse/xtext-core#2052 eclipse/xtext-extras#858

Development has started in my fork's branch:
https://github.com/LorenzoBettini/xtext-xtend/tree/lb_2052_maven_tycho

@LorenzoBettini
Copy link
Contributor Author

@cdietrich I seem to understand that we must use Java 17, because

Error:  org.eclipse.m2e.core 2.0.5.20221128-1757 requires Execution Environment that matches (&(osgi.ee=JavaSE)(version=17)) but the current resolution context uses [a.jre.javase 11.0.0]
Error:  Cannot resolve target definition:
Error:    Software being installed: org.eclipse.m2e.feature.feature.group 2.1.2.20221130-2239
Error:    Missing requirement: org.eclipse.m2e.core 2.0.5.20221128-1757 requires 'osgi.ee; (&(osgi.ee=JavaSE)(version=17))' but it could not be found
Error:    Cannot satisfy dependency: org.eclipse.m2e.feature.feature.group 2.1.2.20221130-2239 depends on: org.eclipse.equinox.p2.iu; org.eclipse.m2e.core [2.0.5.20221128-1757,2.0.5.20221128-1757]

@cdietrich
Copy link
Member

i dont get this point

  • r202203 target => java 11
  • r202206 and later => java 17

@LorenzoBettini
Copy link
Contributor Author

Sorry, I can't see the current configuration of Jenkins jobs due to the outage, and up to now, I thought we were building with Java 11 (that's what I did in GitHub Actions). Since in the other projects, m2e wasn't being used, I realized that only now. My mistake :)

@cdietrich
Copy link
Member

see

./3-maven-tycho-build.sh -s /home/jenkins/.m2/settings.xml --tp=${selectedTargetPlatform()} --local-repository=/home/jenkins/.m2/repository

choice(name: 'TARGET_PLATFORM', choices: ['r202203', 'r202206', 'r202209', 'r202212', 'latest'], description: 'Which Target Platform should be used?')

=> diffferent tps run with different java versions

@cdietrich
Copy link
Member

@LorenzoBettini
Copy link
Contributor Author

@cdietrich @szarnekow when running in GitHub Actions, this particular test fails on Windows (works on macOS and Linux):

org.eclipse.xtend.core.tests.compiler.batch.BatchCompilerTest.testCompileSymlinkedResource()

	@Test
    def void testCompileSymlinkedResource() {
        val tstResources = new File("./batch-compiler-data/test-resources/").toURI().normalize().getPath()
        val wsRootFile = new File(tstResources, "symlink-test-ws/")
        val wsRootPath = wsRootFile.getPath()
        val linkToCreate = wsRootPath + "/plain-folder/linked-src"
        if (!createSymLink(tstResources + "/linked-folder/linked-src/", linkToCreate)) {
            System.err.println(
                "Symlink creation is not possible - skip test. org.eclipse.xtend.core.tests.compiler.batch.TestBatchCompiler.testCompileSymlinkedResource()")
            return
        }
        assertTrue("plain-folder/linked-src/ is a symlink", isSymlink(new File(wsRootFile, "plain-folder/linked-src/")))
        assertTrue("plain-folder/src/ is not a symlink", !isSymlink(new File(wsRootFile, "plain-folder/src/")))
        batchCompiler.writeTraceFiles = true
        batchCompiler.sourcePath = wsRootPath + "/plain-folder/src" + File.pathSeparator + wsRootPath +
            "/plain-folder/linked-src"
        val customOutput = wsRootPath + "/plain-folder/target"
        batchCompiler.outputPath = customOutput
        assertTrue(batchCompiler.compile)
        assertTrue(new File(wsRootPath + "/plain-folder/target/Test.txt").exists)
        assertEquals(2, new File(customOutput).list[dir, name|name.endsWith(".java")].size)
        assertEquals(2, new File(customOutput).list[dir, name|name.endsWith("._trace")].size)

    }

with this error

Exec: ln -s /D:/a/xtext-xtend/xtext-xtend/org.eclipse.xtend.core.tests/batch-compiler-data/test-resources//linked-folder/linked-src/ D:\a\xtext-xtend\xtext-xtend\org.eclipse.xtend.core.tests\batch-compiler-data\test-resources\symlink-test-ws/plain-folder/linked-src

I guess that's expected because Windows does not support links.

I disabled such a test on Windows: LorenzoBettini@7176e61

@cdietrich
Copy link
Member

you are referring to TestBatchCompiler? i wonder why this works in gradle called from eclipse. or does it not work on tycho only?

@cdietrich
Copy link
Member

i see
Exec: ln -s /C:/xtext-master/git/xtext-xtend/org.eclipse.xtend.core.tests/batch-compiler-data/test-resources//linked-folder/linked-src/ C:\xtext-master\git\xtext-xtend\org.eclipse.xtend.core.tests\batch-compiler-data\test-resources\symlink-test-ws/plain-folder/linked-src
Symlink creation is not possible - skip test. org.eclipse.xtend.core.tests.compiler.batch.TestBatchCompiler.testCompileSymlinkedResource()

just does a syserr. do you see a test fail?
should we then remove the return and replace it with an error?

@LorenzoBettini
Copy link
Contributor Author

It does fail on GitHub Actions Windows: https://pipelines.actions.githubusercontent.com/serviceHosts/5e72f0c0-eb6b-432b-aef4-14c3a40c344b/_apis/pipelines/1/runs/5/signedlogcontent/2?urlExpires=2023-01-24T13%3A57%3A30.6657990Z&urlSigningMethod=HMACV1&urlSignature=ssQLzpbzPrF1hnXxJ69PoqxQzTChvm6J4dT2Y7mqnx4%3D

java.lang.AssertionError: plain-folder/linked-src/ is a symlink
 	at org.eclipse.xtend.core.tests.compiler.batch.BatchCompilerTest.testCompileSymlinkedResource(BatchCompilerTest.java:624)

So the check you're mentioning succeeds, but then the assertion fails...

I'll che that on my Windows machine once I've set it up

@cdietrich
Copy link
Member

cdietrich commented Jan 24, 2023

hm on my windows, ran from eclipse, it is green.
but i cannot find a BatchCompilerTest
did you rename?

@cdietrich
Copy link
Member

Screenshot 2023-01-24 150920

@cdietrich
Copy link
Member

which windows version is there on github actions? maybe this has symlinks now

@LorenzoBettini
Copy link
Contributor Author

Yes I had renamed that test (to follow the conventions).

This is the environment of GitHub Actions Windows: https://github.com/actions/runner-images/blob/main/images/win/Windows2022-Readme.md

@cdietrich
Copy link
Member

i dont have access to any windows server, just 10

@LorenzoBettini
Copy link
Contributor Author

On my Windows 10 machine, from Eclipse, if I run that test (after removing my check at the beginning) I also get

Exec: ln -s /C:/Users/bettini/git/xtext-sources/xtext-xtend/org.eclipse.xtend.core.tests/batch-compiler-data/test-resources//linked-folder/linked-src/ C:\Users\bettini\git\xtext-sources\xtext-xtend\org.eclipse.xtend.core.tests\batch-compiler-data\test-resources\symlink-test-ws/plain-folder/linked-src
Symlink creation is not possible - skip test. org.eclipse.xtend.core.tests.compiler.batch.TestBatchCompiler.testCompileSymlinkedResource()

In fact, if I try to run the command from a terminal I get

'ln' is not recognized as an internal or external command,
operable program or batch file.

but if try to run ln from the Git bash shell in Windows, the command is available!

I suspect that on GitHub Actions they provide WSL and bash so it might be that ln is available. Then, the assertion fails due to other reasons? Maybe because this check is not OS independent?

	def private boolean isSymlink(File file) {
		var File canon
		if (file.getParent() === null) {
			canon = file
		} else {
			var File canonDir = file.getParentFile().getCanonicalFile()
			canon = new File(canonDir, file.getName())
		}
		return !canon.getCanonicalFile().equals(canon.getAbsoluteFile())
	}

I'd avoid trying to understand what's going on on GitHub Actions on Windows.

By the way, now that I've enabled xtend.ide.tests, they work perfectly on linux and macOS (on GitHub Actions), but on Windows a few of the ide tests are flaky. For example,

java.lang.AssertionError: org.eclipse.emf.ecore.EObject cannot be resolved to a type.
 	at org.eclipse.xtend.ide.tests.compiler.ResolvingCrossReferenceDuringIndexingTest.assertNoErrorsInWorkspace(ResolvingCrossReferenceDuringIndexingTest.java:460)
 	at org.eclipse.xtend.ide.tests.compiler.ResolvingCrossReferenceDuringIndexingTest.testResolvingXFunctionTypeRef(ResolvingCrossReferenceDuringIndexingTest.java:421)
 	at org.eclipse.xtend.ide.tests.compiler.ResolvingCrossReferenceDuringIndexingTest.testResolvingXFunctionTypeRef_5(ResolvingCrossReferenceDuringIndexingTest.java:307)

Another time, that test succeeds but other two IDE tests were failing because they could not find org.eclipse.xtext.xbase.lib.

UI tests have always been a PITA on Windows on GitHub Actions, so I'd say I disable the build on Windows, WDYT?

@cdietrich
Copy link
Member

you can disable it for now. i also think there might be some more tests failing down the road.

@LorenzoBettini
Copy link
Contributor Author

So I'm going to revert this commit as well LorenzoBettini@7176e61 OK?

I hadn't noticed the check for symlink

@cdietrich
Copy link
Member

yes. or we need to look why it actually fails

@LorenzoBettini
Copy link
Contributor Author

i dont get this point

* r202203 target => java 11

* r202206 and later => java 17

I pushed my branch to xtext-xtend and I had to manually trigger the Jenkins build specifying 'latest' and 'jdk17', if I understood correctly.

@cdietrich
Copy link
Member

cdietrich commented Jan 24, 2023

Om Master there are profiles
r202203
r202206
r202209
r202212
latest
Each associated with a target file
AFAIK the first two run with java 11 the others java 17
Have no overview which one you use

@LorenzoBettini
Copy link
Contributor Author

Om Master there are profiles r202203 r202206 r202209 r202212 latest Each associated with a target file AFAIK the first two run with java 11 the others java 17 Have no overview which one you use

Yes I know about these profiles, and for the moment I'm only using "latest".

My question was related to the Jenkins job: I must specify build parameters correctly, right?
I mean, if I build with "latest" I have to make sure I specify manually Java 17 in the build parameter, right?

However, the build is green! :)

I have to inspect the missing tests

@cdietrich
Copy link
Member

cdietrich commented Jan 25, 2023

if you want to run with java 17 and latest by default you need to change Jenkinsfile to run with 17 by default or keep 11 and call with --tp=r202203

@cdietrich
Copy link
Member

Bildschirmfoto vom 2023-01-25 09-05-21

@LorenzoBettini
Copy link
Contributor Author

@cdietrich some findings about the differences in executed tests:

Maybe because it was deceived by the fact that they were inner classes of a suite class:

@RunWith(Suite.class)
@SuiteClasses({
	ReadWriteAccessTest.FieldReadTest.class,
	ReadWriteAccessTest.VariableReadTest.class,
})
@SuppressWarnings("all")
public class ReadWriteAccessTest {

	public static class FieldReadTest extends AbstractXtendTestCase {
...

so it might have executed the two inner test cases first as part of the suite and then as single discovered test cases.

@cdietrich
Copy link
Member

have no idea about these tests @szarnekow do you?

@cdietrich
Copy link
Member

cdietrich commented Jan 25, 2023

do we want to execute suites at all? Suite naming convention?
in gradle we have
test {
maxHeapSize = "2G"
exclude '**/*Suite.class'
}
but the file is named bad
or maybe gradle does not run inner classes

@LorenzoBettini
Copy link
Contributor Author

What I meant is that all the tests executed in the past are also executed now; it's just that the counting was misleading. Running suites does not make much sense in the CI since all tests are executed anyway. Maven and Tycho should keep track of executed test cases, avoiding running the same test case twice (because it is referred to by a suite). At least, that is what I recall.

From the results above, gradle also runs inner classes.

@cdietrich
Copy link
Member

=> rename the class on master, problem solved?

@LorenzoBettini
Copy link
Contributor Author

maybe, but I don't see that as we problem once we know the numbers to make sure all the tests executed in the past are executed now.

@LorenzoBettini
Copy link
Contributor Author

@cdietrich general question: in many test projects of most Git repositories, we have tons of warnings of discouraged access to our own provisional internal APIs. From time to time, I adjust "x-friend" accordingly in the MANIFEST. Should I go on like that, or can I configure the test projects to ignore "Discouraged access" warnings?

@cdietrich
Copy link
Member

i dont know. am still waiting for review feedback from @szarnekow .
alternative would be to ignore this testcase

@LorenzoBettini
Copy link
Contributor Author

I cherry-picked your commit... let's see

@cdietrich
Copy link
Member

17:16:00 [ERROR] Internal error: java.lang.IllegalArgumentException: bundleLocation not found: /home/jenkins/.m2/repository/org/eclipse/orbit/bundles/com.google.guava/30.1.0-SNAPSHOT/com.google.guava-30.1.0-SNAPSHOT.jar -> [Help 1]
17:16:00 org.apache.maven.InternalErrorException: Internal error: java.lang.IllegalArgumentException: bundleLocation not found: /home/jenkins/.m2/repository/org/eclipse/orbit/bundles/com.google.guava/30.1.0-SNAPSHOT/com.google.guava-30.1.0-SNAPSHOT.jar
what is happening now?

@LorenzoBettini
Copy link
Contributor Author

Once again, problems with Jenkins parameters... it was running for the Tycho build:

./3-maven-tycho-build.sh -s /home/jenkins/.m2/settings.xml --tp=r202203 --local-repository=/home/jenkins/.m2/repository

While I wanted latest.

What happened is:

For the Maven build it used the defaults because it's not parameterized, so Tycho 2.7.5. Instead, if I remember correctly, the older TP profile forces to use an older version of Tycho. As announced by Tycho, recent versions of Tycho (I guess 2.7.5) introduced changes in the downloaded artifacts that are not consumable by older versions of Tycho. So the Tycho build, using an older version of Tycho, cannot reuse the .m2 downloaded artifacts of the more recent version of Tycho.

I restarted the build with hopefully correct parameters.

@szarnekow
Copy link
Contributor

If I understand correctly Flaky annotation reexecutes the test but does not run any before/after

It does run the before and after for the test. If I modify FlakyFailsFourTimes and add

	@Before
	public void before() {
		System.out.println("Flaky Before");
	}
	
	@After
	public void after() {
		System.out.println("Flaky After");
	}

I see this output

Flaky Before
Flaky After
Flaky Before
Flaky After
Flaky Before
Flaky After

@szarnekow
Copy link
Contributor

have no idea about these tests @szarnekow do you?

ReadWriteAccessTest: The grouping into a suite is not necessary. These could just be regular top level tests.

@szarnekow
Copy link
Contributor

About the symlinks on Windows / Linux: java.nio.file.Files.createSymbolicLink(Path, Path, FileAttribute<?>...) might be preferable compared to running ln

@LorenzoBettini
Copy link
Contributor Author

@szarnekow thanks for the clarification on flaky! I also extracted the two tests and removed the suite.
Concerning Windows, for the moment I disabled the GitHub Actions workflow on Windows because it was very flaky in general.
It was also hard to debug, because on my Windows machine and also Christian's the test was not failing (it was skipped because it couldn't create the link in one of the first checks)

@cdietrich
Copy link
Member

cdietrich commented Jan 26, 2023

is there an easy way to test if

	def private boolean createSymLink(String linkTarget, String link) {
		try {
			val linkFile = new File(linkTarget)
			java.nio.file.Files.createSymbolicLink(new File(link).toPath, linkFile.toPath);
			abfalleimer.add(linkFile)
                        return true
		} catch (IOException e) {
			return false;
		}

goes into the catch clause on windows server?

update: it does not.
https://github.com/cdietrich/ln-tests

=> wonder what happens when you update the test

hmmm: maybe i did something bad with c&p
https://github.com/cdietrich/ln-tests/actions/runs/4013067820

https://github.com/cdietrich/ln-tests/blob/3c772aa0b94bbd3200f98a6c800e657467009697/src/test/java/aaaaaa/TestBatchCompiler.java#L623

am still experimenting
@szarnekow what is this test doing. i dont get it running
it fails with annotation not found

ok i added that class.
and with fixing isSymlink it seems to work

@cdietrich
Copy link
Member

another remark. you seem to use deprecated xvfb stuff.
on ubuntu there is xvfb-run available now
https://github.com/itemis/xtext-reference-projects/blob/d784a1c08871b406dc0157b856c1ab19708e63ec/.github/workflows/build-integtests-xtext.yml#L21

@LorenzoBettini
Copy link
Contributor Author

what do you mean "deprecated"? I'm using a GitHub Action that starts xvfb when running on Linux and doesn't when running on other OSes. This allows me to have a single GitHub Actions workflow. Of course, I could split the workflows.

@cdietrich
Copy link
Member

see GabrielBB/xvfb-action#30

@LorenzoBettini
Copy link
Contributor Author

I see, thanks for the update. I'll update the workflow with an if condition then.

@LorenzoBettini
Copy link
Contributor Author

This should fix it f6ef3e9

@LorenzoBettini
Copy link
Contributor Author

@cdietrich concerning Jenkinsfile and parameters, maybe I understand how to do that.

First, the default options must be the first ones:

    choice(name: 'TARGET_PLATFORM', choices: ['latest', 'r202203', 'r202206', 'r202209', 'r202212'], description: 'Which Target Platform should be used?')
    // see https://wiki.eclipse.org/Jenkins#JDK
    choice(name: 'JDK_VERSION', description: 'Which JDK should be used?', choices: [
       'temurin-jdk17-latest', 'temurin-jdk11-latest'
    ])

however, this changes the positions of the options, so if you had previously run a job using 'latest' when it was the last option now it would use the new last option 'r202212'. So, first, you have to adjust the parameters manually from the Jenkins job, and after running a job, everything should work concerning the defaults.

@cdietrich
Copy link
Member

yes the first parameter seems the first one, but i am not a jenkins file pro, so i cannot tell if it can be done better.
we do java 11 + oldest tp by default and in xtext-eclipse start a java 17 latest build 1ce a day and triggers then downstream xtend with the same

@LorenzoBettini
Copy link
Contributor Author

Some trivia on build times for this project in the CI, only for the effective build and test stuff:

  • GitHub Actions ubuntu: ~26 minutes
  • GitHub Actions macOS ~44 minutes
  • Jenkins JIRO: ~1 hour (but I've also seen executions lasting "only" 45 minutes)

These numbers include TP and dependency resolution; in GitHub Actions, we use cache for dependencies.

@cdietrich
Copy link
Member

cdietrich commented Jan 26, 2023

do we are faster as on master ?!?
are we sure any testst executed at all. why are they so fast

@szarnekow
Copy link
Contributor

Nice nice!

@LorenzoBettini
Copy link
Contributor Author

do we are faster as on master ?!? are we sure any testst executed at all. why are they so fast

well on master there are two build stages, grandle and tycho, but most of the tests are still run through tycho on master as well, aren't they? Two stages might add some overhead, maybe. For sure, I think we can say we're not slower ;)

I showed the numbers also to highlight how better GitHub Actions is in general ;)

@LorenzoBettini
Copy link
Contributor Author

PR is ready with detailed notes #1446

@cdietrich
Copy link
Member

with repo merge this is done

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants