forked from jl777/SuperNET
-
Notifications
You must be signed in to change notification settings - Fork 116
fix(wasm): add test-ext-api feature to mm2_main and mm2_bin_lib tomls #2295
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
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
0576c25
add feature flag to mm2_main and mm2_bin_lib tomls
laruh 86f8312
filter 'status:' pr labels
laruh 201bb32
remove old labels
laruh 07b2f85
dont allow to pass blocked and invalid statuses
laruh 456eb17
pass in progress and pending review statuses
laruh 3678a8b
update statuses list
laruh File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe you could use '!=' as 'xor' ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
xorwould treattrue,true,truethe same astrue,false,false. that said im not sure how an expression with multiple==or!=execute (they always confuse me so i just pretend they never existed xD) so you are usingxorhere as an analogy or they actually have the very same effect.solutions i could think of:
trues we have.containsresult and make sure they are equal to1, booleans should support loose type coercion (false-> 0,true-> 1): https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions#operatorsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes 'xor' would not work. Looks like there is no '+' operator either.
I guess we need to set env vars to sum them (like it was done in one of the recent commits)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh. indeed
+isn't listed in the op list.maybe we can just avoid github actions'
ifclause and write the complete logic inside therun:in good old bash instead.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dimxy @mariocynicys
I suggest to move to bash if we decide to make lint logic more complex.
bash is more flexible, but less readable with more code lines required.
If we all agree with current labels logic:
then I suggest to leave GH actions expression.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it would look like this
this is too much, github actions allow to do the same in a more light weight way right in if block without waisting execution time on run
if we need to just be sure that labels have only one of 3 necessary labels this is simpler
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can do 2 separate checks:
we have only one PR label starting with "status:" (if not then error 'duplicate status')
PR labels contain any from the list of allowed labels.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont see problem of having
status: pending reviewandstatus: pending contract deploymentorstatus: pending infraetc together.Only one status i doubt is
status: invalidI would move it toPR must have "exactly one" of these labelslistI dont understand what do you mean, above you suggested to have only one status label
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean if we have already ensured that the PR has only single "status:" label,
it is easy to check that this label is one from allowed, like:
contains(env.LABEL_NAMES, 'pending review') || contains(env.LABEL_NAMES, 'in progress') || contains(env.LABEL_NAMES, 'blocked')Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these also will lead to move the whole logic to run block using bash, while we can do the same right in one
ifblock using GH actions expressions and it will userunonly in the case offalseresult.