Public repository result

Configuring submodules on Odoo.sh

In this tutorial I will learn you how to create and use submodules in Odoo.sh. In this example I will create a public submodule and a private submodule and I will link them to the Odoo.sh project.

1. Introduction to submodules

Tip: If you haven’t made an Odoo.sh project yet you can follow my tutorial here.
So, what exactly is a submodule? A submodule is a link from one Github repository to another repository. You can see it as a virtual pointer to a specific commit in time of the remote repository.

For Odoo.sh there are two major differences. You have public submodules and private submodules. Public repositories are those that are publicly available (for example https://github.com/odoo/odoo). Private repositories are the repositories that are not publicly available. Usually you have private repositories when you work for a company and when you manage customer code.
There is a big difference in using public or private submodules on Odoo.sh though. When you have a public repository you can easily add the submodule and it will work. For a private repository you will need to generate a deploy key on Odoo.sh and then add it on the remote Github repository.

1.1 Why use submodules?

Now we know what a submodule is but the question is why would you use a submodule? Submodules are very handy to use if you want to include third party apps in your Odoo.sh tests. The only other way to get this code available in your Odoo.sh builds is to add all this third party code in your own repository. But what if the third party developer has made a lot of changes, fixes or improvements? If you don’t use submodules you will constantly need to download the remote apps, add them to your own repository and keep track of all those changes. This is the true power of submodules. Now let us first link a public repository to the Odoo.sh project in chapter 2. In chapter 3 I will learn you how to add a private repository as a submodule.

2. Public repositories

Setting up public repositories is really very easy to do.
You will need to create a submodule and commit it to Github. Go to your Github repository, switch to the correct branch and add the submodule from the command line:

This new commit will trigger a new Odoo.sh build. After this build is ready you will see that the modules from the OCA/hr repository are available on this instance:
Public repository result
Great job! This is all you need for a public repository. If you also have a private repository and want to add it then continue to the next chapter.

3. Private repositories

Alright now let us configure the use of a private submodule! Go back to your Odoo.sh project to the settings tab and add the link to your private repository (git@github.com:youruser/repository.git). In your repository you could now make a commit to add the repository as a submodule. For a private repository however you have some extra work. You have to copy the generated key from the Odoo.sh project and add it on Github. First copy the key:
Private key configuration submodules
Now go to the repository where you’ve linked to (so the submodule), go to the settings tab, open “Deploy keys” and add your own key here by clicking on “Deploy key”:
Add deploy key Github
Now add the key in the next screen and click on “Add key”:
Deploy key add screen
After doing this Odoo.sh can find the private repository and can access all the data it needs. The final thing you need to do is to add the submodule from the command line, commit it and push it to Github:

This new commit will trigger a new Odoo.sh build. After this build is ready you will see that the modules from your other private repository are available on this instance.

4. Conclusion

Using submodules in combination with Odoo.sh is very powerfull and handy to use. Setting it up in the beginning might take some time and you can make some mistakes but in the long run it will save you a load of time and redundant code. As a result it’ll improve your testing a lot as all your custom code will be automatically tested.
If you can use submodules and want to test your deployments on Odoo.sh then submodules are the way to go.
Has this tutorial helped you, do you have any feedback or questions? Post away!


PayPal

Odoo Experts

Odoo.sh homepage

Configuring and using Odoo.sh

In this tutorial I will learn you how to setup an Odoo.sh account, how to configure Odoo.sh and how to tests your code automatically with Odoo.sh.
In this example I will create a new account, create a new repository and add code to the Github repository in order to explain how Odoo.sh works.

1. Creating an Odoo.sh account

Go to odoo.sh and click on the “Sign in” button at the top:
Odoosh homescreen
When you click on the “Sign in button” you’ll get an authorize screen from Github. If you’re not yet logged in on Github it will ask you to login, if you’re already logged in on Github you’ll get the authorize screen. Click on “Authorize odoo”:
Authorize Odoo
After you click on “Authorize odoo” Github will ask for additional permissions. Click on “Authorize Odoo” again to give the additional permissions. Because of these additional permissions Odoo.sh can follow all changes and handle it automatically for you.
Additional permissions Odoosh
Now Odoo will ask you to deploy your platform. Choose an existing repository if you want to use it or create a new one. In this tutorial I will create a new repository to show everything in detail. Choose a repository name. Next choose the Odoo version you want to test against and finally provide your enterprise (or partner) license. The hosting location is up to you. Finally click on “Deploy”:
New repository settings
Thats it! You’ve just registered your own Odoosh account and connected Github to Odoosh!

2. The Odoo.sh main screen

After you’ve clicked on “Deploy” you’ll now see the main screen of Odoo.sh.
Odoosh main screen
In the left menu you will see the title “DEVELOPMENT”. Under this section you will see every branch you’ve made on this Github repository. If I would create a second branch named “11.0” I would see “11.0” and “master” in the left menu. At the top you’ll see a main menubar with the options “Branches”, “Builds”, “Status” and “Settings.

  • The Branches tab opens the main page, from where you can see everything related to your branches. This includes the mails, shell access to the test instance and access to the logs.
  • The Builds tab opens a page where you can see all your test instances. This is almost identical to the Odoo runbot (at runbot.odoo.com).
  • The Status tab opens a page where you can see all the statistics of the Odoo.sh platform. It shows you the uptime and the status of all the servers.
  • The Settings tab opens a page where you can configure advanced settings. You can add collaborators, set a project name (and URL), add submodules and much more.

3. Github

Now open up your Github and go to your (just created) repository. Add a commit to the repository so that it contains some (new) code. In my example I will push a module to Github that contains an automated test so I can show you how tests work and what happens. If you’d like to do the same you can take my example module from Github. The moment that you make a commit to the Github repository Odoo.sh will detect this and it will start up a test environment because of the new commit. My Github after making a commit:
New commit on Github
My Odoo.sh a few seconds after making this commit:
Odoosh new commit

4. Checking the commit

Now switch back to Odoo.sh. After a few minutes your new commit will procude a new test instance that is ready and built. In my example I’ve deliberately added an error in my last commit so as a result you can see the test fail. When the test instance is done, typically after a few minutes, you’ll see the result in the main screen:
Failed Odoo.sh build

So now my test has failed it means I must have done something wrong. I’ve figured out what was wrong and I correct my test. After correcting this test I make a new commit to Github. After a few seconds you’ll see that Odoo.sh automatically detects and tests this new commit again:
Succeeded Odoo.sh build

5. Odoo.sh builds and test instances

Finally go to the builds page by clicking on “Builds” in the top menu bar. After you click on “Builds” you will see an overview of all your test instances and if they succeeded or not:
Odoosh build page
From this page you can directly connect to a test instance in order to test functionalities or ‘play’ with Odoo.
When a test has failed (such as “INIT: Add demo module wit…” in my screenshot) you can click on the exclamation icon, next to the connect button, to see why your instance has failed:
Failed test output
Tip: If you want to see the full log of the instance you can do this by clicking on the “…” icon at the top of a build and selecting “Logs”. From here you can download and view all logs. Alternatively you can also do this from the “Branches” page by clicking on the “Logs” menu.

6. Conclusion

As Odoo.sh is very big and has a lot of options I’ve decided to split the content in two tutorials. Because of this the first blog post, this one, is only about basic operations. You can find a second tutorial about how to configure public and private submodules here.

Odoo.sh is a very powerfull platform to use. Odoo has invested a lot of time into Odoo.sh and due to this it is an advanced system that allows you to quickly (and easily!) use test instances with Odoo. Thanks to Odoo.sh you no longer need your own runbot instance and complex hardware setup as you can get it all out of the box.

Has this tutorial helped you, do you have any feedback or questions? Post away!


PayPal

Odoo Experts