[Twisted-Python] Only run Azure, Travis, or CircleCI if GitHub actions pass
Adi, Is it possible to configure the CI so that Azure, Travis and CircleCI only runs if GitHub actions pass? For example here: https://github.com/twisted/twisted/runs/1137175269 *Azure Pipelines* and *Travis* should only run if the GitHub actions pass. -- Craig
On Sat, 19 Sep 2020 at 21:30, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
I think that is partially possible...but complicated. My question: Why does Twisted need Azure Pipelines (sharing infastructure with GihutActions), Travis-CI and Circle-Ci. Why can't Twisted just use GitHub actions? You can trigger one GitHub action workflow from another workflow, or everything as depende jobs inside one workflow. GitHub Action API is pretty good. I was able to implement a quick hack which sends a diff to GitHub and executes a test without a commit, just like Builbot Try [3]. I don't know how to implement something similar with Travis or Circle-Ci. --------- Travis-CI builds can be triggered over the HTTP API [1]...but I feel that implementing it is complicated. There should be a dedicated token... which should be created by a person, and then stored as a secret in GttHub Actions. I don't know how to trigger Circle-CI .. here is some info here [2] but looks like it will be deprecated I don't know how to trigger Azure Pipelines. but I guess that at some point MS will kill Azure Pipelines [1] https://docs.travis-ci.com/user/triggering-builds/ [2] https://circleci.com/docs/2.0/api-job-trigger/ [3] https://asciinema.org/a/nn1U7FLtbyWm57b0dT7U5sKD0 -- Adi Roiban
My question is: why would we want to do this? It seems like it would just make it slower to get feedback for contributors.
In a word: capacity. We have a large test matrix and more services = more parallel builds. The calculus on this is changing all the time; the amount of free stuff that Github Actions gives us has substantially increased, other services have stood still, things that used to be special dispensations for extra parallel builds are now just the default, we test on fewer kernels than we used to (no FreeBSD, for example). If we no longer get a substantial capacity benefit from using multiple services, we should definitely simplify and unify on one service.
On Sun, Sep 20, 2020 at 9:22 PM Glyph <glyph@twistedmatrix.com> wrote:
If some jobs such as lint or mypy fail first quickly, then there is no point in running the full test suite. That would give feedback faster to contributors that they need to do some minor fixes, before wasting cycles running the full test suite. When CI using Azure Pipelines was implemented for Twisted, Azure Pipelines offered runners that ran on Windows which seemed to be more reliable than Appveyor (which was what was used at the time). Azure Pipelines also offers runners that run on MacOS X. If GitHub Actions offers runners for Windows and MacOS X which are reliable enough, the existing CI for Azure Pipelines could be moved to GitHub Actions quite easily. For CircleCI and Travis, probably those CI's could be moved to GitHub Actions if we wanted, since those are running on Linux, and aren't doing anything too sophisticated. For the free version of GitHub Actions, the limits are 20 concurrent jobs (I guess on Linux), and 5 concurrent jobs on MacOS: https://docs.github.com/en/actions/reference/usage-limits-billing-and-admini... I think that is more than enough for Twisted's CI needs. There is no rush to move everything to GitHub Actions, but that is something we can consider over time. -- Craig
On Sat, 19 Sep 2020 at 21:30, Craig Rodrigues <rodrigc@crodrigues.org> wrote:
I think that is partially possible...but complicated. My question: Why does Twisted need Azure Pipelines (sharing infastructure with GihutActions), Travis-CI and Circle-Ci. Why can't Twisted just use GitHub actions? You can trigger one GitHub action workflow from another workflow, or everything as depende jobs inside one workflow. GitHub Action API is pretty good. I was able to implement a quick hack which sends a diff to GitHub and executes a test without a commit, just like Builbot Try [3]. I don't know how to implement something similar with Travis or Circle-Ci. --------- Travis-CI builds can be triggered over the HTTP API [1]...but I feel that implementing it is complicated. There should be a dedicated token... which should be created by a person, and then stored as a secret in GttHub Actions. I don't know how to trigger Circle-CI .. here is some info here [2] but looks like it will be deprecated I don't know how to trigger Azure Pipelines. but I guess that at some point MS will kill Azure Pipelines [1] https://docs.travis-ci.com/user/triggering-builds/ [2] https://circleci.com/docs/2.0/api-job-trigger/ [3] https://asciinema.org/a/nn1U7FLtbyWm57b0dT7U5sKD0 -- Adi Roiban
My question is: why would we want to do this? It seems like it would just make it slower to get feedback for contributors.
In a word: capacity. We have a large test matrix and more services = more parallel builds. The calculus on this is changing all the time; the amount of free stuff that Github Actions gives us has substantially increased, other services have stood still, things that used to be special dispensations for extra parallel builds are now just the default, we test on fewer kernels than we used to (no FreeBSD, for example). If we no longer get a substantial capacity benefit from using multiple services, we should definitely simplify and unify on one service.
On Sun, Sep 20, 2020 at 9:22 PM Glyph <glyph@twistedmatrix.com> wrote:
If some jobs such as lint or mypy fail first quickly, then there is no point in running the full test suite. That would give feedback faster to contributors that they need to do some minor fixes, before wasting cycles running the full test suite. When CI using Azure Pipelines was implemented for Twisted, Azure Pipelines offered runners that ran on Windows which seemed to be more reliable than Appveyor (which was what was used at the time). Azure Pipelines also offers runners that run on MacOS X. If GitHub Actions offers runners for Windows and MacOS X which are reliable enough, the existing CI for Azure Pipelines could be moved to GitHub Actions quite easily. For CircleCI and Travis, probably those CI's could be moved to GitHub Actions if we wanted, since those are running on Linux, and aren't doing anything too sophisticated. For the free version of GitHub Actions, the limits are 20 concurrent jobs (I guess on Linux), and 5 concurrent jobs on MacOS: https://docs.github.com/en/actions/reference/usage-limits-billing-and-admini... I think that is more than enough for Twisted's CI needs. There is no rush to move everything to GitHub Actions, but that is something we can consider over time. -- Craig
participants (3)
-
Adi Roiban -
Craig Rodrigues -
Glyph