Amaury
Complete version of the viscous-inviscid interaction. It handles incompressible/compressible and attached/separated flows. The coupler used is the quasi-simultaneous interaction. The test case bliLiftComp computes a compressible flow around a NACA 0012. Various exemples are given in the header of the test case.
Merge request reports
Activity
added 238 commits
-
c6c791de...465d2d5d - 235 commits from branch
am-dept:feature_vii - e3d7a110 - Fix tests for the viscous-inviscd interaction
- d52e71fe - Fix tests for the viscous-inviscd interaction
- aa33290d - Fix tests for the viscous-inviscd interaction
Toggle commit list-
c6c791de...465d2d5d - 235 commits from branch
Looks like the pipeline is created in Amaury's repository, which has not access to mn2l's runners. Therefore, the pipeline cannot start and time outs.
@R.Boman any ideas to fix that without changing the gitlab-ci.yml? If not, I agree to "force" merge the changes once I have reviewed and tested them. There will be a pipeline when I will merge into master anyways...
As you say, the pipeline of forked projects do not have access to shared group runners (this is normal, otherwise, anyone could use the runners for any fork during each external commit and the runners would be continuously busy when the number of developers grows)
The problem is that the pipeline used for a MR is also run in the user space of the forked repository. This is a problem when people want to use a fork strategy with their project. It is discussed in this issue on gitlab.com. If I understand well, the reason is that there are many security issues. It would be possible to run any kind of malicious code on the shared runners (in particular scripts to retrieve private ssh keys for example). The gitlab issue is still open because there are many possibilities to fix this problem; each method leading to a different security problem. Anyway there could be options in the future to allow runners to be used on forked projects (at least for MRs)
When I saw your message yesterday, I was surprised and I thought it worked because Simon Février successfully did a MR from an external forked repo to PFEM one year ago. The pipeline worked correctly and everything worked fine. The difference was that he was defined as a "developer" of parent PFEM project. So he belonged to the group.
Thus, as a first try, I have just added Amaury to the parent waves repo. I am not able to rerun the pipeline but it could be done from Amaury's repo by performing one additional commit for example.
Another important remark: I see that the size of the forked repository is 90Mb. This size correspond to the additional commits that have been done in Amaury's branch. I have seen that several
.mshhave been commited then removed. Thus I think that it would be nice to merge this MR with a rebase so that we do not increase the size of waves by more than 50% for just a few additional text files.If the pipeline does not work using this strategy, we can manually merge Amaury's repo... but I still recommend a "rebase" instead of a merge due to the excessive size of the branch.
Edited by Boman Romain
-
@R.Boman if we squash the commits when merging, does it has the same effect than rebasing? Or am I missing something? Note that I already squashed merged branch
amauryintofeature_viito fix the conflicts before proceeding with this MR (this commit 465d2d5d).Edited by Adrien Crovato -
I have never used
merge --squash. I didn't know it even exist.After reading the doc,
merge --squashlooks like a rebase where all the commits are accumulated into a single one. The same result could be obtained with rebase. The difference is that the branch that is squashed remains where it is. If a rebase was used, the source branch would move upstream of the target branch.