History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: QB-3283
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Major Major
Assignee: Robin Shen
Reporter: Yoongeon Lee
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.

[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

Created: 29/Oct/18 04:14 PM   Updated: 21/Jan/19 02:06 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown
File Attachments: 1. Text File failed-Conflict.txt (57 kb)

Image Attachments:

1. Step.png
(6 kb)

2. Git repository Configuration.png
(71 kb)
(Build Agent) Windows 10 Enterprise x64
(User Agent) Windows 10 Enterprise x64

 Description  « Hide
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 " 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.

 All   Comments   Work Log   Change History      Sort Order:
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.

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 )

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.

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

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.

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

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