So I deployed an application twice. But i just want to make changes to first one. So how to do that? This is my summary:
Summary
=======
> Total deployments: 2
> Final cost: 0.003708932511868584 ETH
EVM bytecode is immutable by design. Once you deploy a contract, you cannot change its implementation.
You can change the source code, re-compile it, and then deploy it to a new address. Note that the newly deployed contract does not hold the storage values of the previous one.
Related
The problem is that I am trying to make free read-only calls to a smart contract on the Hedera network, but am encountering unexpected results. I have tried various methods, but am unable to successfully make the calls without incurring charges. I am looking for a solution or guidance on how to properly make these free read-only calls to the smart contract on Hedera.
//Create the transaction
const transaction = new ContractExecuteTransaction()
.setContractId(newContractId)
.setFunction("get_message")
I expected this get_message to not charge me HBAR since that function just returns a hardcoded string but I cant execute it for free like I want to. How do I do this?
If you're using the SDK, using ContractCallQuery() is better suited for read-only queries. See sample below:
// Query the contract to check changes in state variable
const contractQueryTx1 = new ContractCallQuery()
.setContractId(contractId)
.setGas(100000)
.setFunction("get_message";
const contractQuerySubmit1 = await contractQueryTx1.execute(client);
Note that the SDK still requires some small amount of gas.
There are a couple of other ways to do cost-free queries.
Use mirror nodes. These two tutorials can give you additional information on working with mirror nodes: https://hedera.com/blog/how-to-inspect-smart-contract-transactions-on-hedera-using-mirror-nodes and https://hedera.com/blog/how-to-look-up-transaction-history-on-hedera-using-mirror-nodes-back-to-the-basics
If you use Hashio (https://swirldslabs.com/hashio/) as a JSON-RPC relay, then you can use EVM tooling to deploy and interact with contracts on Hedera. Then you can simply call contracts the way you would in a chain like Ethereum. Here are some examples: https://github.com/hashgraph/hedera-json-rpc-relay/tree/main/tools
I am trying to deploy this contract
https://github.com/juustesout/EtherRanger/blob/main/EtherRanger.sol
to BSC Testnet, and I get this error in return :
"revert
The transaction has been reverted to the initial state.
Note: The called function should be payable if you send value and the value you send should be less than your current balance.
Debug the transaction to get more information. "
this is an example of a failed transaction on BSC Testnet
https://testnet.bscscan.com/tx/0x5cbe0adcf6a522d89c974cadf70358dd9d79476988b4fb829fc1cc86c88aff0c
I tried forking multiple contracts from BSC, working tokens, but I always get the same error. I tried adding 'payable' to the constructor function, as other StackOverflow posts suggest, but no go. I have been reading any number of posts through Google Search, but I am getting nowhere.
The contracts compile flawless, no errors, no warnings, but they just won't deploy.
Could someone check if they can deploy this contract on BSC Testnet ? It may be a setting on my Remix or something, I am at a loss, I cannot tell where the error comes from.
I don’t know anything about this contract but I guess the hardcoded addresses for the IBEP20 and others are the problem. You need to deploy these contracts too and then pass their addresses to the interface addresses in your constructor.
But to connect to the BSC test network, you need to find the drop-down menu with a list of networks at the top of the MetaMask
https://domhtml.ru/en/sozdanie-sobstvennyh-tokenov-standarta-bep-20-v-seti-binance-smart-chain-bsc-pri-pomoshhi-remix-ide/
I am studying how to make BEP-20 tokens. For this I copied the following contract in remix to be able to study it:
Contract in BscScan
If I copy the whole file and compile it in Remix, when I deploy it it doesn't show me any getters. No public view function appears. If I look at the contract displayed on the testnet, it doesn't have any supply of tokens either.
I separated the files and libraries for a better reading. And it is then, when I try to display it, that I get the following error:
VM error: revert. revert The transaction has been reverted to the initial state. Note: The called function should be payable if you send value and the value you send should be less than your current balance. Debug the transaction to get more information.
It gives me the feeling that this contract does not generate the tokens ... What am I wrong?
I managed to fix the problem. As I suspected, in order to deploy the contract I have to remove everything related to uniswap and cakeswap. This displays the contract correctly.
If you wanted to deploy the contract with the uniswap interfaces in injected web3, you would need the uniswap testnet.
I found a test address for cake here:
Binance Smart change tesnet
we are using Spinnaker to automate our deployment pipelines. As part of the pipelines we have some custom stage that generate change tickets in JIRA for the release (some mandate we have from a regulatory perspective). The custom stage then waits for the change ticket to be approved and moves on. This all works perfectly.
What we are now trying is to add another stage at the end of the pipeline that moves the change ticket to done. For this, we would somehow need to be able to catch the JIRA ticket reference in the previous custom stage and pass it to this custom stage which can then move the JIRA ticket to done using the ticket reference that was passed to it.
Did anyone try passing data from one custom stage to another before?
Looking forward to your responses,
Moritz
Add a new parameter in your configuration stage:
Now assign the Jira ticket number from your Create ticket stage to this variable. The value can be accessed based on how you call the JIRA api and how you get the output. The output can be accessed by spinnaker expressions, for example I am accessing the output for a stage (type: Find Image name from prod cluster stage) like this ${#stage("stagename")["outputs"]["artifacts"][0]["version"]}. This expression cannot be reused and will be unique to your call and how you get the output. So change the expression accordingly. ${parameters.jiraTicket} = ${#stage("stagename")["outputs"]["artifacts"][0]["version"]}
In your 3rd stage you can now use the spinnaker expression ${parameters.jiraTicket} and then close the jira ticket.
You can ignore the steps 1 and 2 and directly use the spinnaker expression from step 2 in step 3 as well.
I was tasked with creating a health check for our production site. It is a .NET MVC web application. There are a lot of dependencies and therefore points of failure e.g. a document repository, Java Web services, Site Minder policy server etc.
Management wants us to be the first to know if ever any point fails. Currently we are playing catch up if a problem arises, because it is the the client that informs us. I have written a suite of simple Selenium WebDriver based integration tests that test the sign in and a few light operations e.g. retrieving documents via the document api. I am happy with the result but need to be able to run them on a loop and notify IT when any fails.
We have a TFS build server but I'm not sure if it is the right tool for the job. I don't want to continuously build the tests, just run them. Also it looks like I can't define a build schedule more frequently than on a daily basis.
I would appreciate any ideas on how best achieve this. Thanks in advance
What you want to do is called a suite of "Smoke Tests". Smoke Tests are basically very short and sweet, independent tests that test various pieces of the app to make sure it's production ready, just as you say.
I am unfamiliar with TFS, but I'm sure the information I can provide you will be useful, and transferrable.
When you say "I don't want to build the tests, just run them." Any CI that you use, NEEDS to build them TO run them. Basically "building" will equate to "compiling". In order for your CI to actually run the tests, it needs to compile.
As far as running them, If the TFS build system has any use whatsoever, it will have a periodic build option. In Jenkins, I can specify a Cron time to run. For example:
0 0 * * *
means "run at 00:00 every day (midnight)"
or,
30 5 * 1-5 *
which means, "run at 5:30 every week day"
Since you are making Smoke Tests, it's important to remember to keep them short and sweet. Smoke tests should test one thing at a time. for example:
testLogin()
testLogout()
testAddSomething()
testRemoveSomething()
A web application health check is a very important feature. The use of smoke tests can be very useful in working out if your website is running or not and these can be automated to run at intervals to give you a notification that there is something wrong with your site, preferable before the customer notices.
However where smoke tests fail is that they only tell you that the website does not work, it does not tell you why. That is because you are making external calls as the client would, you cannot see the internals of the application. I.E is it the database that is down, is a network issue, disk space, a remote endpoint is not functioning correctly.
Now some of these things should be identifiable from other monitoring and you should definitely have an error log but sometimes you want to hear it from the horses mouth and the best thing that can tell you how you application is behaving is your application itself. That is why a number of applications have a baked in health check that can be called on demand.
Health Check as a Service
The health check services I have implemented in the past are all very similar and they do the following:
Expose an endpoint that can be called on demand, i.e /api/healthcheck. Normally this is private and is not accessible externally.
It returns a Json response containing:
the overall state
the host that returned the result (if behind a load balancer)
The application version
A set of sub system states (these will indicate which component is not performing)
The service should be resilient, any exception thrown whilst checking should still end with a health check result being returned.
Some sort of aggregate that can present a number of health check endpoints into one view
Here is one I made earlier
After doing this a number of times I have started a library to take out the main wire up of the health check and exposing it as a service. Feel free to use as an example or use the nuget packages.
https://github.com/bronumski/HealthNet
https://www.nuget.org/packages/HealthNet.WebApi
https://www.nuget.org/packages/HealthNet.Owin
https://www.nuget.org/packages/HealthNet.Nancy