Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Init process of using embargoed field for Incidents #128

Merged
merged 1 commit into from Jul 10, 2023

Conversation

asmorodskyi
Copy link
Contributor

Because of usage of same data structures in two independent applications (qem-bot and qem-dashboard)
we need to do introduction of new field in several stages. At first stage we will start pushing
this field into qem-dashboard from qem-bot. So after deploying this we can than read propely
this field coming from bot

Copy link
Contributor

@Martchus Martchus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like tests still need to be adapted.

@kraih
Copy link
Member

kraih commented Jul 4, 2023

Very useful test failures, confirm that it actually works as expected. Actually looks like the wrong place, what you want is the incident metadata, not the openQA jobs (probably PATCH /api/incidents).

kraih
kraih previously requested changes Jul 4, 2023
Copy link
Member

@kraih kraih left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the wrong place. It should be incidents and not openQA jobs.

Because of usage of same data structures in two independent applications (qem-bot and qem-dashboard)
we need to do introduction of new field in several stages. At first stage we will start pushing
this field into qem-dashboard from qem-bot. So after deploying this we can than read propely
this field coming from bot
@asmorodskyi
Copy link
Contributor Author

Looks like the wrong place. It should be incidents and not openQA jobs.

yes you are correct . Is it right place now ?

@kraih kraih dismissed their stale review July 7, 2023 18:46

Updated

@asmorodskyi
Copy link
Contributor Author

sorry not fully aware about workflows used in this project , so please don't get this as me trying to push you . But if there anything on me that is blocking this PR to be merged ?

@okurz
Copy link
Member

okurz commented Jul 10, 2023

sorry not fully aware about workflows used in this project , so please don't get this as me trying to push you . But if there anything on me that is blocking this PR to be merged ?

Nothing needs to be done by you. This just needs at least a second person reviewing and approving this PR whenever they find their github pull request review time. As the last update was on Friday and we are just in the middle of the next usual business day, i.e. Monday, I wouldn't be concerned.

Copy link
Member

@kraih kraih left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does look like the right place.

@mergify mergify bot merged commit cbef942 into openSUSE:master Jul 10, 2023
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants