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 "EDT:How to commit code to EDT"

(Builds)
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Bugzilla bugs are mandatory ==
+
== Bugzilla bugs are mandatory ==
  
Every change we commit <span style="color:#FF0000">'''''MUST'''''</span> have a corresponding bug or enhancement in Bugzilla. Be sure the Target Milestone is set correctly.  
+
Every change we commit <span style="color:#FF0000">'''''MUST'''''</span> have a corresponding bug or enhancement in Bugzilla. Be sure to set the bug's Target Milestone correctly.  
  
When you resolve a bug, you <span style="color:#FF0000">'''''MUST'''''</span> list the files that you changed.  Either type in the file names or attach a screenshot that shows the changes.
+
== Git commit messages are mandatory ==
  
== Git commit messages are mandatory  ==
+
You <span style="color:#FF0000">'''''MUST'''''</span> enter a message when you commit a change to Git. The message <span style="color:#FF0000">'''''MUST'''''</span> include the number of the Bugzilla bug or enhancement.
  
You <span style="color:#FF0000">'''''MUST'''''</span> enter a message when you commit a change to Git. The message <span style="color:#FF0000">'''''MUST'''''</span> include number of the Bugzilla bug or enhancement.
+
Commit messages should be concise. It's best to say ''why'' you made the change, as opposed to saying ''what'' you changed.  
 
+
Commit messages should be concise. It's best to say why you made the change, as opposed to saying what you changed.  
+
  
 
*Bad: "Bug 12345 - Fixed."  
 
*Bad: "Bug 12345 - Fixed."  
Line 15: Line 13:
 
*Best: "Bug 12345 - The input to the gas pump must be in gallons, not quarts."
 
*Best: "Bug 12345 - The input to the gas pump must be in gallons, not quarts."
  
== File encoding  ==
+
If you want to write more about your changes, do it in Bugzilla.
 +
 
 +
== Links between bugs and fixes are mandatory ==
  
We use the UTF-8 encoding for all of our files. Set your workspace's Text File Encoding preference to UTF-8.  
+
When you resolve a bug, you <span style="color:#FF0000">'''''MUST'''''</span> include the ID of your fix's Git commit. If there's more than one commit, include all of their IDs.
  
== Timing  ==
+
The easiest way to find the ID of a commit is with the Git Reflog view, which lists the commits in a particular branch. Double-click on your commit to open it in the Commit Viewer. Right-click on the ID at the top of the Commit Viewer and choose Copy SHA-1.
  
Our Nightly builds run twice a day: at 9 AM and 9 PM Eastern U.S. time.  
+
[[Image:copySHA1.png]]
  
== Which files are included in the build  ==
+
Now you can paste the commit ID into Bugzilla.
  
Builds don't simply compile the latest code from CVS. A special file called a map file identifies the plugins to be built. There's an entry for each plugin naming the CVS tag for that plugin's code. (A CVS tag is simply a label on a particular version of a file.) The build will include the tagged files from each plugin in the map file. This means that to get a change into the build, you must commit your file to CVS, put a new tag on it AND all of the other files in the plugin, and update the map file with the new tag. That's a lot of work, which is why people have written a tool to automate most of the process.
+
== File encoding ==
  
The tool is in the org.eclipse.releng.tools plugin. You can find it by going to http://download.eclipse.org/eclipse/downloads if you use the most recent version of Eclipse, or http://archive.eclipse.org/eclipse/downloads/index.php if you use an older version of Eclipse. Click on the link for the release you're using and you'll find org.eclipse.releng.tools at the bottom of the page. To install it, unzip it into your dropins folder and restart Eclipse.  
+
We use the UTF-8 encoding for all of our files. Set your workspace's Text File Encoding preference to UTF-8. The preference is on the General > Workspace preference page.
  
You need to check out the org.eclipse.edt.releng plugin from CVS, because it contains our map file. (Releng is short for "release engineering". Most of the files that control EDT builds are in org.eclipse.edt.releng.)
+
== Builds ==
  
To release a change into the build follow these steps:
+
Our Nightly builds run twice a day, at 9 AM and 9 PM Eastern U.S. time. If no changes were made since the last build, then a new build is not produced.
  
#Select all plugins that have uncommitted changes, and org.eclipse.edt.releng.
+
Builds for milestones and releases run as needed.
#Right click (while on any selected plugin) and chose Team-&gt;Synchronize with Repository. This step makes sure you are getting the latest map file and checks for any conflicts before you commit.
+
#In the Team Synchronizing perspective, commit your changes and at the same time update changes from other developers into your workspace. Perform merges if needed.
+
#Go back to the Java Perspective. If there are any errors, correct them and go back to step 1.
+
#With the same set of plugins from step 1 still selected, you are now ready to Team-Release them. Right click (while on any selected plugin) and select Team-&gt;Release....
+
#The Release wizard is displayed. Select "Specify the map project you want to use" and select org.eclipse.edt.releng. Click Next.
+
#The wizard displays the list of projects in your workspace that have entries in the map file. In the Project Selection Dialog, verify that the plugins with your changes are checked in the Project Selection dialog. Click Next.
+
#Specify a release tag for your changes. Your project(s) will be tagged with this tag and the map file will be updated with it as well. The format of a tag should be 'v' followed by a timestamp in YYYYMMDDHHMM format, using 00 to 23 for the hour. For example, the tag for changes made on December 21st 2012, at 11:59pm is v201212212359. The timestamp must be in the Eastern U.S. timezone. If you're located elsewhere, go to http://www.timeanddate.com/worldclock/city.html?n=179 for the current time in New York.
+
#The next page allows you to view the changes to the map file. Click Finish. You don't have to enter a comment when committing a change to the map file.
+
  
Note: do not use Team-&gt;Release if you're making changes to org.eclipse.edt.releng or the widget projects<br>org.eclipse.edt.rui.dojo_*<br>org.eclipse.edt.rui.dojo.remote_*<br>org.eclipse.edt.rui.dojo.runtime.local_*<br>org.eclipse.edt.rui.dojo.runtime.remote_*<br>org.eclipse.edt.rui.dojo.widgets_*<br>org.eclipse.edt.rui.widgets_* <br>
+
== Which files are included in the build ==
  
The widget projects are used to create the RUI widget libraries during the build, but they're not shipped as plugins. They're not listed in the map file. The build includes their latest code from HEAD.  
+
Our builds compile the latest code from the ''master'' branch. There are also a few projects which are not compiled, but are used during the build. For example, we have a set of projects which contain the .egl and .js files for our widgets. The build creates the RUI widget libraries from them.
  
 
[[Category:EDT]]
 
[[Category:EDT]]

Latest revision as of 08:47, 21 August 2012

Bugzilla bugs are mandatory

Every change we commit MUST have a corresponding bug or enhancement in Bugzilla. Be sure to set the bug's Target Milestone correctly.

Git commit messages are mandatory

You MUST enter a message when you commit a change to Git. The message MUST include the number of the Bugzilla bug or enhancement.

Commit messages should be concise. It's best to say why you made the change, as opposed to saying what you changed.

  • Bad: "Bug 12345 - Fixed."
  • Better: "Bug 12345 - Added quartsToGallons() on calls to pumpGas()."
  • Best: "Bug 12345 - The input to the gas pump must be in gallons, not quarts."

If you want to write more about your changes, do it in Bugzilla.

Links between bugs and fixes are mandatory

When you resolve a bug, you MUST include the ID of your fix's Git commit. If there's more than one commit, include all of their IDs.

The easiest way to find the ID of a commit is with the Git Reflog view, which lists the commits in a particular branch. Double-click on your commit to open it in the Commit Viewer. Right-click on the ID at the top of the Commit Viewer and choose Copy SHA-1.

CopySHA1.png

Now you can paste the commit ID into Bugzilla.

File encoding

We use the UTF-8 encoding for all of our files. Set your workspace's Text File Encoding preference to UTF-8. The preference is on the General > Workspace preference page.

Builds

Our Nightly builds run twice a day, at 9 AM and 9 PM Eastern U.S. time. If no changes were made since the last build, then a new build is not produced.

Builds for milestones and releases run as needed.

Which files are included in the build

Our builds compile the latest code from the master branch. There are also a few projects which are not compiled, but are used during the build. For example, we have a set of projects which contain the .egl and .js files for our widgets. The build creates the RUI widget libraries from them.

Back to the top