I just tried to submit my first pull request and I found that it failed 2 out of the 4 'Mergeable' tests, 'MILESTONE' and 'LABEL'.
I'm not sure if I missed a step or did something else wrong. I'm not sure if this PR will even be considered in this state.
Are these fields something that I needed to set when submitting my PR?
I can see them listed to the right of text description, but I can not find a way to edit them.
Advice/guidance on how to proceed from here would be appreciated.
Nothing you need to do. They are actions team members will do when they get around to it.
I just noticed this morning that my second PR had failed the automated test suite when running on Windows.
I reviewed my edits to the test suite, identified my mistake and then committed the updated version. The build for Windows now succeeds.
Unfortunately, the build for "android-x86-docker" fails now, but I can't tell why. All that I can see is that the build script failed with error code '125'.
With the Windows build failure, I could see the results of the test script and identify what had gone wrong. However, with this new error, I just can't tell if this was my error or another error that just happened to coincide with my change.
Some guidance would be appreciated.
not related to your PR. CI is in a bit of a state of flux atm, so not as rock solid as we'd like.
In this particular instance, generally close/reopen the PR gets jenkins to build a clean slate and usually its all good from there.
(2023-03-18, 05:03)Fuzzard Wrote: [ -> ]not related to your PR. CI is in a bit of a state of flux atm, so not as rock solid as we'd like.
In this particular instance, generally close/reopen the PR gets jenkins to build a clean slate and usually its all good from there.
Thanks @
Fuzzard
I saw that you did the close/reopen process on GitHub. Is this something that I should have done or do I not have that level of authority?
As the author, you can open/close. Generally though most people dont have the insight into our current CI quirks to know when or why team members do these sort of things.
Generally someone will come along and check out the CI run and if they notice failures unrelated to the actual PR we'll do what needs to be done.