Skip to content
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

Merged
merged 6 commits into from
Dec 25, 2024

Conversation

laruh
Copy link
Member

@laruh laruh commented Dec 16, 2024

Fixes wasm build with feature flag test-ext-api

hound@hound:~/komodo-defi-framework$ docker run -v "$(pwd)":/app -w /app kdf-build-container wasm-pack build mm2src/mm2_bin_lib --target web --out-dir wasm_build/deps/pkg/ --features  test-ext-api
[INFO]: Checking for the Wasm target...
info: downloading component 'rust-std' for 'wasm32-unknown-unknown'
info: installing component 'rust-std' for 'wasm32-unknown-unknown'
[INFO]: Compiling to Wasm...
warning: /app/mm2src/mm2_bin_lib/Cargo.toml: file `/app/mm2src/mm2_bin_lib/src/mm2_bin.rs` found to be present in multiple build targets:
  * `bin` target `mm2`
  * `bin` target `kdf`
error: none of the selected packages contains these features: test-ext-api
Error: Compiling your crate to WebAssembly failed
Caused by: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit status: 101
  full command: cd "mm2src/mm2_bin_lib" && "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown" "--features" "test-ext-api"

also fixes CI PR lint, checking new status: labels

@laruh laruh requested a review from smk762 December 16, 2024 10:38
@laruh laruh changed the title add feature flag to mm2_main and mm2_bin_lib tomls fix(wasm): add test-ext-api feature to mm2_main and mm2_bin_lib tomls Dec 16, 2024
@laruh laruh requested a review from dimxy December 16, 2024 10:43
@dimxy
Copy link
Collaborator

dimxy commented Dec 16, 2024

I can see there are PR statuses like 'invalid', 'blocked'. Should we allow to run CI for those?

@@ -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')
Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgot to remove

Copy link
Member Author

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

Comment on lines 53 to 64
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
Copy link
Member

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

Copy link
Member

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

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

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

@laruh
Copy link
Member Author

laruh commented Dec 16, 2024

I can see there are PR statuses like 'invalid', 'blocked'. Should we allow to run CI for those?

hmm I see

smk762
smk762 previously approved these changes Dec 16, 2024
@laruh laruh force-pushed the dev-test-ext-api branch 2 times, most recently from 7fe6547 to 50e1e1e Compare December 16, 2024 13:23
@@ -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'))
Copy link
Collaborator

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

Copy link
Collaborator

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:

Copy link
Collaborator

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)

Copy link
Collaborator

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.

Copy link
Member Author

@laruh laruh Dec 17, 2024

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:

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.

Copy link
Member Author

@laruh laruh Dec 17, 2024

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

Copy link
Collaborator

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.

Copy link
Member Author

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

Copy link
Collaborator

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')

Copy link
Member Author

@laruh laruh Dec 18, 2024

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

@dimxy
Copy link
Collaborator

dimxy commented Dec 16, 2024

I am testing 1inch api with wasm (maybe more fixes will be here)

@dimxy
Copy link
Collaborator

dimxy commented Dec 18, 2024

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)

Copy link
Member

@onur-ozkan onur-ozkan left a 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.

Copy link
Collaborator

@dimxy dimxy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@onur-ozkan onur-ozkan merged commit c5f544c into dev Dec 25, 2024
24 of 32 checks passed
@onur-ozkan onur-ozkan deleted the dev-test-ext-api branch December 25, 2024 08:09
dimxy added a commit to dimxy/komodo-defi-framework that referenced this pull request Jan 17, 2025
* 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)
  ...
shamardy pushed a commit that referenced this pull request Jan 28, 2025
…#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
shamardy pushed a commit that referenced this pull request Jan 30, 2025
…#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
shamardy pushed a commit that referenced this pull request Jan 30, 2025
…#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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants