Change Details

= Problem = Continuous Integration is hard to set up for repositories in the Wikimedia environment. Often this will require changes to the `integration/config` repo (e.g. editing a huge YAML file) and whitelisting of users (who may otherwise be unable to trigger some Jenkins jobs via Gerrit). = Proposed solution = Travis CI //et similia// only require a simple YAML file in the root directory of each code repository. Supporting such model can greatly streamline the addition of CI to repositories managed by small volunteer teams, decrease reliance on third-party services and ease the work of the few employees dedicated to CI infrastructure. ---- **Steps to reproduce** * No steps since this is a feature request I discussed this on #wikimedia-releng and @mmodell thought it was a nice idea, he is the one who came up with the name for the file. But this will help us customise it per repo without needing to create a separate job. <twentyafterfour> paladox: it would be cool to do something similar to travis, with a test config file, indeed. What we will do is have a majour improvement over .travis-ci which will allow us to define multiple tests at the same time instead of being limited to 1. What this fixes is in phabricator it is much different to registering tests, to make things easy we could have one test and use that file to define the tests used and any customisation needed like customisaing an export variable or passing one. This will also allow us not to create separate tests for each repo. An example on how it will look project: - name: hi - php: - 7 - 5.6 - 5.5 - 5.4 - 5.3 - hhvm script: - composer test This is a mock and will need improvements to support extending our tests without making it complex.

= Problem = Continuous Integration is hard to set up for repositories in the Wikimedia environment. Often this will require changes to the `integration/config` repo (e.g. editing a huge YAML file) and whitelisting of users (who may otherwise be unable to trigger some Jenkins jobs via Gerrit). = Proposed solution = Travis CI //et similia// only require a simple YAML file in the root directory of each code repository. Supporting such model can greatly streamline the addition of CI to repositories managed by small volunteer teams, decrease reliance on third-party services and ease the work of the few employees dedicated to CI infrastructure. ---- I discussed this on #wikimedia-releng and @mmodell thought it was a nice idea, he is the one who came up with the name for the file. But this will help us customize it per repo without needing to create a separate job. <twentyafterfour> paladox: it would be cool to do something similar to travis, with a test config file, indeed. What we will do is have a major improvement over .travis-ci which will allow us to define multiple tests at the same time instead of being limited to 1. An example on how it will look ``` project: - name: hi - php: - 7 - 5.6 - 5.5 - 5.4 - 5.3 - hhvm script: - composer test ``` This is a mock and will need improvements to support extending our tests without making it complex.

= Problem = Continuous Integration is hard to set up for repositories in the Wikimedia environment. Often this will require changes to the `integration/config` repo (e.g. editing a huge YAML file) and whitelisting of users (who may otherwise be unable to trigger some Jenkins jobs via Gerrit). = Proposed solution = Travis CI //et similia// only require a simple YAML file in the root directory of each code repository. Supporting such model can greatly streamline the addition of CI to repositories managed by small volunteer teams, decrease reliance on third-party services and ease the work of the few employees dedicated to CI infrastructure. ---- **Steps to reproduce** * No steps since this is a feature request I discussed this on #wikimedia-releng and @mmodell thought it was a nice idea, he is the one who came up with the name for the file. But this will help us customiseze it per repo without needing to create a separate job. <twentyafterfour> paladox: it would be cool to do something similar to travis, with a test config file, indeed. What we will do is have a majour improvement over .travis-ci which will allow us to define multiple tests at the same time instead of being limited to 1. What this fixes is in phabricator it is much different to registering tests, to make things easy we could have one test and use that file to define the tests used and any customisation needed like customisaing an export variable or passing one. This will also allow us not to create separate tests for each repo. An example on how it will look An example on how it will look ``` project: - name: hi - php: - 7 - 5.6 - 5.5 - 5.4 - 5.3 - hhvm script: - composer test ``` This is a mock and will need improvements to support extending our tests without making it complex.