Closed ericLemanissier closed 1 month ago
I wonder why the CI doesn't run on this PR
Afaiu, the workflows in this repo never build PR, only branches. That said, tou can take a look at CI on my fork
Hum, right, PR from forks don't trigger the CI then. Do you mind enabling the CI on PRs ? Seems somewhat related to your work to make forks usable
ok, I'm finally starting to get some results on my fork : https://ericlemanissier.github.io/conan-center-bot/
fixes https://github.com/qchateau/conan-center-bot/issues/106
This is based on top of https://github.com/qchateau/conan-center-bot/pull/107 to ease my tests, but the change in
ccb/upstream_project.py
is totally independant from github workfows modifications.Contrary to other
Upstream
sub-classes, I had to do the request inGithubReleaseProject
constructor (as opposed to theversions(self)
property), because we have to know if there are some actual releases during construction, in order to try otherUpstream
types if there are no actual releases. This also implies that if the token becomes rate limited, the exception is caught, and otherUpstream
types are tried. Also, releases tarball download URL cannot be derived from version alone, so I cached the download url as member of the Version object. I could not cache it in theGithubReleaseProject
instance because several instances of the detectedUpstream
are created for each recipe during a single workflow.Examples of branches created by this modification: