| << Back to previous view |
|
[QB-3283] [Git Proof Build] the critical issues occur in a local repository where the user agent is running while developers run the proof build with their commits
|
|
| Status: | Closed |
| Project: | QuickBuild |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Yoongeon Lee | Assigned To: | Robin Shen |
| Resolution: | Won't Fix | Votes: | 0 |
| Remaining Estimate: | Unknown | Time Spent: | Unknown |
| Original Estimate: | Unknown | ||
| Environment: |
(Build Agent) Windows 10 Enterprise x64
(User Agent) Windows 10 Enterprise x64 |
||
| File Attachments: |
3.0.0.2372-Clone Step.png
3.0.0.2372_Proof failed-Conflict.txt
Git repository Configuration.png
|
| Description |
|
We have been using Git and GitHub with connecting to CI-QBuild.
Our developers are merging source code into the main repository through the proof build provided by qbuild. The developers typically run a proof build and then continue with code development on another branch like develop_feature1, develop_feature2 and so on. In that case, the following critical issues occur in a local repository where the user agent is running. 1) The developer made a new commit in "develop" branch and then ran the proof build with the commit. 2) Next, developer changes another branch "develop_feature1" using "git checkout" command and continue with code development on it. 3) The following commands were executed sequentially in the developer local repository where the user agent was running - git fetch origin develop - git merge FETCH_HEAD 4) A lot of conflicts occurred during merging FETCH_HEAD. Those commands should be run in the develop branch, NOT develop_feature1 ( current working branch ) Error message) ( * please refer to the log "3.0.0.2372_Proof failed-Conflict") Step 'Clone a Repository Into Build Server' is failed: Merge conflicts found. Please fix conflicts and merge first, then run the proof build again. |
| Comments |
| Comment by Yoongeon Lee [ 29/Oct/18 04:41 PM ] |
|
One more issue,
If a new commit is updated in the remote main repository by another developer "B" while the proof build is running by the developer "A", the proof build fails. I think if there is no conflict between commits and the commit by developer "A" should be pushed to the main repository without any problem. We have more than 10~20 changes occur in git repository per sw product. If more than 10 changes are queued, only first commit succeeds, and the other remaining commits fail. Error log) error: failed to push some refs to 'git@3dgit.3dsystems.com:3DSprint/3d-sprint.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. |
| Comment by Yoongeon Lee [ 29/Oct/18 05:02 PM ] |
|
To solve these problems, I set the push condition as false in repository configuration, and add the steps to the proof workflow manually. ( like git checkout current branch, git fetch, git rebase --autostash...). However it is not a complete solution.
I think our git proof build seems to be very unstable. It is extremely dangerous for a user agent to fetch and merge in the developer repository. Please let me know if there is a way to run all steps for merging commits on the Build Agent. ( From git clone To git push ) |
| Comment by Robin Shen [ 30/Oct/18 12:13 AM ] |
| This is a limitation of proof build. Proof build will operate on the local repository directly and user needs to wait for proof build to complete before switching to other branch. For Git/GitHub development, it is suggested to use pull request instead of proof build to run verification builds before merging user code into main branch. |
| Comment by Yoongeon Lee [ 30/Oct/18 08:12 AM ] |
|
Can you explain a little bit more about how to set the pull request you mentioned?
Do you have more detailed documentation than the link below? I would like to check it ASAP. - https://wiki.pmease.com/display/QB51/Working+with+GitHub |
| Comment by Robin Shen [ 30/Oct/18 11:28 PM ] |
| It means your team member needs to push their changes to feature branches at GitHub side, and then send a pull request at GitHub side to request to merge the change to master branch. Then QB is pull request enabled will verifying the feature branch automatically. After verification, the pull request can then be accepted to master branch via GitHub interface. |
| Comment by Yoongeon Lee [ 01/Nov/18 11:28 AM ] |
|
As I understood, the developer pushes his commit manually to his branch and requests a pull request manually.
If pull request is enabled on repository configuration, QB downloads the main branch and the developer branch, and then QB applies the developer branch to main branch of remote repository automatically after verification(we already defined) is complete. right? We need more information about 5 options of Pull requests in GitHub repository. 1) All Opened Pull Requests 2) All Closed Pull Requests 3) Pull requests with title filter 4) Specified Pull Requests 5) Pull Requests with body filter 6) Pull Requests with label filter |
| Comment by Robin Shen [ 01/Nov/18 11:34 PM ] |
|
When a pull request is created, GitHub will merge developer branch and main branch. QB then will verify this merged result (if pull request of type MERGE is specified at QB side). Options explained as below:
1. All open pull requests: build all open pull requests 2. All closed pull requests: build all closed pull requests 3. Pull requests with title filter: build all pull requests with title matching specified criteria 4. Specified pull requests: build specified pull request 5. Pull requests with body filter: build pull requests with description matching specified criteria 6. Pull requests with label filter: build pull requests with label matching specified criteria |