> I don't know what you mean exactly. Do you mean you want to test the code that will result after the merge instead of the commit in the feature branch? It would be a nice option to test the merge of the feature branch with master instead of the feature branch itself (you will have to retest all MR’s every time master is updated). BTW The new build trigger API (to be released in a month) is one of the upcoming features that will allow more build customisation.
No, I want to trigger additional types of tests under two circumstances:
- When a merge request is created
- When additional commits are added to a branch for which a merge request exists
The utility is: I don't want to run integration tests if someone is just pushing to a feature branch - that takes up worker time. But I do want to run integration tests before that feature branch gets merged upstream. Achieving this by having everyone submit merge requests to an intermediate branch doesn't work, because we don't know the integration test result until after the merge to the intermediate branch is done, meaning developers might be trying to push a bunch of failing code to the same branch, just to get integration tests to run.
> But I do want to run integration tests before that feature branch gets merged upstream.
Specifically, the integration tests should run against the version of the source code in the feature branch that the merge request is about. The target branch can be merged into the feature branch to have full coverage of the post-merge status, so the target branch's importance is really minimal here.
> Yes, it would be a nice option to test the merge of the feature branch with master instead of the feature branch itself (you will have to retest all MR’s every time master is updated).
Actually no, that's not what I was trying to get at. The tests just have to run against the version of the source code in the feature branch. If the integration tests need to cover anything else, it should be inserted into the feature branch manually. Stale branches are their own problem and are quite common, independent of CI-related testing. Running unit tests all the time is fine, but it would be nice if special additional tests can be triggered only for new merge requests and for updated merge request source branches but not feature branch pushes unassociated with merge requests.
Yes, it would be a nice option to test the merge of the feature branch with master instead of the feature branch itself (you will have to retest all MR’s every time master is updated).
No, I want to trigger additional types of tests under two circumstances:
- When a merge request is created
- When additional commits are added to a branch for which a merge request exists
The utility is: I don't want to run integration tests if someone is just pushing to a feature branch - that takes up worker time. But I do want to run integration tests before that feature branch gets merged upstream. Achieving this by having everyone submit merge requests to an intermediate branch doesn't work, because we don't know the integration test result until after the merge to the intermediate branch is done, meaning developers might be trying to push a bunch of failing code to the same branch, just to get integration tests to run.