Transformer ranking part 1

[nitbharambe]

No description provided.

[Jerry-Jinfeng-Guo]

I like the spirit ;) (of skipping the tests)

[TonyXiang8787]

@nitbharambe @Jerry-Jinfeng-Guo why is #567 merged but this not? How can you test the ranking without the full implementation?

[Jerry-Jinfeng-Guo]

@nitbharambe @Jerry-Jinfeng-Guo why is #567 merged but this not? How can you test the ranking without the full implementation?

The merged tests are for consequtive steps in the ranking. Since steps 2-3-4 and step 1 have inter-dependency, so are the tests. Therefore we figure it to be a good idea to merge stuff from 2-3-4 once ready and continue working on 1, while cross-referencing.

[Jerry-Jinfeng-Guo]

CI is stuck

[mgovers]

CI is stuck

that's because @nitbharambe prefixed the last commit 847723d with [skip ci]

[Jerry-Jinfeng-Guo]

CI is stuck

that's because @nitbharambe prefixed the last commit 847723d with [skip ci]

That should skip it, shouldn't it?

[mgovers]

CI is stuck

that's because @nitbharambe prefixed the last commit 847723d with [skip ci]

That should skip it, shouldn't it?

yes but the way github implemented it is that if there are Required checks (configurable in the repo admin settings) then it will always mark them as Expected.

This also is the reason why the Publish job is awaited in the merge queue but it doesn't link to the pipeline that will set it (because the job is the last one in the pipeline and won't report its status until it has started). I've been thinking about actually adding a report step that tells the merge queue that the pipeline that will set run those checks, but haven't come up with a sustainable solution yet

[TonyXiang8787]

CI is stuck

that's because @nitbharambe prefixed the last commit 847723d with [skip ci]

That should skip it, shouldn't it?

yes but the way github implemented it is that if there are Required checks (configurable in the repo admin settings) then it will always mark them as Expected.

This also is the reason why the Publish job is awaited in the merge queue but it doesn't link to the pipeline that will set it (because the job is the last one in the pipeline and won't report its status until it has started). I've been thinking about actually adding a report step that tells the merge queue that the pipeline that will set run those checks, but haven't come up with a sustainable solution yet

We can just push a new commit with skip ci in the message right?

[mgovers]

CI is stuck

that's because @nitbharambe prefixed the last commit 847723d with [skip ci]

That should skip it, shouldn't it?

yes but the way github implemented it is that if there are Required checks (configurable in the repo admin settings) then it will always mark them as Expected.
This also is the reason why the Publish job is awaited in the merge queue but it doesn't link to the pipeline that will set it (because the job is the last one in the pipeline and won't report its status until it has started). I've been thinking about actually adding a report step that tells the merge queue that the pipeline that will set run those checks, but haven't come up with a sustainable solution yet

We can just push a new commit with skip ci in the message right?

yes but that is not the issue 😉 my second comment was only related to the merge queue

[mgovers]

part 1 of review

[mgovers]

almost there 😬

[mgovers]

FINALLYYYYYYY 🎉

[sonarqubecloud]

Quality Gate passed

Issues
11 New issues
0 Accepted issues

Measures
0 Security Hotspots
94.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud