Bugzilla – Full Text Bug Listing
|
Description
Alexander Kurtakov
Decision on github organization has to be made before we can move on here. I'm looking at changing the submodules URLs to absolute ones (to allow to reference Gerrit repos from Gerrit). It's definitely possibe but there is a but ;) Currently, with URLs referenced as relative ones, we can carry some authentication info. ie when cloning ssh://genie.releng@git.eclipse.org:29418/platform/eclipse.platform.releng.aggregator.git , then the submodules will also use the same SSH account. That is convenient for further tagging of the repo. And when cloning with HTTPS, then the children URLs are also HTTPS, so this is convenient for users who don't have an SSH account configured but still want to get the code locally. Basically, it allows to factorize/propagate the permissions from aggregator to children. With absolute URLs, we loose that. We'd need to decide of whether to use HTTPS or SSH by default, and either instruct users how to switch their remote modules between one and the other according to their needs and privileges; and we may need to add to the build script a step that adds the SSH URLs to allow further tagging of children repos. Of course, once children repos are all moved to GitHub, we can move back to relative path for remotes and then get the HTTPS vs SSH propagated. The difficulty is about what to do in the meantime. Cloning of aggregator repository with submodules is useful for users who wants to build platform locally. They don't do any commits to the any of the repositories(Except genie.releng). For them it should be ok to use https links. In case of genie.releng(using releng jipp), we do commit and tag on all repositories. Here the script we use for clone (https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/mbscripts/mb100_cloneRepos.sh) And Tagging script (https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/mbscripts/mb110_tagBuildInputs.sh) If we can modify these scripts to use different urls or change the push url during the git checkout operation at https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/mbscripts/mb100_cloneRepos.sh#n30 We will be able to solve permissions issue. if required we can list the push url also along with the branch information in https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/streams/repositories_master.txt New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/188410 Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/188410 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=ea3b3882eec4b6d52b2831732dc34451fec0d376 New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/188497 Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/188497 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=be4564ca15f6b8aec42b902d6c9f833f5ff01397 The tagging part is covered. What needs to be changed now are the various steps when a `git clone` of the aggregator is done. I find it strange that the repo needs to `git clone` itself to build. So maybe we should target getting rid of those steps instead? (In reply to Mickael Istria from comment #9) > The tagging part is covered. > What needs to be changed now are the various steps when a `git clone` of the > aggregator is done. I find it strange that the repo needs to `git clone` > itself to build. So maybe we should target getting rid of those steps > instead? Double cloning sounds weird to me too. (In reply to Mickael Istria from comment #9) > The tagging part is covered. > What needs to be changed now are the various steps when a `git clone` of the > aggregator is done. I find it strange that the repo needs to `git clone` > itself to build. So maybe we should target getting rid of those steps > instead? Yes there is double cloning. In the first one we do not clone submodules. In the second one we clone along with sub-modules. first clone is used only for the build scripts only. And using the second clone we do the maven build. One of the reasons for this is to isolate maven build from shell scripts. Another reason was I found it easier to code using clone with submodules rather than use sync submodules. Unfortunately I added all the temporary logs, files, and dirt in cje-production folder. This caused problems during the build input process. So I ended up using the above design. If we can avoid these steps we can definitely work towards changing cloning the source. (In reply to Sravan Kumar Lakkimsetti from comment #11) > (In reply to Mickael Istria from comment #9) > > The tagging part is covered. > > What needs to be changed now are the various steps when a `git clone` of the > > aggregator is done. I find it strange that the repo needs to `git clone` > > itself to build. So maybe we should target getting rid of those steps > > instead? > > Yes there is double cloning. In the first one we do not clone submodules. In > the second one we clone along with sub-modules. > > first clone is used only for the build scripts only. And using the second > clone we do the maven build. If we clone with submodules you still can use the build scripts only (basically not using the submodules). Or is their an issue I don't issue / understand? (In reply to Lars Vogel from comment #12) > If we clone with submodules you still can use the build scripts only > (basically not using the submodules). Or is their an issue I don't issue / > understand? The build scripts to hardcode some locations to git.eclispse.org; and it's not trivial to sort out what can be changed or not. It's doable, but not something we can do without focusing effort on this task. To move forward, a 1st step would be to have the GitHub repo created. Can on the PL deal with creation of the GitHub repo? The GitHub repo is https://github.com/eclipse-platform/eclipse.platform.releng.aggregator ; it's currently not sync'd and the content here are not meant to be treated as official or usable for the moment, all experimental. I'm working on setting a I-Build job that uses GitHub as source: https://ci.eclipse.org/releng/job/I-build-4.23-github/ . I currently removed the periodic execution so only manual actions can trigger it. I'll temporarily remove everything that is about "Promoting" and we will then be able to work on this repoistory to make CI happy with it. Relevant changes will be backported to the official Gerrit repo. When we feel ready, we'll then be able to re-enable the "Promote" steps and try them, and -upon success- we'll then be able to fully switch to the GitHub build and repo. New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/189778 Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/189778 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=d75f9f4223f98141bede7a8c2ef2efdffb36b4a6 Can you open https://ci.eclipse.org/releng/job/I-build-4.23-github/ to all committers to see / change the configuration? Otherwise it is hard to help / test. Last job was successful, so maybe this work is already done? (In reply to Lars Vogel from comment #18) > Can you open https://ci.eclipse.org/releng/job/I-build-4.23-github/ to all > committers to see / change the configuration? Otherwise it is hard to help / > test. We don't want the build to be ran randomly for the moment as it's not complete and still risky to manipulate. All the configuration is in the GitHub repository, the build just runs JenkinsJobs/Build/I-Build.groovy . So current state of things is that the GitHub job seems to work: build runs, tags are created... Only the promotion and email jobs are currently disabled. Those do not seem to be tied to Git in anyway, so I suspect those would succeed without issue. I'd like someone else (Sravan? Alex?) to review the build output. If there is enough confidence that things are working as expected, I'll re-enable the promotion and mail and we can then turn off the "Gerrit" job and repo. I would like this to be reviewed by Sravan when he is available as he knows the whole picture in most details. While migrating to github. I envisaged 3 places we need to make modifications 1. Clone source. here aggregator needs to pulled from github and all other needs to be done from git.eclipse.org - This is working. 2. Tag the source in both github and git. - This is also working 3. Generate gitlog with links pointing to appropriate commits. - This is also working https://ci.eclipse.org/releng/job/I-build-4.23-github/4/artifact/eclipse.platform.releng.aggregator/eclipse.platform.releng.aggregator/cje-production/siteDir/eclipse/downloads/drops4/I20220120-0720/gitLog.html Looked at the logs and the build process looks good. I did not test the build. But I believe it will work without any problems. There we are: * https://ci.eclipse.org/releng/job/I-build-4.23-github/ contains all steps (including promotion & email) * https://ci.eclipse.org/releng/job/I-build-4.23/ is now disabled If everything is fine, then we stick to it; other wise, I'll disable the new build and reenable the "legacy" one. 🤞 (In reply to Mickael Istria from comment #23) > There we are: > * https://ci.eclipse.org/releng/job/I-build-4.23-github/ contains all steps > (including promotion & email) > * https://ci.eclipse.org/releng/job/I-build-4.23/ is now disabled > If everything is fine, then we stick to it; other wise, I'll disable the new > build and reenable the "legacy" one. > 🤞 There seem to be some configuration issues - could be, we use different ECJ / Java version for building? Some classes mentioned in the report weren't changed for years. https://download.eclipse.org/eclipse/downloads/drops4/I20220124-0510/buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt (In reply to Andrey Loskutov from comment #24) > (In reply to Mickael Istria from comment #23) > > There we are: > > * https://ci.eclipse.org/releng/job/I-build-4.23-github/ contains all steps > > (including promotion & email) > > * https://ci.eclipse.org/releng/job/I-build-4.23/ is now disabled > > If everything is fine, then we stick to it; other wise, I'll disable the new > > build and reenable the "legacy" one. > > 🤞 > > There seem to be some configuration issues - could be, we use different ECJ > / Java version for building? Some classes mentioned in the report weren't > changed for years. > > https://download.eclipse.org/eclipse/downloads/drops4/I20220124-0510/ > buildlogs/comparatorlogs/buildtimeComparatorUnanticipated.log.txt The problems are with lambda order. This is a known problem from quite sometime. Immediate fix is to touch those bundles. (In reply to Sravan Kumar Lakkimsetti from comment #25) > The problems are with lambda order. This is a known problem from quite > sometime. Immediate fix is to touch those bundles. But we don't have that on regular build - so the changed order must have some trigger / root cause? (In reply to Andrey Loskutov from comment #26) > (In reply to Sravan Kumar Lakkimsetti from comment #25) > > The problems are with lambda order. This is a known problem from quite > > sometime. Immediate fix is to touch those bundles. > > But we don't have that on regular build - so the changed order must have > some trigger / root cause? Actually we do see these errors on Y-build quite regularly. The code generated is in valid class format except that the lambda order is different from previous build. This I have seen when we move from one branch to another. In this case we have moved from git to github. I could not find a reproducible scenario for this one yet or root cause why this happens. (In reply to Sravan Kumar Lakkimsetti from comment #27) > (In reply to Andrey Loskutov from comment #26) > > (In reply to Sravan Kumar Lakkimsetti from comment #25) > > > The problems are with lambda order. This is a known problem from quite > > > sometime. Immediate fix is to touch those bundles. > > > > But we don't have that on regular build - so the changed order must have > > some trigger / root cause? > > Actually we do see these errors on Y-build quite regularly. The code > generated is in valid class format except that the lambda order is different > from previous build. > > This I have seen when we move from one branch to another. In this case we > have moved from git to github. > > I could not find a reproducible scenario for this one yet or root cause why > this happens. Do we have a corresponding JDT bug? If not, we should. Compiler should generate lambdas from same source in deterministic order, and obviously that is not the case. Do you have some historical reports - are always same classes affected, or is that also random? (In reply to Andrey Loskutov from comment #28) > Do we have a corresponding JDT bug? If not, we should I've created bug 578351 Is the fact that those changes popup while moving to GitHub a coincidence or is this a trigger? I don't get how this change can cause changes in .class file content. Another issue is that pushing to GitHub seems broken: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/787#note_489009 (In reply to Mickael Istria from comment #30) > Is the fact that those changes popup while moving to GitHub a coincidence or > is this a trigger? I don't get how this change can cause changes in .class > file content. Do we have different system that runs the build? What is actually different between "usual" SDK build and the one triggered via github? (In reply to Andrey Loskutov from comment #32) > Do we have different system that runs the build? What is actually different > between "usual" SDK build and the one triggered via github? I think/hope nothing is different unless the URI of the aggregator repository, but all the Maven and other environment things that usually affect the build output didn't change. (In reply to Mickael Istria from comment #30) > Is the fact that those changes popup while moving to GitHub a coincidence or > is this a trigger? I don't get how this change can cause changes in .class > file content. It is a coincidence. We did tried to investigate but could not figure out why this is happening. Our current theory is the order of java files presented to the compiler. We did confirm the java files order presented to the ecj compiler is different in case of I-build and Y-build scenario. I this it will be same here as well. We have a Bug 565336 which produces two different ids for the same lambda. The class file generation is based on this id. Investigating this might give us why we are having lambda order problems. (In reply to Andrey Loskutov from comment #32) > (In reply to Mickael Istria from comment #30) > > Is the fact that those changes popup while moving to GitHub a coincidence or > > is this a trigger? I don't get how this change can cause changes in .class > > file content. > > Do we have different system that runs the build? What is actually different > between "usual" SDK build and the one triggered via github? Since we run the build in a container, technically the machine used is created whenever we run a build but we do use same docker image to create docker container. (In reply to Mickael Istria from comment #23) > There we are: > * https://ci.eclipse.org/releng/job/I-build-4.23-github/ contains all steps > (including promotion & email) > * https://ci.eclipse.org/releng/job/I-build-4.23/ is now disabled > If everything is fine, then we stick to it; other wise, I'll disable the new > build and reenable the "legacy" one. > 🤞 What are the plans? We have the old build job (https://ci.eclipse.org/releng/view/Builds/job/I-build-4.23/) disabled now, but there was no new nightly build today. Considering we have to contribute M2 on 28 January, would be good to have some nightly build running. (In reply to Andrey Loskutov from comment #35) > (In reply to Mickael Istria from comment #23) > > There we are: > > * https://ci.eclipse.org/releng/job/I-build-4.23-github/ contains all steps > > (including promotion & email) > > * https://ci.eclipse.org/releng/job/I-build-4.23/ is now disabled > > If everything is fine, then we stick to it; other wise, I'll disable the new > > build and reenable the "legacy" one. > > 🤞 > > What are the plans? We have the old build job > (https://ci.eclipse.org/releng/view/Builds/job/I-build-4.23/) disabled now, > but there was no new nightly build today. Considering we have to contribute > M2 on 28 January, would be good to have some nightly build running. Lets reenable the old build job (In reply to Sravan Kumar Lakkimsetti from comment #36) > Lets reenable the old build job +1. The GitHub job is currently incomplete and the cron trigger wasn't enabled, let's just keep it for testing at the moment until it's all good to switch. (In reply to Mickael Istria from comment #37) > (In reply to Sravan Kumar Lakkimsetti from comment #36) > > Lets reenable the old build job > > +1. The GitHub job is currently incomplete and the cron trigger wasn't > enabled, let's just keep it for testing at the moment until it's all good to > switch. Triggered a new build now Infra issue https://ci.eclipse.org/releng/job/I-build-4.23-github/ should be fixed now. I updated master and tags on GitHub, disabled the Gerrit job and re-enabled the GitHub on and triggered a build: https://ci.eclipse.org/releng/job/I-build-4.23-github/ . Let's monitor completion of the build. Upon completion, important things to verify are tags on GitHub and Gerrit are present. When this is successful, we can configure the GitHub job to trigger on cron just like the Gerrit one and call it done. So while build is still running (slow infra today, got some Jenkins restart in the meantime...), I could see that the tags I20220203-1550 generated by the GitHub job are published as expected on the GitHub repo and on all children repo at Gerrit. Let's cross fingers for successful completion, this tag issue was the only one known remaining so far. Submitted https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/2 for Y-Build New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/190436 Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/190436 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=64cb3ea441f87668919b014a3eb83c1bf06316a1 Did I miss a platform-dev mail for the changes here? I might not have paid enough attention. By chance I wanted to check where an entry from the eclipse.ini was coming from, after checking out https://git.eclipse.org/r/platform/eclipse.platform.releng.aggregator.git the repository is empty, with a README.md pointing to the new repository. Also I assume whatever how-to pages in wiki.eclipse.org/ are updated with the new repository path? (In reply to Simeon Andreev from comment #44) > Did I miss a platform-dev mail for the changes here? I might not have paid > enough attention. > > By chance I wanted to check where an entry from the eclipse.ini was coming > from, after checking out > https://git.eclipse.org/r/platform/eclipse.platform.releng.aggregator.git > the repository is empty, with a README.md pointing to the new repository. > > Also I assume whatever how-to pages in wiki.eclipse.org/ are updated with > the new repository path? Mail is not sent yet - there is still steps to do to consider it finished (e.g. featureFreeze.sh references in Jenkinsfiles) but infra problems are not helping us to move faster. wiki.eclipse.org pages are fixed wherever I saw them. Looks like wiki pages have not been updated yet, e.g. this one I would consider to be the main one: https://wiki.eclipse.org/Platform-releng/Platform_Build#cloning_platform_source_tree (In reply to Simeon Andreev from comment #46) > Looks like wiki pages have not been updated yet, e.g. this one I would > consider to be the main one: > > https://wiki.eclipse.org/Platform-releng/ > Platform_Build#cloning_platform_source_tree This page couldn't have been more outdated :) I did a first round of improvement to it https://wiki.eclipse.org/index.php?title=Platform-releng%2FPlatform_Build&type=revision&diff=444895&oldid=415383 but Build Output and Running tests sections are probably still wrong. I'm leaving them as they are for someone to improve them if interested. IMHO we should delete most of these sections. (In reply to Alexander Kurtakov from comment #47) > (In reply to Simeon Andreev from comment #46) > > Looks like wiki pages have not been updated yet, e.g. this one I would > > consider to be the main one: > > > > https://wiki.eclipse.org/Platform-releng/ > > Platform_Build#cloning_platform_source_tree > > This page couldn't have been more outdated :) > I did a first round of improvement to it > https://wiki.eclipse.org/index.php?title=Platform- > releng%2FPlatform_Build&type=revision&diff=444895&oldid=415383 but Build > Output and Running tests sections are probably still wrong. I'm leaving them > as they are for someone to improve them if interested. IMHO we should delete > most of these sections. I wish in some future we could just remove such pages and put such documentation in the aggregator repo directly. (In reply to Mickael Istria from comment #48) > (In reply to Alexander Kurtakov from comment #47) > > (In reply to Simeon Andreev from comment #46) > > > Looks like wiki pages have not been updated yet, e.g. this one I would > > > consider to be the main one: > > > > > > https://wiki.eclipse.org/Platform-releng/ > > > Platform_Build#cloning_platform_source_tree > > > > This page couldn't have been more outdated :) > > I did a first round of improvement to it > > https://wiki.eclipse.org/index.php?title=Platform- > > releng%2FPlatform_Build&type=revision&diff=444895&oldid=415383 but Build > > Output and Running tests sections are probably still wrong. I'm leaving them > > as they are for someone to improve them if interested. IMHO we should delete > > most of these sections. > > I wish in some future we could just remove such pages and put such > documentation in the aggregator repo directly. With such content in the wiki we are better without it IMHO. I see eclipse.platform.releng is also moved. This is now affecting Eclipse contributor workspaces, due to org.eclipse.test being empty in the old repository. Do you plan to send out an e-mail that the move is on-going? Or its better to notify everyone once everyone already knows the move has started? Mail sent. With that I consider aggregator repo move as being finished. |