Lazarus Team - Git Workflows: what changed
Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.
| Old | New | Line | |
|---|---|---|---|
| 1 | 1 | This page contains workflows for Lazarus team members, when working with GIT. | |
| 2 | 2 | ||
| 3 | 3 | # git pull --rebase | |
| 4 | 4 | ||
| 5 | 5 | Commits made by team members should have a linear history | |
| 6 | 6 | ||
| 7 | 7 | If you have local commits to push, and the remote branch has new commits too, then use **rebase**. Do not create any merge commits. | |
| 8 | 8 | ||
| 9 | 9 | ` git pull --rebase` | |
| 10 | 10 | ||
| 11 | 11 | or | |
| 12 | 12 | ||
| 13 | 13 | ` git rebase` | |
| 14 | 14 | ||
| 15 | 15 | ------------------------------------------------------------------------ | |
| 16 | 16 | ||
| 17 | 17 | See also [[SVN to GIT Cheatsheet|SVN_to_GIT_Cheatsheet#Recommended]] | |
| 18 | 18 | ||
| 19 | 19 | # Merge Requests / Pull Requests | |
| 20 | 20 | ||
| 21 | 21 | Merge requests should be included by creating a merge commit | |
| 22 | 22 | ||
| 23 | 23 | ` git merge merge-request/foo` | |
| 24 | 24 | ||
| 25 | 25 | > **Note:** To pull merger request to your local git: <https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#checkout-locally-by-modifying-gitconfig-for-a-given-repository> | |
| 26 | 26 | ||
| 27 | - | ||
| 28 | 27 | ---- | |
| 29 | 28 | ||
| 30 | 29 | Merge-requests can be (optionally / recommended, if the fork-point is way back) rebased first. Within the gitlab merge-request website, this can be done adding a comment | |
| 31 | 30 | ||
| 32 | 31 | ` /rebase` | |
| 33 | 32 | ||
| 34 | 33 | # Cherry picking / Merging | |
| 35 | 34 | ||
| 36 | 35 | Do not "squash" commits when cherry picking. | |
| 37 | 36 | ||
| 38 | 37 | If commits are squashed, then ["git cherry"](https://git-scm.com/docs/git-cherry) wont work. | |
| 39 | 38 | ||
| 40 | 39 | Use | |
| 41 | 40 | ||
| 42 | 41 | ` git cherry pick -x` | |
| 43 | 42 | ||
| 44 | 43 | The "-x" adds "cherry picked from commit" | |
| 45 | 44 | ||
| 46 | 45 | # ".gitattributes" - Adding new file extensions | |
| 47 | 46 | ||
| 48 | 47 | > **Warning:** Adding new extensions can have unwanted side effects on existing file. | |
| 49 | 48 | ||
| 50 | 49 | If you add files with an new extension (not yet covered by .gitattributes) then it is best to add that extension (or the concrete file) | |
| 51 | 50 | ||
| 52 | 51 | Files not covered by .gitattributes will be left to git figuring out on its own, if they are text. Since this affects line endings, it is best to tell git, what we want the file to be. | |
| 53 | 52 | ||
| 54 | - | ||
| 53 | + | After editing .gitattributes you must run (before committing): | |
| 55 | 54 | ||
| 56 | 55 | ` git add --renormalize .` | |
| 57 | 56 | ||
| 58 | 57 | Then check **git status** which files were affected. | |
| 59 | 58 | ||
| 60 | 59 | # Issue Tracker | |
| 61 | 60 | ||
| 62 | 61 | ## Milestone | |
| 63 | 62 | ||
| 64 | 63 | When closing an issue, ensure to set the correct milestone. | |
| 65 | 64 | ||
| 66 | 65 | If the issues is (or will be) merged to a fixes branch, set the milestone for the fixes release. (If the merge later fails, the milestone must be amended). | |
| 67 | 66 | ||
| 68 | 67 | If you do not merge (cherry pick) yourself: | |
| 69 | 68 | ||
| 70 | 69 | - leave the issue open | |
| 71 | 70 | - Set the fixes milestone | |
| 72 | 71 | - add the label | |
| 73 | 72 | ||
| 74 | 73 | ||
| 75 | 74 | ||
| 76 | 75 | merge::merge-and-close | |
| 77 | 76 | ||
| 78 | 77 | # Continuous integration (CI) System | |
| 79 | 78 | ||
| 80 | 79 | On every commit and every update to merge requests continuous integration (CI) system creates a pipeline, which builds Lazarus for several platforms/widgetsets. If the build fails, it notifies the creator of commit which caused the failure. | |
| 81 | 80 | ||
| 82 | 81 | The building process happens in a virtual machine (Docker container), which loads an operating system image. Our image is based on Debian 12 x86_64 and at the time of writing this section contains: | |
| 83 | 82 | ||
| 84 | 83 | - GTK2, GTK3, Qt5, Qt6 libraries; | |
| 85 | 84 | - FPC (versions 3.2.0 \[oldstable\], 3.2.2 \[stable\], 3.2.3 \[fixes\], 3.3.1 \[main\]) for the following targets: | |
| 86 | 85 | - x86_64-linux; | |
| 87 | 86 | - x86_64-win64 (cross-compiler); | |
| 88 | 87 | - i386-win32 (cross-compiler); | |
| 89 | 88 | - Pas2JS compiler (Git snapshot, compiled with FPC main compiler/sources). | |
| 90 | 89 | ||
| 91 | 90 | Docker image configuration is defined in *buildenv.Dockerfile* file, and pipeline configuration is defined in *.gitlab-ci.yml* (both files are located in Lazarus root directory). | |
| 92 | 91 | ||
| 93 | 92 | At the time of writing this section our pipeline consists of four stages: | |
| 94 | 93 | ||
| 95 | 94 | 1. Update our Docker image (see above). This process can be triggered manually in **Build**-\>**Pipelines** page by running **update-build-env** job of the first manual stage of the most recent pipeline belonging to *main* branch (rebuilding process takes ~23 min). It should be run in the following cases: | |
| 96 | 95 | 1. When there is a desire to simply update FPC fixes and main snapshots. It is safe if FPC versions haven't changed in the meantime (in rare cases rebuilding process (FPC snapshots compilation) may fail, re-run the job in this case). It is enough to just run the job (no variables need to be defined), the image will be updated automatically and will include FPC snapshots at the time of rebuilding of image. | |
| 97 | 96 | 2. When *buildenv.Dockerfile* and/or FPC version constants in *.gitlab-ci.yml* file have been changed. **Do with care!** | |
| 98 | 97 | 2. Clear Qt5Pas/Qt6Pas bindings caches if (and only if) any file in bindings is changed. Reasons to keep this stage separate from updating Qt5Pas/Qt6Pas bindings: | |
| 99 | 98 | 1. Cache actually contains all files from bindings directory (both source and object ones) and is extracted after checkout, so it overwrites checked out sources, and thus prevents correct cache update if not cleared appropriately. | |
| 100 | 99 | 2. Sources should be kept in cache, as removing them will cause bindings to be always recompiled (both in bindings and IDE compile jobs). It takes long time and thus undesirable. | |
| 101 | 100 | 3. Simply doing full cache rebuild if any file in bindings is changed is not enough as this job will not be triggered e. g. for a new merge request (if it does not modify bindings) and will cause IDE compile jobs for it to fail. GitLab CI currently does not support conditions for triggering a job if a cache is missing. | |
| 102 | 101 | 3. Update Qt5Pas/Qt6Pas bindings and cache results of these jobs. They are required for subsequent building of Lazarus with Qt5 and Qt6 widgetsets. This is needed because building both Qt5 and Qt6 bindings takes a long time (~25 min) and they are rarely changed. | |
| 103 | 102 | 4. Build Lazarus for various widgetsets/platforms. The following jobs for building Lazarus are defined: | |
| 104 | 103 | - x86_64-gtk2 bigide (oldstable, stable, fixes, main FPC); | |
| 105 | 104 | - x86_64-gtk3 bigide (oldstable, stable FPC); | |
| 106 | 105 | - x86_64-qt5 bigide (oldstable, stable FPC); | |
| 107 | 106 | - x86_64-qt6 bigide (oldstable, stable FPC); | |
| 108 | 107 | - x86_64-win64 bigide (oldstable, stable FPC); | |
| 109 | 108 | - i386-win32 bigide (oldstable, stable, fixes, main FPC); | |
| 110 | 109 | - Documentation (stable, fixes, main FPDoc); | |
| 111 | 110 | - Tests for Codetools (main FPC). | |
| 112 | 111 | ||
| 113 | 112 | At the time of writing this section the following jobs for building Lazarus run automatically on every commit: | |
| 114 | 113 | ||
| 115 | 114 | - x86_64-gtk2 bigide (stable FPC); | |
| 116 | 115 | - x86_64-gtk3 bigide (stable FPC); | |
| 117 | 116 | - x86_64-qt5 bigide (oldstable FPC); | |
| 118 | 117 | - x86_64-qt6 bigide (stable FPC); | |
| 119 | 118 | - i386-win32 bigide (stable FPC); | |
| 120 | 119 | - Tests for Codetools (main FPC). | |
| 121 | 120 | ||
| 122 | 121 | All others can be triggered manually via GitLab web interface. | |
| 123 | 122 | ||
| 124 | 123 | In GitLab web interface you can notice **Build** menu item at the left. By clicking **Build**-\>**Pipelines** you will get to pipelines list, where you can see build status for each commit. By clicking circles in the **Stages** column you will get to submenus which will show status of all jobs and will allow to run/rerun them manually (by clicking at **play**/**retry** button) and to look at job's log (by clicking at job's name). | |
| 125 | 124 | ||
| 126 | 125 | Important notice for Qt5/Qt6 jobs: | |
| 127 | 126 | ||
| 128 | 127 | They use cached results from stage 3. In absolute majority of the builds this should not cause any problems. But still if stage 3 does not pass or if you get Qt5/Qt6 widgetset build failure related to Qt5Pas/Qt6Pas version mismatch or missing cache, make sure to go to the **Pipelines** page and do the following: | |
| 129 | 128 | ||
| 130 | 129 | 1. Stop the currently running pipeline if needed. | |
| 131 | 130 | 2. Press **Run pipeline** button (you will be asked about defining variables, just skip this step (we don't use them) and confirm running pipeline). | |
| 132 | 131 | 3. In case pipeline failed to pass, press **Clear runner caches** button and then rerun pipeline by pressing **Run pipeline** button again. | |
| 133 | 132 | ||
| 134 | 133 | --- | |
| 135 | 134 | *From the Free Pascal wiki, page "Lazarus Team - Git Workflows", as it stood on 2023-11-22 after a change by Maxim, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).* | |
| 136 | 135 | Category: Lazarus | |
| 137 | 136 | Category: Revision control | |
| 138 | 137 | Category: SOPs |