
Hello, does anyone of you have experience with the continuous integration system "Travis" used by GitHub? If so it would be great if you could modify the configuration and offer this as an PR. I assume this is the relevant configuration file for that: https://github.com/bit-team/backintime/blob/master/.travis.yml The file seems quit easy but I don't want to mess around with it if there is someone with a bit more experience. I would like to remove the "python-nightly" from the tests. It seems interesting to know how the BiT code works with the next Python version. But currently we don't have resources for that and problems there are not urgent. We always should test the code manually when a new release candidate comes out. This is IMHO enough. Python 3.10 is fresh out and will stay for some times. Let's concentrate on more urgent problems. Doing this automatically distracts the users offering PRs and often gets red travis errors. As an example: https://github.com/bit-team/backintime/pull/1274/checks?check_run_id=7981781... The problem here is that BiT use the deprecated `unittest.TestCase.assertEquals()` with an 's' at the end instead of the without the 's' at the end. No big deal and not relevant for the code that was changed by the PR. The user invested time do offer us a PR so we should give him the damn good feeling of green test indicators. ;) So please someone remove "python-nightly". Also "python3.9-dev" isn't needed anymore because 3.9 is stable. Current is 3.9.13 and maybe there will come a 3.9.14 someday but the modifications shouldn't break our builds. So no need to check a dev/rc/pre version here. And why does python 3.6 and 3.10 are happens two times here? https://github.com/bit-team/backintime/pull/1274/checks?check_run_id=7981781... Is there a good reason for this or can we drop this and reduce resources (time, energy and CO2) on the GitHub server? Kind Christian

Dear Christian, I've updated the Travis-CI testing specifications to exclude Python "3.9-dev" and "nightly" from AMD64 architecture too. This should limit the testing to Python 3.6, 3.9 and 3.10. To keep the diff to a minimum, and since there's also PowerPC testing being done, I didn't remove any lines, but just excluded the tests. We might update the testing specification further down the line, if it proves to be necessary. I have created a PR, and it's currently being tested by Travis, so if it passes, somebody might merge that, maybe. Lastly, just as some context, Travis is an external service which provides CI/CD services, and provides it free for Open Source projects like Back in Time. They're very good at what they do, so I think we can continue using them. Both because I see no benefit in fixing what's not broken, and it's better to not tie Back in Time code tightly tied to GitHub ecosystem. Cheers, Hakan On 30.08.2022 11:00, Michael Büker wrote:

Dear Christian, I've updated the Travis-CI testing specifications to exclude Python "3.9-dev" and "nightly" from AMD64 architecture too. This should limit the testing to Python 3.6, 3.9 and 3.10. To keep the diff to a minimum, and since there's also PowerPC testing being done, I didn't remove any lines, but just excluded the tests. We might update the testing specification further down the line, if it proves to be necessary. I have created a PR, and it's currently being tested by Travis, so if it passes, somebody might merge that, maybe. Lastly, just as some context, Travis is an external service which provides CI/CD services, and provides it free for Open Source projects like Back in Time. They're very good at what they do, so I think we can continue using them. Both because I see no benefit in fixing what's not broken, and it's better to not tie Back in Time code tightly tied to GitHub ecosystem. Cheers, Hakan On 30.08.2022 11:00, Michael Büker wrote:
participants (3)
-
c.buhtz@posteo.jp
-
Hakan Bayındır
-
Michael Büker