feat(RELEASE-1401): close issues fixed in advisories #812
Conversation
|
Skipping CI for Draft Pull Request. |
johnbieren
force-pushed
the
release1401
branch
11 times, most recently
from
3cdd783 to
31681e2
Compare
| - name: ACCESS_TOKEN | ||
| valueFrom: | ||
| secretKeyRef: | ||
| name: todo |
There was a problem hiding this comment.
This should not be merged with the name and key as todo (e2e) won't pass anyways. It is also in the mocks. Waiting on Rogue to provide the key and releng to add it to update this
johnbieren
force-pushed
the
release1401
branch
from
31681e2 to
c231acf
Compare
This commit adds a new task, `close-advisory-issues` to the `rh-advisories` pipeline. It should run after the advisory is created. It will close all issues listed in the releaseNotes and add a comment saying what advisory they were fixed in. Signed-off-by: Johnny Bieren <[email protected]>
johnbieren
force-pushed
the
release1401
branch
from
c231acf to
dc61247
Compare
|
|
||
| echo "Closing issue $issue" | ||
| # Get the Closed transition id. This varies per Jira project | ||
| if ! CLOSED_ID="$(curl "${CURL_ARGS[@]}" "${API_URL}/transitions" \ |
There was a problem hiding this comment.
TBH, I'm a bit worried about this. For example, it works for RELEASE, but not for CWFHEALTH.
$ curl -H "Authorization: Bearer $JIRA_TOKEN" https://issues.redhat.com/rest/api/2/issue/CWFHEALTH-3987/transitions | jq -r '.transitions'
[
{
"id": "11",
"name": "Groom",
"description": "An issue has made it past grooming within the team (via the PO) and is ready to be accepted by a developer and/or added to a sprint.",
"opsbarSequence": 10,
"to": {
"self": "https://issues.redhat.com/rest/api/2/status/15021",
"description": "Work is being scoped and discussed (To Do status category; see also Draft)",
"iconUrl": "https://issues.redhat.com/images/icons/statuses/generic.png",
"name": "Refinement",
"id": "15021",
"statusCategory": {
"self": "https://issues.redhat.com/rest/api/2/statuscategory/2",
"id": 2,
"key": "new",
"colorName": "default",
"name": "To Do"
}
}
},
{
"id": "41",
"name": "Drop",
"description": "An issue has possibly been filed by mistake and should resolved back to the reporter with the reason for Dropping it.",
"opsbarSequence": 20,
"to": {
"self": "https://issues.redhat.com/rest/api/2/status/5",
"description": "For teams with longer stakeholder feedback loops (multiple days before they typically respond), this status can be used to indicate the work is done and deployed, but still awaiting sign-off from the requester(s). It is different from Release Pending because the work has been deployed. This is meant for help-desk style interactions, not product development.",
"iconUrl": "https://issues.redhat.com/images/icons/statuses/resolved.png",
"name": "Resolved",
"id": "5",
"statusCategory": {
"self": "https://issues.redhat.com/rest/api/2/statuscategory/3",
"id": 3,
"key": "done",
"colorName": "success",
"name": "Done"
}
}
}
]
There is no match for name=Closed.
Of course this is not a jira project that will be used. But the point is that transitions can be set up completely differently for different projects. Would be good to find out how SP is dealing with this. Or maybe you got it from them?
There was a problem hiding this comment.
I did not, but I tried it on RELEASE and OCPBUGS, which was my example cve. @p-rog do you have any idea how SP does this? Or who to ask?
There was a problem hiding this comment.
All software product projects should follow the OJA schema and use the same transition and closure resolutions: Closed / Done. Of course there is a chance that there is a project with custom schema. Can we in such cases ignore the issue and proceed without changing the status?
There was a problem hiding this comment.
Okay, I think the code as written may be good enough then. Right now, if they have no Closed state, we will continue and process the other issues but fail at the end and print out what one we failed to close. This will be useful (IMO) so users are alerted that "hey, we didn't close this one for you." It is the final task in the pipeline, so everything will still run with this failure. Maybe it will nudge them to add the state to their jira project
There was a problem hiding this comment.
We can try this approach. If users will complain that they want to proceed even if issue is not closed, then we can adjust the logic and ignore Jira issues which use not standard schema.
|
@johnbieren: The following test has Failed, say /retest to rerun failed tests.
Inspecting Test ArtifactsTo inspect your test artifacts, follow these steps:
mkdir -p oras-artifacts
cd oras-artifacts
oras pull quay.io/konflux-test-storage/konflux-team/release-service-catalog:konflux-e2e-tests-catalog-kmd6nTest results analysis🚨 Error occurred while running the E2E tests, list of failed Spec(s): ➡️ [ Click to view logsPipelineRun managed-kx5w4 failed
Expected
: Pipelinerun 'managed-kx5w4' didn't succeed\nLogs from failed container 'managed-kx5w4-add-fbc-contribution-to-index-image/step-add-contribution': \n{\n \"index_image\": {\n \"target_index\": \"quay.io/redhat/redhat----preview-operator-index:v4.12\"\n }\n}\nCreating InternalRequest to add FBC contribution to index image:\nInternalRequest 'update-fbc-catalog-2lpvp' created.\nSync flag set to true. Waiting for the InternalRequest to be completed.\nChecking IR statuses...\nFound 1 InternalRequests matching the name or label\nConditions:\n update-fbc-catalog-2lpvp: Rejected\nAll InternalRequests have been completed\nERROR: At least one InternalRequest failed\nConditions:\n update-fbc-catalog-2lpvp: [{\"lastTransitionTime\":\"2025-02-07T15:57:56Z\",\"message\":\"No endpoint to handle 'update-fbc-catalog' requests\",\"reason\":\"Rejected\",\"status\":\"False\",\"type\":\"Succeeded\"}]\nResult: failure\n
to equal
: ➡️ [ Click to view logsPipelineRun managed-gc9bc failed
Expected
: Pipelinerun 'managed-gc9bc' didn't succeed\n
to equal
: ➡️ [ Click to view logsPipelineRun managed-tdnrs failed
Expected
: Pipelinerun 'managed-tdnrs' didn't succeed\n
to equal
: |
This commit adds a new task,
close-advisory-issuesto therh-advisoriespipeline. It should run after the advisory is created. It will close all issues listed in the releaseNotes and add a comment saying what advisory they were fixed in.Describe your changes
Relevant Jira
Checklist before requesting a review
do not mergelabel if there's a dependency PRrelease-service-maintainershandle if you are unsure who to tagSigned-off-by: My name <email>