I would like to execute migration file "6_deploy_and_register_group.js" every time when I need to create a new group. Is this a proper way to use migrations? If yes, how can I make it working? Calling:

truffle migrate 6_deploy_and_register_group.js 

gives me that "network is up to date". Is there any way to execute only that file but have stored other addresses unchanged?


var Registry = artifacts.require('./Registry');

module.exports = async function(deployer, network, accounts)
    await deployer.deploy(Registry);


var Group = artifacts.require('./Group');
var Registry = artifacts.require('./Registry');

const args = require('minimist')(process.argv.slice(2));

module.exports = async function(deployer, network, accounts)
    let units = args["itemscount"];
    if(units == null)
        console.log('\x1b[31m%s\x1b[0m', 'did you forget to use --itemscount=xyz argument?');
    let groupName = args["groupname"];
    if(groupName == null)
        console.log('\x1b[31m%s\x1b[0m', 'did you forget to use --groupname=xyz argument?');
    await deployer.deploy(Group, groupName, units);
    let registry = await Registry.deployed();
    await registry.register(Group.address);

No, this is not a good use of migrations.

Migrations are about deploying the system to the network and one-time initialization steps. This function seems to be about operations - creating instances of Groups and registering them in the Registry.

It's unclear but likely that this process should be restricted to an authorized admin user or minimally there should be an assurance that the registered contract is indeed a Group and not merely a random address. Some protections are needed here to avoid chaos and an off-chain approach won't provide that assurance.

In my opinion, a default approach is to severely limit what is acceptable.

  1. A Registry that only accepts legitimate Group contracts. One approach would be to restrict it to only listen to a trusted Factory contract.
  2. A Factory that only lets authorized user deploy a new Group and attends to the registration.

A factory contract would ensure that deployed Group contracts are built from the same template. Here is a very skeletal sketch to give you some ideas:


import "./Group.sol";
import "./RegistryInterface.sol";

contract GroupFactory is Owned {

  RegistryInterface r;

  function setRegistry(address reg) public onlyOwner {
    r = RegistryInterface(reg);

  function createAndRegisterGroup(bytes32 groupName, uint units) public onlyOwner {
    Group g = new Group(groupName, units);


address public factory;
address[] public groupList;

modifier onlyFactory {
  require(msg.sender == factory);

function setFactory(address _factory) public onlyOwner {
  factory = _factory;

function registerGroup(address group) public onlyFactory {

Above is a very simplistic sketch with simple access control restrictions. You would deploy a Registry once and a factory once. Following deployment, you would rely on the factory to deploy new Groups. There is some more discussion on Factory contracts over here: Deploy contract from contract in Solidity

The migrations would be concerned with the initial deployment as well as the configuration steps - setting the Factory address in the Registry and setting the Registry address in the Factory.

Hope it helps.

  • Thanks. If I use factory in migration or test I can't get the result address of factory built. I can't return address of newly created group because it returns the hash. Watching event doesn't work in migration or test, tried on google but none is working. – Radeg90 Jan 13 at 12:15
  • You can use factories in tests and migrations, you can get the address of the contracts created by a factory, you can watch events. Those are candidates for new questions so this thread stays focused on a single question. – Rob Hitchens - B9lab Jan 13 at 15:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.