Jump to content

Continuous integration/Tutorials/Trigger a job manually

From mediawiki.org

When creating new Jenkins job, you would want to experiment with it before it gets included in the Zuul configuration. Your labs account would need to be allowed to trigger build in Jenkins (should be the case if you're a member of the wmf or wmde LDAP group).

Browse to the Jenkins job and click "Build with Parameters". A form will ask you to fill in Zuul related parameters, they define the project name, commit and git reference, the parameters are used by the job to apply the patch. You can get such parameters from the properties of another job that already ran for a similar change. E.g. If you're working on a new job to run phpunit for a project, look at existing jobs for the same project and take the parameters from one of its builds. Copy-and-paste at least the following fields:

  • ZUUL_PROJECT
  • ZUUL_BRANCH
  • ZUUL_REF
  • ZUUL_COMMIT
  • ZUUL_CHANGE_IDS

Then press "Build". The job will now run as if it were triggered by Zuul.

If you are not happy with the result, continue tweaking the job configuration. After each configuration update, you can navigate to the previous build and press "Rebuild" to kick off a new build with the same parameters (but using the new job configuration).

If the job already exists in a zuul pipeline, you can use the zuul-test-repo script to manually trigger the entire pipeline on the last merged patchset for a repository. Examples:

  • zuul-test-repo oojs/ui
  • zuul-test-repo ext:MassMessage # Shortcut for MediaWiki extensions
  • zuul-test-repo mediawiki/core postmerge