On 4/19/21 11:40 AM, Daniel P. Berrangé wrote: > On Mon, Apr 19, 2021 at 01:34:47AM +0200, Philippe Mathieu-Daudé wrote: >> Forks run the same jobs than mainstream, which might be overkill. >> Allow them to easily rebase their custom set, while keeping using >> the mainstream templates, and ability to pick specific jobs from >> the mainstream set. >> >> To switch to your set, simply add your .gitlab-ci.yml as >> .gitlab-ci.d/${CI_PROJECT_NAMESPACE}.yml (where CI_PROJECT_NAMESPACE >> is your gitlab 'namespace', usually username). This file will be >> used instead of the default mainstream set. > > I find this approach undesirable, because AFAICT, it means you have > to commit this extra file to any of your downstream branches that > you want this to be used for. Then you have to be either delete it > again before sending patches upstream, or tell git-publish to > exclude the commit that adds this.
Good point. What I'm looking for is allow fork to keep following the mainstream development. > IMHO any per-contributor overhead needs to not involve committing > stuff to their git branches, that isn't intended to go upstream. But why am I forced to run the upstream overhead stuff into my fork? I find it counter-productive for my limited set of topic I'm modifying. Also, why should I wait >2h for a pipeline when I exactly know which area I'm modifying? This is a waste of time and resources. Gitlab suggested an alternative 3 months ago, it is still fresh: https://docs.gitlab.com/ee/ci/yaml/README.html#variables-with-include combined with https://docs.gitlab.com/ee/ci/yaml/README.html#includeremote and https://docs.gitlab.com/ee/ci/yaml/README.html#multiple-files-from-a-project we could have forks include their gitlab-ci.yml from a specific branch of their repository. Example, if I push a branch named project-specific-ci, and we add that to mainstream: include: - project: '$CI_PROJECT_PATH' ref: project-specific-ci file: - '/.gitlab-ci.d/project-specific.yml' The it would include project-specific-ci:/.gitlab-ci.d/project-specific.yml in all branches/tags I push. In that case we could rename qemu-project.yml -> project-specific.yml (patch 12). The problem is I couldn't have it optionally working (when there is no 'project-specific-ci' branch). Still room for investigation... Thanks for the feedback, Phil.