Test: proposal social post and devcontainer setup

[petersalomonsen]

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]

@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]

What if we add building discussions, community and community-factory in root build.sh and call just this one? @frol

[frol]

1. There are no build.sh scripts anymore
2. We need to implement build.rs that would build the dependency contract
3. Let's use ghcr.io/near/near-devcontainer:latest image for the container, which already has all the NEAR CLIs; you can test the container on https://github.com/near/cargo-near-new-project-template repo

[petersalomonsen]

I've changed to ghcr.io/near/near-devcontainer:latest, and build.sh is not used anymore. Instead cargo near build is invoked from all the subcontract folders, like in the build pipeline.

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. Workspaces is another option, I tried briefly, but not enough to actually make it work.

use std::process::Command;
use std::env;
use std::path::Path;

fn main() {
    let projects = ["discussions", "community", "community-factory"]; 

    for project in projects {
        let project_path = if project == "." {
            env::var("CARGO_MANIFEST_DIR").unwrap()
        } else {
            Path::new(&env::var("CARGO_MANIFEST_DIR").unwrap())
                .join(project)
                .to_str()
                .unwrap()
                .to_string()
        };

        let mut command = Command::new("cargo");
        command.arg("near").arg("build")
               .current_dir(project_path);

        let status = command.status().expect(&format!("Failed to execute cargo near build in {}", project));

        if !status.success() {
            panic!("Failed to build NEAR contract in project: {}", project);
        }
    }
}

[PolyProgrammist]

@petersalomonsen Please request a review from someone with write access

[ailisp]

Looks good. Also the devcontainer setup is very helpful. Thanks!

[ailisp]

I think post-create.sh is a okay setup and it's not worthy to figure out a working build.rs. At the meantime, given contract dependency pattern is common, can it be indicated in cargo.toml and support in cargo-near?

[petersalomonsen]

@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]

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

[frol]

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?