Skip to content
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

A suggestion for a more simple mostly automated way to test a patch. #884

Open
the-snowwhite opened this issue Nov 11, 2023 · 13 comments
Open

Comments

@the-snowwhite
Copy link
Contributor

the-snowwhite commented Nov 11, 2023

The presentation:

In my first adventure of being able to fix 2 Eclipse bugfix issues: #851

There was a moment where I fumbled the ball being unable to answer a simple question:
beginning with this request:
#879 (comment)
(arrived in my mail-inbox: Fri, 10 Nov 2023 06:16:22 -0800)

And the first arrival of the question was:
(arrived in my mail-inbox: Fri, 10 Nov 2023 08:57:50 -0800 )

The moment I fumbled was:
here:
#879 (comment)
(arrived in my mail-inbox: Fri, 10 Nov 2023 09:38:26 -0800)

The time the (correct) decision was made assuming a yes.
(arrived in my inbox:Fri, 10 Nov 2023 10:23:39 -0800 )

the moment I was able to input the correct answer to this very simple question via the method requested was the time stamp of this comment :
#851 (comment)
(right now it says 17 hours ago and my local time is now 16:12 GMT+1 Copenhagen).

So how much time and frustration could have been saved via more automation of the #858 process ?

So that the required swt binaries could be made via a pull request like process ?

This is the end of the time stamped opening more will follow shortly.

@the-snowwhite
Copy link
Contributor Author

the-snowwhite commented Nov 11, 2023

An unmentioned first step (1.a) in the #858 process is to create a usable patch, by picking out the relevant commits,
and theh rewording them to something github likes (changing only the commit messages).
last part of this step is committing to your local branch.
the patch I came up with is right now linked to in this comment:
#851 (comment)

As a test I then made a PR to R_29_Maintenance:

@the-snowwhite
Copy link
Contributor Author

the-snowwhite commented Nov 11, 2023

@mickaelistria
@iloveeclipse

Will you please answer this simple question

Would this proposal have made things easier yesterday ?

The proposal:

If the Releng builds could be made able to provide the build artifacts to the users (Like in current Machinekit).
preferably via a link in the PR gui.
It would make i much easier to test PR's and make the #858 as easy as;
download, rename 3 files(could be skiped if the build names them correctly), copy them in plugins folder, test in your current Stable Eclipse release.(Or whatever there are branches for).

Originally posted by @the-snowwhite in #881 (comment)

the builder only needs to run the same mvn commands as those i copied from the the jenkins build console:
steps 8 and 9 of the #858 process

@mickaelistria
Copy link
Contributor

The SWT artifacts are archived on CI for each build upon success. You can for example get the one PR-883 would generate at https://ci.eclipse.org/releng/job/eclipse.platform.swt/view/change-requests/job/PR-883/lastSuccessfulBuild/artifact/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/target/

@the-snowwhite
Copy link
Contributor Author

OK
If I understand this correctly the ones for #881 would then now be at:
https://ci.eclipse.org/releng/job/eclipse.platform.swt/view/change-requests/job/PR-881/lastSuccessfulBuild/artifact/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/target/

Without the need for a merge if that build had succeeded ?

(I think that a re-visit from dependa-bot is all that is needed for the build to succeed)
Hmmm
that seems to have been done:
https://github.com/the-snowwhite/eclipse.platform.swt/commits/R4_29_maintenance

@the-snowwhite
Copy link
Contributor Author

the-snowwhite commented Nov 11, 2023

The build seemed to fail with this (non commit related) message:

[ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:4.0.2:compare-version-with-baselines
(compare-attached-artifacts-with-release) on project org.eclipse.swt: Only qualifier changed for 
(org.eclipse.swt/3.124.100.v20231111-0040). Expected to have bigger x.y.z than what is available in baseline 
(3.124.100.v20230825-1346)

familiar ?

@the-snowwhite
Copy link
Contributor Author

the-snowwhite commented Nov 11, 2023

I found 2 of the 3 files needed in
https://ci.eclipse.org/releng/job/eclipse.platform.swt/view/change-requests/job/PR-883/lastSuccessfulBuild/artifact/eclipse.platform.swt.binaries/bundles/org.eclipse.swt.gtk.linux.x86_64/target/

However I also seemed to need to replace:
/home/mib/.p2/pool/plugins/org.eclipse.swt_3.124.100.v20230825-1346.jar

with the renamed version of:

mib@neon-am5:~/.m2/repository/org/eclipse/swt/org.eclipse.swt/3.124.100-SNAPSHOT$ ls -l

-rw-rw-r-- 1 mib mib 19245 nov 10 21:53 org.eclipse.swt-3.124.100-SNAPSHOT.jar

(its only 18.8kb)

before the patched Eclipse would startup correctly ?

I think this file is from the second mvn build not the first build of the binaries repo.

@the-snowwhite
Copy link
Contributor Author

the-snowwhite commented Nov 11, 2023

This leads the to the next logical question:
Why did the build fail with these messages

[ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:4.0.2:compare-version-with-baselines
(compare-attached-artifacts-with-release) on project org.eclipse.swt: Only qualifier changed for 
(org.eclipse.swt/3.124.100.v20231111-0040). Expected to have bigger x.y.z than what is available in baseline 
(3.124.100.v20230825-1346)

and these messages in the build console:

02:12:30  [ERROR] Failed to execute 
goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:4.0.2:compare-version-with-baselines (compare-attached-artifacts-with-release) 
on project org.eclipse.swt: Only qualifier changed for (org.eclipse.swt/3.124.100.v20231111-0040). 
Expected to have bigger x.y.z than what is available in baseline (3.124.100.v20230825-1346) -> [Help 1]
02:12:30  [ERROR]
02:12:30  [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
02:12:30  [ERROR] Re-run Maven using the -X switch to enable full debug logging.
02:12:30  [ERROR]
02:12:30  [ERROR] For more information about the errors and possible solutions, please read the following articles:
02:12:30  [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
02:12:30  [ERROR]
02:12:30  [ERROR] After correcting the problems, you can resume the build with the command
02:12:30  [ERROR]   mvn <args> -rf :org.eclipse.swt

update:

Only qualifier changed for 

(org.eclipse.swt/3.124.100.v20231111-0040). Expected to have bigger x.y.z than what is available in baseline
(3.124.100.v20230825-1346)

in the first message and

and

(org.eclipse.swt/3.124.100.v20231111-0040). Expected to have bigger x.y.z than what is available in baseline 
(3.124.100.v20230825-1346)

in the second message seem to stand out ?
also is the failure in any way related to #868 ?

@the-snowwhite
Copy link
Contributor Author

From the #881 PR build console.log the last command run is:

mvn clean verify --batch-mode -DforkCount=0 -Dcompare-version-with-baselines.skip=false -Dmaven.compiler.failOnWarning=true -Dmaven.test.failure.ignore=true -Dmaven.test.error.ignore=true

in folder:

/home/jenkins/agent/workspace/eclipse.platform.swt_PR-881/eclipse.platform.swt

The summary and Error messages block contains:

02:12:29  [INFO] ------------------------------------------------------------------------
02:12:29  [INFO] Reactor Summary:
02:12:29  [INFO]
02:12:29  [INFO] eclipse.platform.swt 4.29.0-SNAPSHOT ............... SUCCESS [  6.244 s]
02:12:29  [INFO] org.eclipse.swt 3.124.100-SNAPSHOT ................. FAILURE [ 21.402 s]
02:12:29  [INFO] org.eclipse.swt.fragments.localbuild 3.105.0-SNAPSHOT SKIPPED
02:12:29  [INFO] org.eclipse.swt.tools.base 3.107.400-SNAPSHOT ...... SKIPPED
02:12:29  [INFO] org.eclipse.swt.tools.spies 3.109.100-SNAPSHOT ..... SKIPPED
02:12:29  [INFO] org.eclipse.swt.tools 3.110.100-SNAPSHOT ........... SKIPPED
02:12:29  [INFO] org.eclipse.swt.examples 3.108.100-SNAPSHOT ........ SKIPPED
02:12:29  [INFO] org.eclipse.swt.examples.browser.demos 3.108.100-SNAPSHOT SKIPPED
02:12:29  [INFO] org.eclipse.swt.examples.launcher 3.108.100-SNAPSHOT SKIPPED
02:12:29  [INFO] org.eclipse.swt.examples.ole.win32 3.108.100-SNAPSHOT SKIPPED
02:12:29  [INFO] org.eclipse.swt.examples.views 3.108.100-SNAPSHOT .. SKIPPED
02:12:29  [INFO] org.eclipse.swt.tests 3.107.100-SNAPSHOT ........... SKIPPED
02:12:29  [INFO] org.eclipse.swt.tools.feature 3.109.100-SNAPSHOT ... SKIPPED
02:12:29  [INFO] org.eclipse.swt.tests.gtk 3.109.0-SNAPSHOT ......... SKIPPED
02:12:29  [INFO] ------------------------------------------------------------------------
02:12:29  [INFO] BUILD FAILURE
02:12:29  [INFO] ------------------------------------------------------------------------
02:12:29  [INFO] Total time:  01:36 min
02:12:29  [INFO] Finished at: 2023-11-11T01:12:29Z
02:12:29  [INFO] ------------------------------------------------------------------------
02:12:30  [ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:4.0.2:compare-version-with-baselines (compare-attached-artifacts-with-release) on project org.eclipse.swt: Only qualifier changed for (org.eclipse.swt/3.124.100.v20231111-0040). Expected to have bigger x.y.z than what is available in baseline (3.124.100.v20230825-1346) -> [Help 1]
02:12:30  [ERROR]
02:12:30  [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
02:12:30  [ERROR] Re-run Maven using the -X switch to enable full debug logging.
02:12:30  [ERROR]
02:12:30  [ERROR] For more information about the errors and possible solutions, please read the following articles:
02:12:30  [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
02:12:30  [ERROR]
02:12:30  [ERROR] After correcting the problems, you can resume the build with the command
02:12:30  [ERROR]   mvn <args> -rf :org.eclipse.swt

@the-snowwhite
Copy link
Contributor Author

https://ci.eclipse.org/releng/job/eclipse.platform.swt/view/change-requests/

PR-890 15 hr #1 N/A 2 hr 3 min   46

PR-890 15 hr #1 N/A 2 hr 3 min 46

I think this shows that I could have answered the question as yes without doubt on time.

@the-snowwhite
Copy link
Contributor Author

the-snowwhite commented Nov 13, 2023

I'm currently assimilating
eclipse-platform/eclipse.platform.releng.aggregator#863
To see if anything there can get me out of my Do not merge PR sandbox dilemma stalemate situation.

in #890
as a result of #881 and #858

Just because i was unsatisfied with this answer
@mickaelistria @iloveeclipse @sravanlakkimsetti @merks
Any suggestions ?

@the-snowwhite
Copy link
Contributor Author

the-snowwhite commented Nov 13, 2023

The Eclipse Versioning Numbering Document has following things to say about bug fixes:

Each segment captures a different intent:

the major segment indicates breakage in the API
the minor segment indicates "externally visible" changes
the service segment indicates bug fixes and the change of development stream (the semantics attached to development stream is new to this proposal, see below)
the qualifier segment indicates a particular build

The minor segment number must be incremented when a plug-in changes in an "externally visible" way. Examples of externally visible changes include binary compatible API changes, an updated BREE (Bundle-RequiredExecutionEnvironment), significant performance changes, major code rework, adding a new extension point, changing files with a somewhat unclear API status (e.g. changing icons from gif to png), etc. Another way to know when this version number should be changed is by exclusion: it should indicate changes that are neither bug fixes (indicated by the service segment) nor breaking API changes (indicated by the major segment). When the minor segment is changed, the service segment is reset to 0.

I think this confirms the LLM's (Chatgpt4) analysis is correct.

Analysis of 3.124.100.qualifier and 3.124.101.qualifier

Major Version (3): Both versions have the same major version number (3), indicating that there are no breaking changes in the API between these two versions.
Minor Version (124): The minor version is also the same in both cases, suggesting that no new "externally visible" features or significant changes have been introduced.
Service Version (100 vs. 101):
    The service version has incremented from 100 to 101. This increment typically indicates bug fixes or other changes that are not visible in the API.
    According to the Eclipse guidelines, if a change occurs in a service release, then the number is incremented by 1. If it happens for the next official release, 100 is added.
Qualifier Segment (qualifier): This is a placeholder segment used to indicate specific builds. In actual usage, this would be replaced by a more specific string, often a date or build identifier.

Implications of the Version Change

The change from 3.124.100.qualifier to 3.124.101.qualifier indicates a progression in the development of the software, most likely due to bug fixes or minor changes that do not affect the API or the external functionality of the software.
This versioning approach allows for detailed tracking of changes and helps in maintaining compatibility, especially in a complex software ecosystem like Eclipse.
By following these guidelines, Eclipse ensures consistent and predictable management of its software versions, facilitating the understanding of the nature and impact of changes for developers and users alike.

The detailed versioning system in Eclipse, as described in the Eclipse_versioning_numbering.txt file, reflects a comprehensive approach to software development and release management, crucial for large-scale and modular software projects.

This means that #851
could have been labeled bug:
I don't know why this didn't happen
I thought I was adding a new feature.

@basilevs
Copy link
Contributor

basilevs commented Nov 27, 2023

This happened to me in #883. The key to solution was to ignore any and all errors from API Tools in PDE and rely on CI to correctly verify API changes. It is slow, but configuring API tools to work correctly locally is just impractical for a new contributor.
Also, do not touch versions unless CI orders to do so.

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

No branches or pull requests

3 participants