- Configure at least P4PORT and P4USER (see examples below)
- Provision with credentials - a P4TICKETS file is recommended
- Optionally customise workspace mapping.
Configuration via env vars:
env: P4PORT: perforce:1666 P4USER: username steps: plugins: - ca-johnson/perforce: ~
Configuration via the plugin:
steps: plugins: - ca-johnson/perforce: p4port: perforce:1666 p4user: username
P4PORT may also be configured by setting
BUILDKITE_REPO for your pipeline.
Custom workspace view:
steps: plugins: - ca-johnson/perforce: view: >- //dev/project/... project/... //dev/vendor/... vendor/...
Workspace view via a p4 stream:
steps: plugins: - ca-johnson/perforce: stream: //dev/minimal
There are a few options for triggering builds that use this plugin, in this order from least valuable but most convenient to most valueable but least convenient.
A. Schedule builds with a cron in buildkite - this requires no additional setup, but provides the worst reponse time as changes are made
B. A service polls your perforce for the current head revision and POSTs to the Buildkite API to trigger builds for any new changes. Note that you will need to store state to avoid duplicate and skipped builds.
C. Set up a
p4 trigger which POSTs to the buildkite API to trigger a build. See p4 triggers for more information. Note that this will require admin access to the Perforce server.
- Install python/requirements.txt
- Make sure
p4dis in your
- Make sure your version of
bk local run
Making changes to
- Write unit tests
- Implement new functionality
- Iterate via python unit tests
Making changes to
hooks/ and scripts called by hooks
- Add entries to local-pipeline.yml to test new behaviour, if relevant.
maketo start p4d on localhost:1666, vendor the plugin, run the pipeline and kill p4d.