Hello,

I am using TravisCI for my project on GitHub. The project is packaged
for Debian, Ubuntu, Arch and several other distros.

All this distros support multiple architectures and they have their own
test machines to take care that all packages working on all archs.

On my side (upstream) I wonder which arch I should "support" in my
TravisCI configuration. I wan't to speed up travis and I want to save
energy and carbon.

I suspect that my Python code should run on much every platform that
offers a Python interpreter. Of course there are edge cases. But they
would be captured by the distros own test environments.

So is there a good and objective reason to support multiple (and maybe)
exotic platforms in a CI pipeline on upstream?

Kind
Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: c.buhtz
Re: Which architectures to support in a CI like Travis?
By: c.buhtz to comp.lang.python on Sun Sep 18 2022 09:46:45

I am using TravisCI for my project on GitHub. The project is packaged
for Debian, Ubuntu, Arch and several other distros.
All this distros support multiple architectures and they have their own test machines to take care that all packages working on all archs.

to be honest. most likely you're going to run into arm, x86_64 and x86_32 for the most part sot those are the ones i would focus on.

regarrds
Charles Blackburn
SYSOP - The F.B.O BBS 21:1/221
Aviation related fun @ bbs.thefbo.us IPV4 and IPV6
DOVE-Net FSX-Net USENET
Coming soon: FIDO-Net
--- Synchronet 3.19c-Linux NewsLink 1.113
The FBO - Aviation related fun - telnet://bbs.thefbo.us

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I would depend on the project.

In the crytoanalysis tool that I developing, "cryptonita", I just
manipule bytes. Nothing that could depend on the distro so my CI picks
one OS and run the tests there.

Project: https://github.com/cryptonitas/cryptonita
CI: https://github.com/cryptonitas/cryptonita/blob/master/.github/workflows/test.yml

On the other extreme I have "byexample", a tool that takes the examples
in your docs and run them as automated tests. It supports different
languages (Python, Ruby, Java, ...) and it works using the interpreter
of each languages.

An there is the challenge for its CI. Because byexample highly depends
on the version of the interpreter, the CI config tries a lot of
different scenarios

Project: https://byexamples.github.io/
CI: https://github.com/byexamples/byexample/blob/master/.github/workflows/test.yml

I don't tests different distros but I should for some cases that I
suspect that it could be differences in how some interpreters behave.

An about OS, I'm planning to add MacOS to the CI because I know that
some users had problems in the past in that platform because how
byexample interacts with the terminal.

So two projects, both in Python, but with two totally different
dependencies on the environment where they run, so their CI are
different.

The two examples are using Gitlab actions but the same applies to
TravisCI.

Thanks,
Martin.


On Sun, Sep 18, 2022 at 09:46:45AM +0000, c.buhtz@posteo.jp wrote:

Hello,

I am using TravisCI for my project on GitHub. The project is packaged
for Debian, Ubuntu, Arch and several other distros.

All this distros support multiple architectures and they have their own
test machines to take care that all packages working on all archs.

On my side (upstream) I wonder which arch I should "support" in my
TravisCI configuration. I wan't to speed up travis and I want to save
energy and carbon.

I suspect that my Python code should run on much every platform that
offers a Python interpreter. Of course there are edge cases. But they
would be captured by the distros own test environments.

So is there a good and objective reason to support multiple (and maybe) >exotic platforms in a CI pipeline on upstream?

Kind
Christian
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/18/22 03:46, c.buhtz@posteo.jp wrote:

Hello,

I am using TravisCI for my project on GitHub. The project is packaged
for Debian, Ubuntu, Arch and several other distros.

All this distros support multiple architectures and they have their own
test machines to take care that all packages working on all archs.

On my side (upstream) I wonder which arch I should "support" in my
TravisCI configuration. I wan't to speed up travis and I want to save
energy and carbon.

I suspect that my Python code should run on much every platform that
offers a Python interpreter. Of course there are edge cases. But they
would be captured by the distros own test environments.

So is there a good and objective reason to support multiple (and maybe) exotic platforms in a CI pipeline on upstream?

Kind
Christian

Kind of unrelated to the actual question, but if you start doing
anything serious under Travis you'll run out of free minutes rather
quickly. My project had to just give up on it after they changed their licensing models....

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)