-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No test results for I20240605-1800 #2101
Comments
This issue appears to be related to the automated test , Jenkins parameters. somehow the parameter field is not generated when the test is triggered automatically. However, when we rebuild the test manually, the buildID parameter is available and passed correctly. Raised : https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4717 |
OK, we have some changes made by Sebastien on https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4717 and now it seem to me that the tests are started properly but we have build? errors with some plugins missing
@sravanlakkimsetti , @akurtakov : I'm not sure what means the |
Don't forget to update the configuration as suggested by Sébastien Heurtematte in https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/JenkinsJobs/Builds/I_build.groovy and https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/JenkinsJobs/YBuilds/Y_build.groovy |
This means the testing has aborted in between. To debug I will normally check the console logs at https://download.eclipse.org/eclipse/downloads/drops4/I20240606-0650/logs.php#console. In this case ep433I-unit-win32-java17_win32.win32.x86_64_17_consolelog.txt. In that file there should be 78 instances of In this instance I see
It appears pde tests are looking for user input. Please check the org.eclipse.pde.ui.tests.AllPDETests bundle |
That would mean, the Jenkins job parameters aren't resolved? |
This contains the changes to the I-build config applied by Sébastien Heurtematte directly to the job in Jenkins for - https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4717#note_2343210 - eclipse-platform#2101 (comment) Co-authored-by: Sébastien Heurtematte <sebastien.heurtematte@eclipse-foundation.org>
Do you read that from the
I have to admit I don't know what to check because I don't find anything that seem relevant when searching for |
Created #2107 in an attempt to capture the changes. |
Ensure all stages run within the 'jnlp' container and remove defaultContainer 'container' because a container named 'container' isn't defined. See eclipse-platform#2101 (comment) Co-authored-by: Sébastien Heurtematte <sebastien.heurtematte@eclipse-foundation.org>
The tests are executed again. Only remaining part is to update scripts that create jobs => #2108 |
My guess was based on
I could be wrong here though. the testing can stop if there is a timeout, waiting for user input, test bundle not installed properly during the run.
|
Ensure all stages run within the 'jnlp' container and remove defaultContainer 'container' because a container named 'container' isn't defined. See #2101 (comment) Co-authored-by: Sébastien Heurtematte <sebastien.heurtematte@eclipse-foundation.org>
Just submitted #2108 and deplyed the job configurations in the RelEng JIPP I also triggered an I-build and aborted it after the first stage to verify that there are no sever syntax errors. |
Yes I noticed that as well at this moment :( Looks like #2108 wasn't sufficient. Since it makes a difference if the job is triggered manually or by the cron-tigger I wonder if it is actually a question of permissions? |
I did some investigation with my local Jenkins and since the Parameters tab ob the test jobs does not show anything I have the impression that the test-jobs somehow 'forgets' that it has parameters. If the triggering job would not pass the buildId parameter the default value would be used but the parameter would still be displayed (which is not the case if a job is cron triggered):
With that in mind, @heurtematte could it be that the removal of eclipse.platform.releng.aggregator/JenkinsJobs/Builds/I_build.groovy Lines 77 to 78 in 132e5e7
in #2107 makes the difference? |
In the past night triggering the I-build test succeeded as desired again: There are quite some failures in JDT's tests but they also happened in the I-build before which I triggered manually: Trying to explain that in retrospective I would say that's because pipeline jobs need to run once to know their parameters: And it looks like this behavior is for each kind of trigger? But I wonder if this has not been noticed before and it looks like that is because since
The parameters are defined within the pipeline instead of being defined as job parameters in the job configuration outside the pipeline itself. But lets see if the next nightly I-build confirms that. Since I'm currently working on unifying the I-build test-pipelines in #2005 I would like to fix the parameter definition on the first run after the pipelines have been merged to have less changes. |
Yes, it's a bit frustrating that parameter changes to a Jenkinsfile aren't noticed earlier and there is no mechanism (that I know of) for telling the job to process the Jenkinsfile purely for the purposes of updating the parameter details. In some cases I did this: One can guard all the steps that it's the expected version and increment the version when the parameter definitions change. The first launch will use the older version definition and skip everything. But surely there must be a better way... |
Declaring the parameters only within the pipeline definition has the disadvantage that they have to be discovered in the first run and are therefore only available in the second run onwards. This leads to total failures of all I-build tests on the first run each time the seed job to create the Eclipse RelEng jobs ran. Permanently fixes eclipse-platform#2101
Declaring the parameters only within the pipeline definition has the disadvantage that they have to be discovered in the first run and are therefore only available in the second run onwards. This leads to total failures of all I-build tests on the first run each time the seed job to create the Eclipse RelEng jobs ran. Permanently fixes #2101
Absolutely. I have just submitted #2129 to fix that. |
See https://download.eclipse.org/eclipse/downloads/drops4/I20240605-1800/
We have no idea about build quality.
At least SDK is starting now on Linux, so that SWT binaries problem is not a problem anymore.
The text was updated successfully, but these errors were encountered: