Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI: fewer triggers #457
CI: fewer triggers #457
Changes from 18 commits
ded6758
6885707
57df351
b04236e
acb005f
84bef1b
a6e53cd
98ceb05
a8523f3
5dc021b
e77a9ae
dce6d4c
7b61248
7b16079
d4e1c3a
742d0b4
a33cbda
922cff0
4150f6a
bf222fc
14b8ee7
f456912
05170fb
3b24f92
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we say that the package work with python 3.9 and 3.10, this needs to be tested and verified with the CI. Either we decide that we don't support python 3.9 anymore (because in case I'd go for the newer python and not for the older version), or we keep both versions in the CI.
I would keep both, I don't think it's critical in our case (testing on the two latest releases of python is pretty common and we've already removed python 3.8 at the beginning of the project). Also it could be that some unix based OS still need python 3.9 for let pytorch work. At the same time we want to guarantee that the package works with the latest release of python (for example because it's faster than 3.9)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Newest python is actually 3.11 :). But let's stick to 3.9 and 3.10 for now, I think.
We could do 3.9 for the normal build and 3.10 for the coveralls build. There is currently 1 command present in the normal build that isn't in coveralls, I can add that one to the coveralls to basically make it an extension of normal build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh and it was released in October, so many months ago. Then in the early future we should think about adding 3.11 as well, and at that point we can evaluate how critical is to remove the 3.9 version.
For the building, I get that coveralls does the build itself so you want to test 3.9 with the build file and 3.10 with the coveralls file, because both builds are tested this way. But this is not the cleaner way of doing it, because these yml files are thought to have well separated functions and they originate the badges that we show in the readme:

The build should be verified separately from coveralls, which should be run only if the build jobs go well. There are ways or creating interdependent yml files and avoiding running stuff multiple times, but I didn't want to spend much time on implementing more elegant solutions and I sticked to the basic one. If you're interested of course go for it, and we can have a chat for looking together where to find such info, but otherwise I'd prefer to use the build file to actually verify the builds that we want to guarantee (3.9 and 3.10 so far), and then use one of the two versions for running coveralls.