Add a 30 second sleep in mass_comment.py to avoid overwhelming Jenkins

[damccorm]

I found that running everything at once led to dropped jobs and conflicts between jobs (e.g. Gradle issues, Jenkins worker failures). This helped dramatically (I only had one or two jobs with Jenkins issues when I did this, as opposed to 20+). It also avoids harming the Jenkins experience for others who are planning on doing normal CI.

I also removed Java Portability examples on Dataflow with Java 11 since it doesn't seem to be a real postcommit (see #25600 (comment))

This will cause the script to run for around 1.25 hours, but shouldn't make a huge difference in the time to completion of the jobs themselves since a full Jenkins queue tends to be the blocker here anyways.

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

[damccorm]

R: @johnjcasey @kennknowles @Abacn

[github-actions]

Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control

[kennknowles]

So the obvious question is... can this script be a jenkins job?

[kennknowles]

So the obvious question is... can this script be a jenkins job?

Or GitHub Action

[codecov]

Codecov Report

Merging #25714 (66a5287) into master (60ac6ef) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #25714      +/-   ##
==========================================
- Coverage   72.82%   72.82%   -0.01%     
==========================================
  Files         775      775              
  Lines      102928   102928              
==========================================
- Hits        74957    74953       -4     
- Misses      26517    26521       +4     
  Partials     1454     1454              

Flag	Coverage Δ
python	81.96% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
sdks/python/apache_beam/utils/interactive_utils.py	95.12% <0.00%> (-2.44%)	⬇️
sdks/python/apache_beam/runners/direct/executor.py	96.46% <0.00%> (-0.55%)	⬇️
sdks/python/apache_beam/transforms/combiners.py	93.05% <0.00%> (-0.39%)	⬇️
...ks/python/apache_beam/runners/worker/sdk_worker.py	89.46% <0.00%> (+0.15%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[damccorm]

It actually is part of

beam/.github/workflows/verify_release_build.yml

Line 78 in 60ac6ef

sh ./comment_pr_trigger_phrases.sh $GITHUB_PR_URL

- that's currently on broken self-hosted runners though.

This is a good reminder that I forgot to update that job too, just did

[damccorm]

Unfortunately, our half done GH release automation is probably slowly drifting away from our actual release scripts

[damccorm]

Also, arguably we should be solving this problem by hitting Jenkins directly and gathering results at the end instead of using more expensive/indirect GH PR comments.

All of that is more work than bumping the timeout though, thus the current fix

[Abacn]

Thanks! It would greatly reduce the need of babysitting jenkins