NEAR-DevHub / neardevhub-contract

DevHub Portal Product Contract (Hosted on NEAR Blockchain) – Includes other instances (e.g. Infrastructure, Events)
https://neardevhub.org
19 stars 15 forks source link

Test: proposal social post and devcontainer setup #91

Closed petersalomonsen closed 8 months ago

petersalomonsen commented 9 months ago

This was originally meant to test for commenting to proposals, but verifying it requires a call to the index ( posting the comment to social db, and then looking up with the same item as the proposal post ), which is not available in the test environment.

What's added here instead, is just a verification that adding a proposal, also creates a post in socialdb.

Another thing is the DevContainer setup which means that the project can be opened in codespaces ( 4 core machine type recommended ).

petersalomonsen commented 9 months ago

@Megha-Dev-19 Because I'm not sure how to verify that a comment is linked to the proposal ( just checking that social.set works is not much of a point from here ), I dropped the idea of testing comments here. However I've added a test for the socialdb proposal post to be created after adding a proposal. I believe that is useful.

PolyProgrammist commented 9 months ago

@petersalomonsen Please request a review from someone with write access

petersalomonsen commented 8 months ago

@ailisp we could at least set up a workspace definition in Cargo.toml, that references the other projects. Something like:

[workspace]
# remember to include a member for each contract
members = [
  "community",
  "community-factory",
  "discussions",
  "."
]

What do you think? Should we do that?

ailisp commented 8 months ago

Sounds good! If cargo-near can support a workspace build I think it solves the whole problem. @frol

frol commented 8 months ago

If cargo-near can support a workspace build I think it solves the whole problem.

@ailisp I don't think workspaces would solve anything here. Workspaces do not compile all the artifacts magically. We still need to explicitly indicate the dependencies for each individual contract.

I did try implementing a build.rs like below, but I gave up because of settings/env propagating from the parent build, and too much too hack into right now.

@petersalomonsen The implementation looks good to me except the fact that it should not be all in one build.rs, but each individual contract should have the build.rs with its own dependency. I am surprised to hear there were setting/env propagation issues. Can you elaborate and share more details / exact error messages?