One thing that is so far missing for the drone execution are test-coverage reports sent to coveralls. This could be resolved in combination with the pytest transition as proposed by florian: https://github.com/RDFLib/rdflib/pull/1268
@Nick you can give me the necessary right to configure drone, as long as there is a team of people who care for the configuration that is ok for me.
Natanael On 04.03.21 09:29, Wes Turner wrote:
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] <mailto:[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 <https://github.com/RDFLib/rdflib/pull/1271>. Travis seems to be working better these days too, presumably since the travis.org <http://travis.org> / travis.com <http://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] <mailto:[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] <mailto:[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 <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> https://github.com/dask/community/issues/107#issuecomment-724653314 <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 <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/tox-dev/tox-travis> > * https://github.com/ymyzk/tox-gh-actions <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 <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> > > * https://github.com/actions/runner/blob/main/src/Runner.Worker/action_yaml.json <https://github.com/actions/runner/blob/main/src/Runner.Worker/action_yaml.json> > * https://github.com/actions/virtual-environments <https://github.com/actions/virtual-environments> > TIL there's also a > https://github.com/pypa/gh-action-pypi-publish <https://github.com/pypa/gh-action-pypi-publish> GitHub action. > https://conda-forge.org/docs/maintainer/adding_pkgs.html <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#example-workflow-for-updating-a-package> > > https://conda-forge.org/docs/maintainer/updating_pkgs.html#pushing-to-regro-cf-autotick-bot-branch <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://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://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 <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 <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:-- http://github.com/RDFLibGitHub Actions might be faster? https://docs.github.com/en/actions/learn-github-actions/migrating-from-travis-ci-to-github-actions <https://docs.github.com/en/actions/learn-github-actions/migrating-from-travis-ci-to-github-actions> https://github.com/ymyzk/tox-gh-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<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 <https://groups.google.com/d/msgid/rdflib-dev/7742a56f-c2bd-5967-c5ca-e33789110cfa%40gmail.com>.-- http://github.com/RDFLib<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 <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 <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] <mailto:[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 <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] <mailto:[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 <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] <mailto:[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 <https://groups.google.com/d/msgid/rdflib-dev/CACfEFw8k78kzU%3DqAHAu%3Dj%3DeEiDNmM_AT6CSO%2BTkPpvv%3D0xY_3g%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/76eb6d5e-031e-00d3-d541-050bf1f5daf8%40gmail.com.
OpenPGP_signature
Description: OpenPGP digital signature
