 |
History
| Log In
|
|
|
|
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 ) 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.
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 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.
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 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 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
[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 
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.