The main concern here seems to be whether using pre-release candidates
would be too disruptive to our workflow. I think this is an easy
hypothesis to test out--we can give using prerelease candidates a try, and
if that indeed turns out to be a problem we can then do the work of
trying to put togeth
Friendly ping:)
If anyone has experience testing the pre-released versions, your feedback
would be much appreciated.
Thanks,
Anand
On Wed, Apr 12, 2023 at 5:07 PM Yi Hu wrote:
> Sounds good, thanks!
>
> Best,
> Yi
>
> On Wed, Apr 12, 2023 at 2:20 PM Anand Inguva
> wrote:
>
>> @Yi Hu I thin
Sounds good, thanks!
Best,
Yi
On Wed, Apr 12, 2023 at 2:20 PM Anand Inguva wrote:
> @Yi Hu I think adding them to Jenkins or github
> actions is okay with me. With Github actions, since we don't use self
> hosted runners yet, I worry that action workers might get queued up.
>
> Also, I plan to
@Yi Hu I think adding them to Jenkins or github actions
is okay with me. With Github actions, since we don't use self hosted
runners yet, I worry that action workers might get queued up.
Also, I plan to not run these on every commit but run it as a cron
job(maybe once per day) and also as trigger
I think case in point dependency that would benefit from this testing is
grpcio, which includes pre-releases, and broke us and multiple of it's
released versions were yanked. https://pypi.org/project/grpcio/#history .
We can look at how grpcio affected Beam previously. Couple of issues:
- https:/
Thanks Anand,
This would be very helpful to avoid experiencing multiple time (
https://s.apache.org/beam-python-dependencies-pm). One thing to note is
that Beam Jenkins CI is experiencing many issues recently, mostly due to
that multiple Jenkins plugins does not scale (draining GitHub API call
lim
2. Make use of the current PreCommit and PostCommit test suite and modify
it so that it installs pre-released dependencies.
> Leads to noisy test signals if the pre-release candidate is unstable.
I am favor of option 2 since it's a simple solution that is easy to
implement and try out. The disadv
Thanks for doing this Anand, I'm +1 on option 1 as well - I think having
the clear signal of the normal suite succeeding and the prerelease one
failing would be helpful and there shouldn't be too much additional code
necessary. That makes it really easy to treat the prerelease suite as a (at
least
Hi all,
For Apache Beam Python we are considering using pre-released dependencies
for unit testing by using the --pre flag to install pre-released
dependencies of packages.
We believe that using pre-released dependencies may help us to identify and
resolve bugs more quickly, and to take advantage
