Is there a "push to PR branch runs the CI build" workflow for lowly infrequent contributors such as myself, who shouldn't be expected to run their own Drone server or runners?
It's not even reasonable to expect me to run tox manually or in a precommit config before committing or pushing (especially when the full test suite must run multiple database servers to test against) FWIU, Drone supports GitLab CI YAML but not yet GitHub Actions YAML. Actions would get free CI for all PRs (indefinitely) and you can run the actual build locally. I suppose it would be disadvantageous to factor out db-specific drivers so that those tests only need to run when code in those then multiple other repos changes? On Thu, Mar 4, 2021, 03:09 Nicholas Car <[email protected]> wrote: > Following up on this: Ashley's implemented Drone and it seems to be > running happlity, see the checks for recent PRs, e.g. > https://github.com/RDFLib/rdflib/pull/1271. > > Travis seems to be working better these days too, presumably since the > travis.org / travis.com issues have resolved. > > Working on the assumption that Drone is doing everything we need it to do, > I propose skilling up a couple of other CI/CD admins for RDFlib and then, > if they are all happy, shutting down Travis. I'v put forward Alejandro from > my company to get across Drone (since we will also use it internally) so > can I have hands up for another, perhaps you Natanael? > > Thanks, > > Nick > > On Fri, Feb 5, 2021 at 11:46 AM Ashley Sommer <[email protected]> > wrote: > >> My intention is to avoid vendor lock-in. Hosting our own GitHub runner >> for example is really no different than using the provided free GitHub >> Actions free tier, its essentially the same level of vendor lock-in. >> Even using Travis is to some extent still vendor lock-in because you >> cannot self-host your own Travis runner and Travis only works with >> GitHub-linked repositories. >> That's why I was thinking about hosting a well known 3rd party tool like >> Jenkins, which will work whether the repository is hosted on GitHub, >> GitLab, BitBucket, or any other. >> >> I understand it does incur a small amount of additional maintenance >> overhead, so that will need to be taken into consideration. >> On Friday, February 5, 2021 at 10:43:56 AM UTC+10 [email protected] >> wrote: >> >>> You could host a GitLab Runner or a GitHub Runner (or Drone or Jenkins). >>> >>> AFAIU, all of the above need access to the docker socket to start and >>> stop build containers, so (without additional process isolation) the build >>> server that pulls PRs automatically and runs them in containers has root on >>> everything else on that box. >>> >>> Self-hosted CI does have additional maintenance and redundant pager >>> costs; a runner for CI jobs in excess of GH/GL free quota should be bounded. >>> https://github.com/awesome-selfhosted/awesome-selfhosted >>> >>> >>> >>> On Thu, Feb 4, 2021, 18:32 Ashley Sommer <[email protected]> wrote: >>> >>>> Last year I reached out to Linode to provide sponsor a VM for the >>>> RDFLib project (they are really good about providing VMs for open source >>>> projects if you contact them and ask nicely). >>>> I'd planned to host a new RDFLib website and documentation on there, as >>>> well as a Discourse-based RDFLib Community Forum. >>>> None of that has yet materialized, but we do have the server, it is >>>> running there doing nothing. So I could host a CI something like Bamboo or >>>> Jenkins on there. We could possibly even host a full-blown gitlab and >>>> mirror the repository too. >>>> >>>> - Ashley >>>> >>>> On Saturday, January 30, 2021 at 5:02:50 AM UTC+10 [email protected] >>>> wrote: >>>> >>>>> From Dask's multi-project meta "Migrate CI to GitHub Actions" >>>>> https://github.com/dask/community/issues/107 >>>>> https://github.com/dask/community/issues/107#issuecomment-724653314 >>>>> >>>>> > Is there a script to convert from one YAML build spec to another? >>>>> There may already be tool written in Python for converting between various >>>>> CI configs? >>>>> > >>>>> > Looks like drone-yaml (which is depended upon by drone-cli) can >>>>> convert _from_ BitBucket & GitLab, but not yet CircleCI, TravisCI, or >>>>> GitHub >>>>> > only to drone CI YML. >>>>> > >>>>> https://github.com/drone/drone-yaml/blob/6f4d6dfb39e40f92d31cb113f2cdcb19387d163b/yaml/converter/convert.go#L17-L27 >>>>> > >>>>> > If you can put most of the CI config in tox.ini with tox-travis or >>>>> tox-gh-actions, you can more easily run equivalent local builds (and have >>>>> less build config to convert) >>>>> > >>>>> > * https://github.com/tox-dev/tox-travis >>>>> > * https://github.com/ymyzk/tox-gh-actions >>>>> > >>>>> > Note that self-hosted GitHub runners (~GitLab CI Runners (Go)) are >>>>> an option for faster local or cloud builds: >>>>> > >>>>> > * >>>>> https://docs.github.com/en/free-pro-team@latest/actions/hosting-your-own-runners/about-self-hosted-runners >>>>> (C#) >>>>> > * https://github.com/actions/runner >>>>> > >>>>> > * >>>>> https://github.com/actions/runner/blob/main/src/Runner.Worker/action_yaml.json >>>>> > * https://github.com/actions/virtual-environments >>>>> >>>>> > TIL there's also a >>>>> > https://github.com/pypa/gh-action-pypi-publish GitHub action. >>>>> >>>>> >>>>> >>>>> > https://conda-forge.org/docs/maintainer/adding_pkgs.html :: >>>>> > >>>>> > > [...] how to contribute packages to conda-forge. >>>>> > >>>>> > >>>>> https://conda-forge.org/docs/maintainer/updating_pkgs.html#example-workflow-for-updating-a-package >>>>> > >>>>> > >>>>> https://conda-forge.org/docs/maintainer/updating_pkgs.html#pushing-to-regro-cf-autotick-bot-branch >>>>> : >>>>> > >>>>> > > When a new version of a package is released on PyPI/CRAN/.., we >>>>> have a bot that automatically creates version updates for the feedstock. >>>>> In >>>>> most cases you can simply merge this PR and it should include all changes. >>>>> When certain things have changed upstream, e.g. the dependencies, you will >>>>> still have to do changes to the created PR. As feedstock maintainer, you >>>>> don’t have to create a new PR for that but can simply push to the branch >>>>> the bot created. >>>>> > >>>>> > bot commands recognized in GH PR comments: >>>>> > >>>>> > * >>>>> https://conda-forge.org/docs/maintainer/infrastructure.html#admin-web-services >>>>> > * >>>>> https://github.com/conda-forge/conda-forge-webservices/blob/master/conda_forge_webservices/tests/test_commands.py#L42 >>>>> > * >>>>> https://regro.github.io/cf-scripts/github_actions_infrastructure.html#automerging-prs >>>>> >>>>> >>>>> > TIL there's also a >>>>> > https://github.com/pypa/gh-action-pypi-publish GitHub action. >>>>> >>>>> >>>>> >>>>> On Fri, Jan 29, 2021, 04:32 Natanael Arndt <[email protected]> wrote: >>>>> >>>>>> GitHub Actions is one option, which is at hand. It might provide the >>>>>> best integration with GitHub. But it might provide stronger ties for >>>>>> vendor >>>>>> login, which could cause trouble in some distant future. But actually I >>>>>> do >>>>>> not have a good overview on the alternatives and having no vendor login >>>>>> would only be possible with self-hosted infrastructure. >>>>>> >>>>>> Does anybody have good experience with the different choices? >>>>>> >>>>>> Natanael >>>>>> On 28.01.21 21:26, Wes Turner wrote: >>>>>> >>>>>> GitHub Actions might be faster? >>>>>> >>>>>> >>>>>> https://docs.github.com/en/actions/learn-github-actions/migrating-from-travis-ci-to-github-actions >>>>>> >>>>>> https://github.com/ymyzk/tox-gh-actions >>>>>> >>>>>> On Thu, Jan 28, 2021, 13:40 Natanael Arndt <[email protected]> wrote: >>>>>> >>>>>>> The Continuous Integration provided by Travis makes some trouble at >>>>>>> the >>>>>>> moment. It takes over an hour until a pull-request is tested. We >>>>>>> have to >>>>>>> do something about this. As it appears to me in the github settings, >>>>>>> the >>>>>>> travis integration is very old, we might need to update it from org >>>>>>> (Open Source) to com, but I don't know if we will be still good with >>>>>>> the >>>>>>> free plan. So maybe we have to switch to a different CI provide as >>>>>>> many >>>>>>> others did. Or we have some resource to run our own ci. >>>>>>> >>>>>>> What are your thought about this topic? >>>>>>> >>>>>>> Natanael >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> http://github.com/RDFLib >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "rdflib-dev" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/rdflib-dev/7742a56f-c2bd-5967-c5ca-e33789110cfa%40gmail.com >>>>>>> . >>>>>>> >>>>>> -- >>>>>> http://github.com/RDFLib >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "rdflib-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/rdflib-dev/CACfEFw8sc_9hCUTpyxsbaeMMB-eGUk%2B%2B%2B0pBe5FXm4krPRzj-A%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/rdflib-dev/CACfEFw8sc_9hCUTpyxsbaeMMB-eGUk%2B%2B%2B0pBe5FXm4krPRzj-A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> -- >>>>>> http://github.com/RDFLib >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "rdflib-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> >>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/rdflib-dev/8483e0be-b03e-bc02-b564-71a7f805f9a1%40gmail.com >>>>>> <https://groups.google.com/d/msgid/rdflib-dev/8483e0be-b03e-bc02-b564-71a7f805f9a1%40gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> http://github.com/RDFLib >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "rdflib-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/rdflib-dev/018820bd-e088-490d-96be-87c8cf1e3051n%40googlegroups.com >>>> <https://groups.google.com/d/msgid/rdflib-dev/018820bd-e088-490d-96be-87c8cf1e3051n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> http://github.com/RDFLib >> --- >> You received this message because you are subscribed to the Google Groups >> "rdflib-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/rdflib-dev/6fd8c550-6d12-4220-a111-6c3c0f2e074cn%40googlegroups.com >> <https://groups.google.com/d/msgid/rdflib-dev/6fd8c550-6d12-4220-a111-6c3c0f2e074cn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > http://github.com/RDFLib > --- > You received this message because you are subscribed to the Google Groups > "rdflib-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rdflib-dev/CAP7nqh1tiqiFV%2BYLe%2BV6kfWvcsy3999-kxpzNTKEJ39663qESw%40mail.gmail.com > <https://groups.google.com/d/msgid/rdflib-dev/CAP7nqh1tiqiFV%2BYLe%2BV6kfWvcsy3999-kxpzNTKEJ39663qESw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- http://github.com/RDFLib --- You received this message because you are subscribed to the Google Groups "rdflib-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/CACfEFw8k78kzU%3DqAHAu%3Dj%3DeEiDNmM_AT6CSO%2BTkPpvv%3D0xY_3g%40mail.gmail.com.
