Use curl to call the Jenkins Remote Access API, without downloading or using jenkins-cli.jar, and without adding wrapper scripts.
Scope of Operations
- Connecting, and querying identity, jobs, builds, logs, and artifacts are read-only operations.
- Write operations such as triggering or rerunning builds, modifying configuration, and stopping or deleting builds must be performed within the actions and target scope explicitly authorized by the user. If explicit authorization already exists, do not ask for confirmation again.
- When this project's pipelines are involved, first read the Git management instructions, and verify the actual job configuration and plugin capabilities on site; do not treat historical records as the current configuration.
Execution Flow
Before executing a request, read the environment, authentication, and read-only check sections of the Remote Access API reference , then read the query, trigger, wait, or configuration modification sections according to the job.
- Determine the controller and the expected user. Always read the address from the current environment variable
JENKINS_URL; if a required variable is missing, report the variable name, and do not automatically load or write project configuration. - Select credentials and prepare a temporary curl configuration, then verify identity via
/whoAmI/api/json./loginandX-Jenkinsare for auxiliary diagnostics only. - Locate the target from the URL returned by the API, and read Folders level by level; confirm the job type and parameters, and do not guess based on similar names.
- Perform operations as authorized. For write requests using password authentication, reuse the cookie obtained when fetching the crumb; place files in the system temporary directory, create them independently for each operation and clean them up at the end, without persisting across jobs.
- Output the controller, target job, HTTP status, and the necessary build number, result, revision, or log evidence. Credentials, cookies, crumbs, and sensitive parameters must not be output.
Triggering, Stopping, and Deleting
- By default, triggering only sends the request. HTTP 201/202 means the request has been accepted, not that the build has started or succeeded; when
Locationis present, provide the queue URL. - By default, do not query the queue, wait for the build, or follow logs. If the user's current request already includes waiting or log following, follow the reference documentation without additional confirmation.
- A full rerun, a Declarative Pipeline stage restart, and Replay are different operations; first choose the interface based on the user's intent and the target build's actual action, and do not treat Replay as a general rerun.
- An ordinary "stop build" only executes the standard
/stop。/term、/killand deleting a build are more destructive, and each must separately meet the prerequisites and authorization requirements in the reference documentation, without automatic escalation. - When a POST response is unclear or the connection is interrupted, do not automatically retry, to avoid duplicate triggering.
- If the target API is inaccessible, the identity does not match, the required permissions are missing, or the target cannot be uniquely matched, stop operations that depend on that information, and report the confirmed evidence and the missing information.