[Jenkins] Add build stages

[phalbert]

Description

• Added a new kind stage
• Added a new blueprint jenkinsStage

Implementation

Utilized the Jenkins API provided by the pipeline-stage-view-plugin to retrieve pipeline stage information.

The API returns details such as stage IDs, names, statuses, start times, durations, and links to each stage, as shown in the example JSON response below:

{
    "_links": {
        "self": {
            "href": "/job/Phalbert/job/airframe-react/job/master/29/wfapi/describe"
        }
    },
    "id": "29",
    "name": "#29",
    "status": "FAILED",
    "startTimeMillis": 1717069181870,
    "endTimeMillis": 1717070384780,
    "durationMillis": 1202910,
    "queueDurationMillis": 5,
    "pauseDurationMillis": 0,
    "stages": [
        {
            "_links": {
                "self": {
                    "href": "/job/Phalbert/job/airframe-react/job/master/29/execution/node/6/wfapi/describe"
                }
            },
            "id": "6",
            "name": "Declarative: Checkout SCM",
            "execNode": "",
            "status": "SUCCESS",
            "startTimeMillis": 1717070383791,
            "durationMillis": 892,
            "pauseDurationMillis": 0
        },
        {
            "_links": {
                "self": {
                    "href": "/job/Phalbert/job/airframe-react/job/master/29/execution/node/17/wfapi/describe"
                }
            },
            "id": "17",
            "name": "Declarative: Post Actions",
            "execNode": "",
            "status": "SUCCESS",
            "startTimeMillis": 1717070384739,
            "durationMillis": 24,
            "pauseDurationMillis": 0
        }
    ]
}

Additional Context: For more details and ongoing discussion, please refer to the linked Slack thread: Jira Task Discussion.

Type of change

Please leave one option from the following and delete the rest:

• New feature (non-breaking change which adds functionality)

All tests should be run against the port production environment(using a testing org).

Core testing checklist

• Integration able to create all default resources from scratch
• Resync finishes successfully
• Resync able to create entities
• Resync able to update entities
• Resync able to detect and delete entities
• Scheduled resync able to abort existing resync and start a new one
• Tested with at least 2 integrations from scratch
• Tested with Kafka and Polling event listeners

Integration testing checklist

• Integration able to create all default resources from scratch
• Resync able to create entities
• Resync able to update entities
• Resync able to detect and delete entities
• Resync finishes successfully
• If new resource kind is added or updated in the integration, add example raw data, mapping and expected result to the examples folder in the integration directory.
• If resource kind is updated, run the integration with the example data and check if the expected result is achieved
• If new resource kind is added or updated, validate that live-events for that resource are working as expected
• Docs PR link here

Preflight checklist

• Handled rate limiting
• Handled pagination
• Implemented the code in async
• Support Multi account

Screenshots

Include screenshots from your environment showing how the resources of the integration will look.

API Documentation

Provide links to the API documentation used for this integration.

[PeyGis]

Left some comments

[PeyGis]

in terms of the user experience, I was just wondering why we're using the job_url instead of the job_name. is the job_url easier or the same as the name? maybe you can share a sample format for the job_url

[phalbert]

In terms of user experience, we use the job_url instead of the job_name primarily for consistency and reliability. Job names can contain spaces or special characters, which require URL encoding, and this can lead to issues if not handled correctly. On the other hand, the job_url is a complete and fully encoded reference to the job, making it more straightforward to work with.

Here are some examples:

http://localhost:8080/job/Phalbert/job/airframe-react/
http://localhost:8080/job/limbopay/job/Limbo%20Core/job/main/

The second url would have the job name Limbo Core in the jenkins dashboard.

In this format, the job_url already includes everything necessary to make API requests (such as appending /api/json), eliminating the need for additional encoding steps. By using job_url, we avoid potential errors related to name encoding and ensure the API calls are more predictable.

After all, the Job URL is always returned as a property and a user can copy and paste in the mapping.