✨ Feature ➾ Improve SmartPy Workflow in relation to contract and storage compilations and added native SmartPy test #1551
Conversation
Deploying with
|
| Latest commit: |
0c2f887
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://58d656d8.taqueria.pages.dev |
| Branch Preview URL: | https://1475-smartpy-jcc.taqueria.pages.dev |
|
jchenche
changed the title
jchenche
force-pushed
the
1475_smartpy_JCC
branch
from
6e314a9 to
4c4c5f1
Compare
jchenche
force-pushed
the
1475_smartpy_JCC
branch
3 times, most recently
from
c349495 to
9107072
Compare
Stop publishing our flextesa image on every PR and just use the one that ECAD devs use when building locally
jchenche
force-pushed
the
1475_smartpy_JCC
branch
from
9107072 to
eab1672
Compare
…rks on Windows in CICD
Merge in LIGO highlighting brancH.
|
The docker image has been published and is avaiable here. Look for the image with the tag |
|
The docker image has been published and is avaiable here. Look for the image with the tag |
There was a problem hiding this comment.
There was just one missing await statement in the test suite. Other than that, looks good.
Side note, although it doesn't impact the test results when they run correctly, wrapping your test in a try/catch block is unnecessary and actually makes it harder to see where the failure occurred , as the line number of what assertion isn't present.
E.g.:
test('Verify that taqueria SmartPy plugin will output proper error message running taq test <sourceFile> command against invalid test file', async () => {
try {
// 1. Copy contract from data folder to taqueria project folder
await exec(`cp e2e/data/hello-tacos-failed-tests.py ${taqueriaProjectPath}/contracts`);
// 2. Run taq test ${testFileName}
const { stdout } = await exec(`taq test hello-tacos-failed-tests.py`, {
cwd: `./${taqueriaProjectPath}`,
});
expect(stdout).toContain('Some tests failed');
} catch (error) {
throw new Error(`error: ${error}`);
}
});
Should be:
test('Verify that taqueria SmartPy plugin will output proper error message running taq test <sourceFile> command against invalid test file', async () => {
// 1. Copy contract from data folder to taqueria project folder
await exec(`cp e2e/data/hello-tacos-failed-tests.py ${taqueriaProjectPath}/contracts`);
// 2. Run taq test ${testFileName}
const { stdout } = await exec(`taq test hello-tacos-failed-tests.py`, {
cwd: `./${taqueriaProjectPath}`,
});
expect(stdout).toContain('Some tests failed');
});
This is something I had talked to Alex, and I've been removing them as I come across them. But what I think would be better is to create an issue that involves going through each test suite and removing those try/catch wrappers.
🌮 Taqueria PR
Fixes #1475
🪁 Description
Provide a smooth SmartPy workflow for our SmartPy plugin by making it easier to compile and deploy. E.g.
taq compile my_contract.pythentaq deploy my_contract.tz(ortaq deploy my_contract.tz --env testingto deploy to ghostnet) and that's it.Users will define all compilation and expression compilation targets in their main SmartPy contract file and we will compile them all and copy the relevant artifacts (contract, storage, and expression files) to the
/artifactsfolder. All other artifacts will be hidden under/artifacts/.smartpy.Compilation targets in SmartPy produce both the contract and its storage Michelson files. We will name them using the following naming convention:
<CONTRACT_NAME>.storage.<COMPILATION_TARGET_NAME>.tz. But the first of these is special and will be called:<CONTRACT_NAME>.default_storage.tz(the Taquito deploy task will deem this as the default initial storage value).Expression compilation targets in SmartPy produce only the expression Michelson file. We will name them using the following naming convention:
<CONTRACT_NAME>.expression.<COMPILATION_TARGET_NAME>.tz.Native SmartPy testing can now be done with
taq test my_contract.py.In SmartPy and LIGO's compile task,
--jsoncan be specified to emit JSON-encoded Michelson instead of pure Michelson expressions.🪂 Pre-Merge Checklist (Definition of Done)
🚦 Required to merge:
🛩️ Summary of Changes
Please include a summary of the changes to the codebase. Please also include relevant motivation and context for the change
(e.g. what was the existing behaviour, why did it break, etc.)
🎢 Test Plan
Please describe the testing strategy and plan for this PR. Keep this lightweight and anticipate any testing challenges
🛸 Type of Change