Continuous Integration

[Natanael Arndt]

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

[Wes Turner]

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

--
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 rdflib-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/7742a56f-c2bd-5967-c5ca-e33789110cfa%40gmail.com.

[Natanael Arndt]

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

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.

[Wes Turner]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/8483e0be-b03e-bc02-b564-71a7f805f9a1%40gmail.com.

[Ashley Sommer]

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

[Wes Turner]

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

 

To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/018820bd-e088-490d-96be-87c8cf1e3051n%40googlegroups.com.

[Ashley Sommer]

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.

[Nicholas Car]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/6fd8c550-6d12-4220-a111-6c3c0f2e074cn%40googlegroups.com.

[Wes Turner]

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?

To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/CAP7nqh1tiqiFV%2BYLe%2BV6kfWvcsy3999-kxpzNTKEJ39663qESw%40mail.gmail.com.

[Natanael Arndt]

If this answers your question. The tests are executed on Drone on every pull-request. So if you create a pull request with your changes that should do all of the automatic testing that we have configured.

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

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.

[Wes Turner]

 

On Thu, Mar 4, 2021, 04:26 Natanael Arndt <arn...@gmail.com> wrote:

If this answers your question. The tests are executed on Drone on every pull-request. So if you create a pull request with your changes that should do all of the automatic testing that we have configured.

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.

https://galaxy.ansible.com/search?keywords=Drone

FWIU, there's not yet an Ansible role for this Docker security baseline: 

https://dev-sec.io/baselines/docker/

Is there a good way to do Drone builds in *rootless* containers (without granting `--privileged` access and/or the docker socket) i.e. without root?

It's probably possible to configure Drone to use gVisor for build containers (and also to limit egress bandwidth entirely for a sufficiently hermetic build)?

How could what percentage of users donate to support the cost of CI hosting?

> A project may define a `.github/FUNDING.yml`, which GitHub will display on the 'Sponsor' tab of the GitHub project. A project may also or instead include funding information in their /README.md.