Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Platform-releng/Migration To GitHub"

(→‎Build Process)
Line 66: Line 66:
 
* ... [Please add more missing items] ...
 
* ... [Please add more missing items] ...
  
−
== Build Process ==
+
== Changing build Process ==
 +
 
 
* We have build scripts available [https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/mbscripts here]. In theory if you trigger [https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/master-build.sh master-build.sh] script you should get a eclipse, equinox and update site along with reports should get created in [https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/siteDir siteDir] folder. But this is broken. This would be a good starting point to understand how the repos are cloned, tagged and how generation reports are done.
 
* We have build scripts available [https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/mbscripts here]. In theory if you trigger [https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/master-build.sh master-build.sh] script you should get a eclipse, equinox and update site along with reports should get created in [https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/cje-production/siteDir siteDir] folder. But this is broken. This would be a good starting point to understand how the repos are cloned, tagged and how generation reports are done.
−
* Only build the bundle that was changed and not build the whole IDE
 
−
[Sravan] Excellent idea. this also eliminates use of comparator. Here are the steps we are doing now.
 
−
# Calculate qualifier based on last commit timestamp in UTC(in Eastern time for features)
 
−
# Build the bundle with the usual process.
 
−
# Check if we have this particular bundle with same version along with qualifier in the existing comparator repository(called baseline. Do not get confused here there are multiple baselines used across releng. lets call this as comparator baseline)
 
−
# If not that is the end of building the bundle.
 
−
# If exists, dissemble all the class files in the newly built bundle and from the comparator baseline.
 
−
# Compare the all the files(including disassembled class files) in the bundle ignoring signing changes.
 
−
# If changes are found throw comparator error
 
−
# Replace newly built bundle with the bundle from comparator baseline. Note this happens always even when we don't have any comparator errors.
 
−
 
−
Here are some bugs recently I handled in this area
 
−
{{bug|571840}}
 
−
 
−
Another thing to note here is when we change compiler(this happens atleast once per milestone), there will be changes to generated class files. How can we report these issues?
 
  
 
== Other noteworthy items ==
 
== Other noteworthy items ==

Revision as of 05:41, 11 March 2021

This page is meant to capture ideas, concerns, evaluations, experimentations... that can help the Platform project in moving to GitHub.

Goal

Attract more contributors by using a more known workflow on a popular Platform

Workflow

  • Which requirements do we have on the workflow? E.g. how should the history look like?
  • How do the current workflow and the GitHub workflow an compare?
  • How should the GitHub workflow be used?

Requirements

  • Each commit or merge to master is reviewed
  • Each commit (either by direct commit or merge) in master is reviewed separately
  • Master has a linear history (i.e. only fast forward merges)?

There are multiple Git workflows possible to implement the required behavior.

Gerrit Workflow

  • Create commit with Change-Id FooBar
  • Push to Gerrit
  • Review
  • Amend commit with Change-Id FooBar
  • Rebase commit on master HEAD
  • Merge commit with Change-ID FooBar to master

Possible GitHub workflow

  • Create a branch FooBar
  • Push commits to branch FooBar
  • Create a pull request to master
  • Review
  • Push more commits to branch FooBar
  • Merge master HEAD into FooBar
  • Squash and merge branch FooBar into master to create a single commit in master


Concerns

Moving to GitHub is an opportunity but also has drawbacks:

  • GitHub code review is not perceived by some committers as good as Gerrit
  • GitHub issue tracker is not perceived by some committers as usable at the scale of Platform project (lack of depends on/blocks/clone relations, difficulty to list attachements, linked patches...)
  • The process for contributing to Eclipse project via GitHub is currently cumbersome and not productive enough for new contributors (Signed-Off-By requirement cause a lot of noisy descripton and some contributions are abandoned)
  • ... [Please add more missing items] ...

Plan

  1. Get rid of the "signed-off by" requirement
  2. Move the main repo to GitHub
  3. Allow contributions through issues and PR's
  4. Tie PR's to Gerrit Changes and Issues to Bugzilla's

What needs to be done?

Generally

  • Build scripts need to be able to manipulate (add tag to) GitHub repositories
  • ... [Please add more missing items] ...

For each repository

  • Some GitHub actions and/or Jenkinsfile need to be added to trigger CI builds
  • The aggregator repository needs to change its submodule reference
  • The build scripts need to add tags to the GitHub repo
  • PMI info needs to be changed
  • ... [Please add more missing items] ...

Changing build Process

  • We have build scripts available here. In theory if you trigger master-build.sh script you should get a eclipse, equinox and update site along with reports should get created in siteDir folder. But this is broken. This would be a good starting point to understand how the repos are cloned, tagged and how generation reports are done.

Other noteworthy items

Retrieved from "https://wiki.eclipse.org/index.php?title=Platform-releng/Migration_To_GitHub&oldid=442596"

Back to the top