These products have been deprecated and are no longer being maintained. For a better experience and support, please check out our new stack Aragon OSx.

How to publish an Aragon App to aragonPM

This guide will show you how to publish an App to aragonPM on different environments.

Note 1. Publishing your app requires an on-chain action so you must connect an Ethereum account with enough funds on the selected environment to send a publish transaction.

2. Secondly, your app's frontend content is uploaded to IPFS and it becomes your responsibility to ensure that it stays available to users. Click here to learn more about IPFS and pinning files.

Environment setup

Before starting you need to check if you have already installed all these prerequisites:

  • the right version of node.js (recommended v12 LTS version)

  • Metamask web3 provider

  • the aragonCLI (Aragon Command Line Interface)

  • the Aragon Buidler plugin

  • an IPFS server.

If you haven't already installed them or if you need more info about this goes to the "Environment Setup" paragraph here.

Setup

We'll start from the Aragon React boilerplate.

npx create-aragon-app <app name>

Make sure you choose a unique app name which has not yet been registered in the aragonpm.eth or open.aragonpm.eth registries since that would lead to an error later on.

This will create a new directory named <app name> with everything you need.

To interact with aragonPM we will use the Aragon Buidler plugin already installed in the boilerplate repository.

We will also need a running IPFS server. Open a new Terminal tab and run:

For this tutorial, we will assume that the IPFS server is running locally with its:

  • API port set to 5001

  • gateway port set to 8080.

If you need an IPFS pinning services, you can chose service like Pinata and Eternum. They are also available for a reasonable price.

Introduction to environments

This App has 3 environments defined:

Environment
Network

default

localhost

rinkeby

rinkeby

mainnet

mainnet

It is a prerequisite to have a ENS Registry address defined.

Environments are defined in arapp.json, for example rinkeby points to:

  • An ENS registry: 0x98df287b6c145399aaa709692c8d308357bc085d

  • An app name (repository and registry of aragonPM): <app name>.aragonpm.eth

  • An Ethereum network: rinkeby

Note The default environment which points to localhost does not have an ENS Registry address specified because the Buidler plugin will default the value to 0xB9462EF3441346dBc6E49236Edbb0dF207db09B7 (the ENS Registry pre-deployed on the local development chain).

Publish a major version: content + contract

To publish the app on aragonPM we will use the following builder task for this tutorial:

aragonpm.eth is a curated ens registry. So unless your app has been curated by Aragon, you can publish your app on open.aragonpm.eth.Read more about it here.

You will likely run into the following error:

Account 0xb4124cEB3451635DAcedd11767f004d8a28c6eE7 does not have permissions to create a new repo in registry aragonpm.eth

To solve this open arapp.json and replace <app name>.aragonpm.eth with <app name>.open.aragonpm.eth for the network you are publishing to (in this case Rinkeby).

This command will:

  • Apply version bump (major).

  • Compile and deploy the app's contract (by default the output lives in build).

  • Build the app's frontend (by default the output lives in dist).

  • Generate application artifact.

  • Publish the app to the rinkeby environment.

  • Upload the app's frontend to the IPFS server.

Sample output:

In case of 'outdated' or 'cannot resolve dependencies' errors, update and install dependencies.

Note You can also deploy a major version with only frontend changes by passing the flag: --only-content.

The contract location is defined in arapp.json under path.

Task syntax and options

The publish task has the following syntax:

Where global options are Buidler's (now Hardhat) global options and bump is the version bump (either major, minor or patch) or the semantic version. E.g. minor would increase version 1.2.0 to 1.3.0.

The following task options are available:

  • contract: Address of the app's deployed smart contract.

  • manager-address: Permissions manager of the app's aragonPM repo. Must be provided in the initial release.

  • ipfs-api-url (default: http://localhost:5001): IPFS API URL to connect to an IPFS server.

  • only-content (flag): Prevents contract compilation, deployment and artifact generation.

  • verify (flag): Enables Etherscan verification.

  • dry-run (flag): Output transaction data without broadcasting.

Check published versions

To fetch the versions published on aragonPM, we can use the aragon apm versions command from aragonCLI.

Command:

Sample output:

If you have an error similar to:

You need to add a truffle.js file to the root folder where you are running the command.

Add the following content and saveshell:

Fetch other packages versions

We will fetch the published versions of the official voting app on the rinkeby (rinkeby network) environment.

Command:

Sample output:

Building frontends

Your application's frontend will have another build script associated with it, to transpile, bundle, and pack all of its assets (e.g. scripts, images, fonts, etc) together.

If you've used the Aragon React boilerplate, this has already been set up for you with parcel-bundler and aragonUI.

If you need to add, modify, or remove assets or the way the frontend is built, it's important to remember to always use relative paths to serve those assets. Usually, this can be accomplished by adding a ./ in front of the path.

This is important because in production, the Aragon client usually fetches all of an app's assets via an IPFS gateway, and non-relative paths break gateway resolutions. You can test this for yourself by attempting to access your app when it's published by going to an IPFS gateway and making sure its assets are being loaded correctly.

PreviousHow to build your first Aragon App!NextHow to migrate existing Aragon App to Buidler plugin

Last updated

Was this helpful?