Migration to GitHub #3
Replies: 1 comment
-
The simrel.build repository has auto-merge enabled.
It also has delete_branch_on_merge enabled: That setting is applicable for deleting branches in the simrel.build repository itself. But it's generally preferred that you create a branch in your fork. For auto-deleting a branch from your fork, you can configure the settings of your fork as follows: For this setting in particular: For those who would like to enable this for a different Eclipse repository, that can be done via otterdog. This is the configuration for simrel.build: Here I've highlighted the relevant parts for auto-merge. With this the process of completing a PR is simplified. As soon a the PR is opened, it's possible to select Enable auto-merge button: After confirming that you definitely want that, the PR will look like this: When the verification completes, and you have not enabled auto-delete, the PR will look like this: I.e., the selected merge action has automatically been applied. If your fork has been configured to auto-delete the branch, the PR will look like this: |
Beta Was this translation helpful? Give feedback.
-
The migration of SimRel to GitHub is mostly complete:
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3624
It is a work-in-progress with information still distributed across multiple sources.
The wiki is badly outdated. It is highly recommenced to create a fresh new development environment using the following link:
The page prompting for configuration information will look similar to this:
Please include your github account ID, i.e., where your fork will be located, so that you will be easily able to create pull requests with no additional configuration later. Note that you can use either ssh or https for commits to you fork; those choices are available in the dialog. The
main
branch protected from direct commits so you will necessarily be forced to create pull requests. Also, merge commits are blocked so please rebase properly and amend your commits if you need to make changes to your pull request after a previous commit.The resulting development environment will contains the clones, configured to create pull requests easily:
This configuration is recommend. You will be cloning the repo directly, not your fork, so you will never need to be concerned about keeping your fork in sync with the actual repository..
The workflow for managing your fork is as described here for the eclipse-platform:
https://github.com/eclipse-platform/.github/blob/main/CONTRIBUTING.md#creating-and-managing-a-fork
For those unfamiliar with pull requests here are some details that will hopefully be helpful. Before you start, be sure you have master checked out and do a pull:
Create a topic branch:
It doesn't matter what you call it:
Double click your
*.aggrcon
to open it in the editor. Double click anything in the editor to see its properties. Make your changes in the editor and save. You can validate the model via the context menu, before you commit the changes:This is obviously faster than waiting for a build!
Commit your changes to your topic branch. Use
Commit
notCommit and Push
which will fail because direct commits are blocked.Now you can push your topic branch, though you will need to configure it:
Choose the remote for your fork. I always change it to rebase as well:
A confirmation dialog will come up. Don't just close it! Click on the pull request link:
That will create a page were you can create your pull request via the big green button:
After a short while, the checks will start, including the verification build:
Please, please, please wait for it to complete successfully!
Of course it should never fail because you validated the model in the IDE before for pull request.
When the build complete in ~3 minutes, the page will look like this:
If you need to modify the changes, because you just don't listen, you can amend your commit and
Commit
again and then push your topic branch again, but this time force push it:The existing pull request will be updated and will start a new verification build:
Rinse, lather, repeat until the verification build is green. Then you can
Squash and merge
it:Probably you will want to delete your branch after the merge. I don't show that here because I did not actually merge this change...
Beta Was this translation helpful? Give feedback.
All reactions