Improving CI for new packages and updates about hunter

[NeroBurner]

how and where are the changes in cmake/projects or examples detected? How do you decide which versions to compare?

[bkotzz]

How - using a git diff (name only) between the HEAD commit of the PR branch, and the merge base of the PR branch and the merge target (which is the master branch of this repo). Essentially the detected changes files should be identical to the changed files you see in the PR on github

Where - at the beginning of each build in the build matrix for Travis and appveyor jobs

Which versions - I think I answered that above, but let me know if something doesn’t make sense

[bkotzz]

A proposal for an intermediate step:

We have currently moved ingenue/hunter into the cpp-pm org here https://github.com/cpp-pm/hunter-testing. Again, this repo's only relation to hunter is that each branch contains the travis/appveyor build matrix for that package. It doesn't need to be a fork of hunter, because instead of merging the testing branches into feature branches, it's reasonable to do:

# On your feature branch

git remote add testing https://github.com/cpp-pm/hunter-testing
git fetch testing pkg.gtest
git checkout testing/pkg.gtest -- appveyor.yml
git checkout testing/pkg.gtest -- .travis.yml
git checkout -b gtest_test
git commit -m "Test gtest builds"
git push -u origin gtest_test

# As long as CI is enabled on your fork, go to travis/appveyor websites and track the relevant build job that you just kicked off

So instead of maintaining a repo with branches to hold the build matrices for each package, we could instead check them into https://github.com/cpp-pm/hunter as unused files. So for example, we would have cmake/projects/GTest/.travis.yml and cmake/projects/GTest/appveyor.yml. Then, if you wanted to run CI when updating gtest to a new version, you would do:

cp cmake/projects/GTest/.travis.yml .
cp cmake/projects/GTest/appveyor.yml .
git checkout -b gtest_test
git commit -m "Test gtest builds"
git push -u origin gtest_test

This would then mean that:

• To add a new package, you don't need a PR against the testing repo to create the branch for the new package
• For existing packages, you don't need to merge against another repo to run CI
• When updating packages, if a build in the build matrix starts/stops failing, you can comment/uncomment in the same PR against hunter that updates the package.

[NeroBurner]

GitLab released generated child pipelines. You can generate the jobs, that need to be triggered dynamically. So one job detects which examples need to be run, and a child pipeline then runs only for the changed project files
https://docs.gitlab.com/ee/ci/parent_child_pipelines.html#dynamic-child-pipelines

is there something like that in the github space?

[rbsheth]

Closed by #250