Job definitions should be a simple as possible, and ideally identify a single gradle target to execute.
To test changes locally, without breaking the project’s job definitions, you can use Local Dockerized Jenkins.
It is possible to test a PR that includes Jenkins changes, but it is potentially destructive because the job definitions are a shared resource. To update the job definitions on a PR, use the “Run Seed Job” trigger phrase. This will cause the job definitions to be read and parsed, and they will be active until the next scheduled execution on beam_SeedJob or beam_SeedJob_Standalone.
Beam committers can trigger a job with the jenkins UI. Non-committers can trigger a job if there is a trigger phrase.
Each post-commit and pre-commit job file defines several jobs with different suffixes. For pre-commits, there _Commit, _Phrase, and _Cron suffixes. The _Commit job happens with every push to a pull request. The _Phrase happens when the trigger phrase is entered as a comment in the pre-commit. The _Cron pre-commit happens post-commit on the master branch as a signal whether the pre-commit would pass without any changes.
Most beam Jenkins jobs specify the label beam, which uses beam executors 1-15.
The performance test jobs specify the label beam-perf, which uses beam executors 16.
The website publishing job specifies the label git-websites, which allows publishing generated documentation to the asf-site branch.
Accessing test history
You can look at this url:
to get there
failed job -> test result -> navigate to failed test -> history
I remember having issue getting there for succeeded tests. So usually just replaced relevant fields in url.