Added by livdywan about 4 years ago. Updated almost 4 years ago.
0%
Description
The reference parameter allows the API to verify that the current state in the database matches the state expected by the consumer.
There is https://gitlab.suse.de/qsf-u/qa-sle-functional-userspace/-/merge_requests/29 and no one responded within 3 weeks. This is either a big overlook on the side of the corresponding team or they just don't like you ;) In any case also the pipeline job seems to have failed. So what do you plan as next steps?
Conversation with upstream and update to my branch in progress - turns out my original approach was way to complicated.
Unfortunately the change had to be reverted because of a regression. I proposed a PR to address this:
Turns out git/ GitLab CI is making what should've been a simple fix quite a challenge.
origin/master on GitLab CIgit fetch fails because it's not configuredgit show doesn't fail even when it failsCI_COMMIT_BEFORE_SHA doesn't work and isn't well-documentedI'm putting this on Feedback now, on account of having exhausted all the options.
Maybe the feature isn't feasible on GitLab? Maybe we need a different approach?
I created https://gitlab.suse.de/qsf-u/qa-sle-functional-userspace/-/merge_requests/78
I think it's not very nice having to compose the repo URL ourselves, but it works.
There's also an alternative proposal https://gitlab.suse.de/qsf-y/qa-sle-functional-y/-/merge_requests/166 which means this is pending on upstream's call on which to go for now.
No update in the MR https://gitlab.suse.de/qsf-y/qa-sle-functional-y/-/merge_requests/166 but I guess we can just give it more time.
We can in fact close this. Ultimately the protection against unexpected changes doesn't fit the workflow very well, at least for QASFY.