132 lines
5.4 KiB
Markdown
132 lines
5.4 KiB
Markdown
# Merge Request tricks
|
|
|
|
By default, a Merge Request pipeline would only build PIKA with
|
|
autotools, meson and for Windows 64-bit (similarly to normal commits).
|
|
|
|
You might want to actually generate easy-to-install builds, in
|
|
particular if you want it to be testable for non-developers, or various
|
|
other reasons. Making a full flatpak or Windows installer can actually
|
|
be quite time-consuming on a personal computer.
|
|
|
|
☣️ We remind that these packages are built on-top of development code
|
|
(i.e. work-in-progress and potentially unstable codebase likely
|
|
containing critical bugs) with additional code which can be contributed
|
|
by anyone (any anonymous person is allowed to propose patches as merge
|
|
requests not only known team members).
|
|
Therefore you should always check the merge request changes before
|
|
running the code and never blindly trust that it is harmless. In any
|
|
case, run these builds at your own risk. ☢️
|
|
|
|
## Generating a Windows installer for merge request code
|
|
|
|
If you add the label `5. Windows Installer` in a MR, then trigger a
|
|
pipeline (for instance by rebasing), it will add a Windows installer
|
|
creation to the pipeline. Once the pipeline ends, the installer can be
|
|
found by:
|
|
|
|
- clicking the pipeline ID.
|
|
- In the "Distribution" stage, click the "win-installer-nightly" job.
|
|
- Then click the "Browse" button.
|
|
- Navigate to `build/installer/_Output/`.
|
|
- Then click the `pika-<version>-setup.exe` file to download the
|
|
installer.
|
|
|
|
## Generating a flatpak for merge request code
|
|
|
|
If you add the label `5. Flatpak package` in a MR, then trigger a
|
|
pipeline for instance by rebasing), it will add a flatpak creation to
|
|
the pipeline. Once the pipeline ends, the flatpak can be installed by:
|
|
|
|
- clicking the pipeline ID.
|
|
- In the "Pika" stage, click the "flatpak" job.
|
|
- Then click the "Browse" button.
|
|
- Click the `pika-git.flatpak` file to download it.
|
|
- Locally run: `flatpak install --user ./pika-git.flatpak`
|
|
It should propose you to install the flatpak, allowing you to test.
|
|
- After testing, you can uninstall with: `flatpak remove technology.heckin.PIKA//master`
|
|
|
|
## Reviewing MR branches
|
|
|
|
Reviewing merge requests on the Gitlab interface often leads to poor
|
|
review, because:
|
|
|
|
- It doesn't show tabs, trailing whitespaces and other space issues
|
|
which a well-configured CLI git would usually emphasize with colors.
|
|
- The commit history is not emphasized, only the final results, but it's
|
|
very important to check individual commits, as well as usable commit
|
|
messages.
|
|
- It's anyway usually much easier to review patches on your usual
|
|
workflow environment rather than in a hard-to-use web interface.
|
|
|
|
There are ways to work on your local environments.
|
|
|
|
### Fetching MR branches automatically (read-only)
|
|
|
|
This first one is more of a trick, but an incredibly useful one.
|
|
Unfortunately it is read-only, so it means you can review but not edit
|
|
the MR yourself. Nevertheless since having to edit a MR should be the
|
|
exception, not the rule, it's actually not too bad.
|
|
|
|
Edit your `.git/config` by adding a second "fetch =" rule to the
|
|
"origin" remote. It should read:
|
|
|
|
```
|
|
[remote "origin"]
|
|
fetch = +refs/heads/*:refs/remotes/origin/*
|
|
fetch = +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
|
|
url = git@ssh.gitlab.gnome.org:GNOME/pika.git
|
|
```
|
|
|
|
From now on, when you `git pull` or `git fetch` the origin remote, any
|
|
new or updated merge request will also be fetched. \o/
|
|
|
|
### Pushing to a third-party MR branch
|
|
|
|
There are cases when you want to push to the MR branch. It should stay
|
|
rare occasions, but it can be for instance when the contributor seems
|
|
stuck and doesn't know how to do some things; or maybe one doesn't
|
|
understand instructions; sometimes also some contributors disappear
|
|
after pushing their patch and never answer to review anymore.
|
|
|
|
When this happen, you could merge the commit and fix it immediately
|
|
after (but it's never good to leave the repo in a bad state, even for
|
|
just a few minutes). You could also apply, fix and push the fixed
|
|
commits directly, but then the MR has to be closed and it doesn't look
|
|
like it was applied (which is not the end of the world, but it's still
|
|
nicer to show proper status on which patches were accepted or not).
|
|
Moreover you would not be able to pass the CI build.
|
|
|
|
So we will fetch the remote yet without naming the remote:
|
|
|
|
- Click the "Check out branch" button below the merge request
|
|
description. Gitlab gives you instructions but we will only use the
|
|
first step ("Fetch and check out the branch for this merge request").
|
|
For instance if contributor `xyz` created the branch `fix-bug-123` on
|
|
their own remote, you would run:
|
|
|
|
```
|
|
git fetch "git@ssh.gitlab.gnome.org:xyz/pika.git" 'fix-bug-123'
|
|
git checkout -b 'xyz/fix-bug-123' FETCH_HEAD
|
|
```
|
|
|
|
- Now that you are in a local branch with their code, make your fix, add
|
|
a local commit.
|
|
|
|
- Finally push to the contributor's own remote with the call:
|
|
|
|
```
|
|
git push git@ssh.gitlab.gnome.org:xyz/pika.git xyz/fix-bug-123:fix-bug-123
|
|
```
|
|
|
|
This assumes that the contributor checked the option "*Allow commits
|
|
from members who can merge to the target branch.*" (which we ask
|
|
contributors to check, and it's set by default)
|
|
|
|
- Now check the MR page. It will normally be updated with your new
|
|
commit(s) and a new pipeline should be triggered.
|
|
|
|
- Finally if you don't need the local branch anymore, you may delete it
|
|
locally. The nice thing is that since you didn't name the remote, it
|
|
doesn't pollute your git output and all data will be simply disposed
|
|
of the next time `git gc` runs (implicitly or explicitly).
|
