Support https://docs.gitlab.com/api/jobs/#get-job-tokens-job in JobApi

[tkruse]

The actual gitlab v4 API allows to fetch jobs by token https://docs.gitlab.com/api/jobs/#get-job-tokens-job

curl --header "Authorization: Bearer $CI_JOB_TOKEN" "${CI_API_V4_URL}/job"
curl --header "JOB-TOKEN: $CI_JOB_TOKEN" "${CI_API_V4_URL}/job"
curl "${CI_API_V4_URL}/job?job_token=$CI_JOB_TOKEN"

But the Java API does not have any way to access that endpoint.

Implementation would be roughly:

    /**
     * GET /job
     * curl "${CI_API_V4_URL}/job?job_token=$CI_JOB_TOKEN" or 
     * curl --header "JOB-TOKEN: $CI_JOB_TOKEN" "${CI_API_V4_URL}/job"
     */
    public Job getJob(final String ciJobToken) throws GitLabApiException {
        // this method is currently not exposed in JobApi
        final Response response = get(
                Response.Status.OK, 
                // this approach collides with other authorization tokens in gitlabApi
                // new GitLabApiForm().withParam("job_token", ciJobToken).asMap(), 
               null
                "job");
        return (response.readEntity(new GenericType<Job>() {}));
    }

However, we had trouble implementing it like this, because the authorization via the job_token and the authorization via the personal access token seemed to conflict with each other.

[jmini]

I added getJob() in with pull request #1233

If you use the token-based auth, this correspond to:

curl --header "JOB-TOKEN: $CI_JOB_TOKEN" "${CI_API_V4_URL}/job"

I have a working example here:
https://github.com/jmini/jbang-ci-test/blob/get-job/HelloWorld.java

This is using jbang to run the script that is using the gitlab4j library.

And this is the file for the pipeline definition:
https://github.com/jmini/jbang-ci-test/blob/get-job/.gitlab-ci.yml
(with a build and execute job definitions, could be simplified to have only one job that execute the jbang script directly. Also the ./jbang info tools call is more for debugging purpose)

---

It worked well for me:

--- Start ---
{
  "id" : 407058,
  "commit" : {
    "author" : null,
    "authoredDate" : "2025-03-05T08:17:50Z",
...
    "issuesTemplate" : null,
    "markedForDeletionOn" : null,
    "public" : null,
    "_links" : null
  }
}
--- End ---

---

Do you need the variant with ciJobToken argument?
I guess that in that case you need no authentication or a personal access token…

[tkruse]

@jmini : No, we do not specifically need the variant with ?job_token= query parameter. We thought we could use this with our existing GitabApi instance, then it would have made things easier, but since that does not work, there is no benefit to it.

However, the code in your PR probably needs a lot of documentation (and/or better error messages) to clarify that to work, this requires a GitlabApi instance that has been created as in your example using new GitLabApi(ApiVersion.V4, gitLabUrl, TokenType.JOB_TOKEN, gitLabAuthValue). When using a gitlabApi instance without a JOB_TOKEN set, the call is meaningless, and should probably fail with IllegalStateException("job token not set"). Should I comment about it on the MR directly?

Probably many users like us would have a "singleton" GitabApi instance in their system reused for all calls to Gitlab, but in this case this would not be viable.

[jmini]

I have opened #1236 to add the method with the query parameter and I have integrated your feedback from the previous PR