-
Notifications
You must be signed in to change notification settings - Fork 101
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
fix(wasm): add test-ext-api feature to mm2_main and mm2_bin_lib tomls #2295
Conversation
I can see there are PR statuses like 'invalid', 'blocked'. Should we allow to run CI for those? |
.github/workflows/pr-lint.yml
Outdated
@@ -50,5 +50,15 @@ jobs: | |||
LABEL_NAMES: ${{ toJson(github.event.pull_request.labels.*.name) }} | |||
if: contains(env.LABEL_NAMES, 'under review') == contains(env.LABEL_NAMES, 'in progress') |
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.
This needs to be updated.
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.
Forgot to remove
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.
as we have 3rd label to check, I decided to use &&
3678a8b
.github/workflows/pr-lint.yml
Outdated
echo "PR must have "exactly one" of these labels: ['under review', 'in progress']." | ||
exit 1 | ||
# Filter labels starting with "status:" | ||
STATUS_LABELS=$(echo $LABEL_NAMES | jq -r '.[] | select(startswith("status:"))') | ||
STATUS_COUNT=$(echo "$STATUS_LABELS" | wc -l) | ||
|
||
echo "Found status labels: $STATUS_LABELS" | ||
echo "Count of status labels: $STATUS_COUNT" | ||
|
||
if [ "$STATUS_COUNT" -ne 1 ] | ||
then | ||
echo "PR must have exactly one label starting with 'status:'. Found $STATUS_COUNT." | ||
exit 1 | ||
fi |
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.
We don't need this much change here I think
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.
We just need to replace the old labels, I don't know why we changed the entire logic
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.
We just need to replace the old labels, I don't know why we changed the entire logic
I decided that almost all status labels are valid and can pass the PR lint. Are you suggesting allowing only the 'pending review' and 'in progress' statuses to pass the lint check?
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.
Label validation logic was simple: requiring one of "in progress" or "under review" labels but not both at the same time. We can update this logic with new ones + blocked 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.
We can update this logic with new ones + blocked label.
That what I wanted to do, allow new status labels except invalid statuses, just without rewriting all statuses manually.
But I think now, its better to be explicit with labels in pr lint for the case if we add new status labels in the future
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 didn't mean all new labels, what I mean is these 3 labels:
- status: pending review
- status: blocked
- status: in progress
hmm I see |
7fe6547
to
50e1e1e
Compare
63d0a1a
to
3678a8b
Compare
@@ -48,7 +48,9 @@ jobs: | |||
- name: Check PR labels | |||
env: | |||
LABEL_NAMES: ${{ toJson(github.event.pull_request.labels.*.name) }} | |||
if: contains(env.LABEL_NAMES, 'under review') == contains(env.LABEL_NAMES, 'in progress') | |||
if: "!((contains(env.LABEL_NAMES, 'pending review') && !contains(env.LABEL_NAMES, 'in progress') && !contains(env.LABEL_NAMES, 'blocked')) |
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' ?
if: ! (contains(env.LABEL_NAMES, 'pending review') != contains(env.LABEL_NAMES, 'in progress') !=
contains(env.LABEL_NAMES, 'blocked'))
...
exit 1
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.
xor
would treat true
, true
, true
the same as true
, 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 using xor
here as an analogy or they actually have the very same effect.
solutions i could think of:
- collect these results in a list and count how many
true
s we have. - add up the
contains
result 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#operators
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.
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' if
clause and write the complete logic inside the run:
in good old bash instead.
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 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:
Allow any number of labels, but only one of the following labels must be present at a time:
['status: pending review', 'status: in progress', 'status: blocked']
. These labels cannot be set together.
then I suggest to leave GH actions expression.
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.
bash is more flexible, but less readable with more code lines required.
i would argue that the current check is harder to read than if it was written in bash.
it would look like this
- name: Check PR labels
env:
LABEL_NAMES: ${{ toJson(github.event.pull_request.labels.*.name) }}
run: |
# Convert LABEL_NAMES (JSON) to a string
LABEL_NAMES_STR=$(echo "${LABEL_NAMES}" | jq -r '.[]')
# Define allowed labels
ALLOWED_LABELS=("status: pending review" "status: in progress" "status: blocked")
MATCHED_COUNT=0
# Check for matches in LABEL_NAMES
for label in "${ALLOWED_LABELS[@]}"; do
if echo "$LABEL_NAMES_STR" | grep -Fxq "$label"; then
((MATCHED_COUNT++))
fi
done
# Validate exactly one match
if [[ "$MATCHED_COUNT" -ne 1 ]]; then
echo "PR must have exactly one of these labels: ['status: pending review', 'status: in progress', 'status: blocked']."
exit 1
fi
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
- name: Check PR labels
env:
LABEL_NAMES: ${{ toJson(github.event.pull_request.labels.*.name) }}
if: "!((contains(env.LABEL_NAMES, 'pending review') && !contains(env.LABEL_NAMES, 'in progress') && !contains(env.LABEL_NAMES, 'blocked'))
|| (!contains(env.LABEL_NAMES, 'pending review') && contains(env.LABEL_NAMES, 'in progress') && !contains(env.LABEL_NAMES, 'blocked'))
|| (!contains(env.LABEL_NAMES, 'pending review') && !contains(env.LABEL_NAMES, 'in progress') && contains(env.LABEL_NAMES, 'blocked')))"
run: |
echo "PR must have "exactly one" of these labels: ['status: pending review', 'status: in progress', 'status: blocked']."
exit 1
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.
we have only one PR label starting with "status:" (if not then error 'duplicate status')
I dont see problem of having status: pending review
and status: pending contract deployment
or status: pending infra
etc together.
Only one status i doubt is status: invalid
I would move it to PR must have "exactly one" of these labels
list
PR labels contain any from the list of allowed labels.
I 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 dont understand what do you mean, above you suggested to have only one status label
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')
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 understand what do you mean, above you suggested to have only one status label
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')
these also will lead to move the whole logic to run block using bash, while we can do the same right in one if
block using GH actions expressions and it will use run
only in the case of false
result.
- name: Determine label validity
id: label_check
env:
LABEL_NAMES: ${{ toJson(github.event.pull_request.labels.*.name) }}
run: |
status_count=$(echo "$LABEL_NAMES" | jq '[.[] | select(startswith("status:"))] | length')
allowed_status_count=$(echo "$LABEL_NAMES" | jq '[.[] | select(. == "status: pending review" or . == "status: in progress" or . == "status: blocked")] | length')
if [ "$status_count" -eq 1 ] && [ "$allowed_status_count" -eq 1 ]; then
# Valid scenario
echo "valid=true" >> $GITHUB_OUTPUT
else
# Invalid scenario
echo "valid=false" >> $GITHUB_OUTPUT
fi
- name: Check PR labels
if: steps.label_check.outputs.valid == 'false'
run: |
echo "PR must have exactly one of these labels: ['status: pending review', 'status: in progress', 'status: blocked']."
exit 1
I am testing 1inch api with wasm (maybe more fixes will be here) |
BTW no fixes for wasm is expected for now. We discovered that for wasm we can call 1inch API only via komodo-proxy (due to the CORS check by 1inch API) |
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 guess it could be nicer to write it in plain bash style but I don't mind that (it's not that critical). If it works, it's fine.
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.
LGTM
* dev: (35 commits) fix(crypto): allow non bip39 mnemonics storage (KomodoPlatform#2312) fix(legacy_swap): check for existing maker/taker payment before timeout (KomodoPlatform#2283) feat(tendermint): validators RPC (KomodoPlatform#2310) chore(CI): validate Cargo lock file (KomodoPlatform#2309) test(P2P): add test for peer time sync validation (KomodoPlatform#2304) fix mm2_p2p dev build (KomodoPlatform#2311) update Cargo.lock (KomodoPlatform#2308) chore(CI): unlock wasm-pack version (KomodoPlatform#2307) add `wasm` feature on WASM for timed-map (KomodoPlatform#2306) replace broken rpc link (KomodoPlatform#2305) chore(eth-websocket): remove some unnecessary wrappers (KomodoPlatform#2291) improvement(CI): switch to proper rust caching (KomodoPlatform#2303) fix(wasm): add test-ext-api feature to mm2_main and mm2_bin_lib tomls (KomodoPlatform#2295) chore(ci): Update docker build for wasm (KomodoPlatform#2294) chore(p2p): follow-up nits (KomodoPlatform#2302) feat(p2p): ensure time synchronization in the network (KomodoPlatform#2255) bump libp2p (KomodoPlatform#2296) chore(adex-cli): use "Komodo DeFi Framework" name in adex_cli (KomodoPlatform#2290) chore(ctx): replace gstuff constructible with oncelock (KomodoPlatform#2267) don't rely on core (KomodoPlatform#2289) ...
…#2295) * add feature flag to mm2_main and mm2_bin_lib tomls * filter 'status:' pr labels * remove old labels * dont allow to pass blocked and invalid statuses * pass in progress and pending review statuses * update statuses list
…#2295) * add feature flag to mm2_main and mm2_bin_lib tomls * filter 'status:' pr labels * remove old labels * dont allow to pass blocked and invalid statuses * pass in progress and pending review statuses * update statuses list
…#2295) * add feature flag to mm2_main and mm2_bin_lib tomls * filter 'status:' pr labels * remove old labels * dont allow to pass blocked and invalid statuses * pass in progress and pending review statuses * update statuses list
Fixes wasm build with feature flag
test-ext-api
also fixes CI PR lint, checking new
status:
labels