AHTUNG! This article is not relevant for those who use GitHub "to the fullest", and have long known about CI, and how to configure them!
Those who are developing more seriously, of course, know about things like Continuous Integration (CI for short).
For developers of free projects that contain their code on Github (and not only), there are options for free CI. For Github, for example, this is Travis. What is it - I will not tell. To whom it is very interesting, google himself. In short, CI simplifies life by allowing you to execute a certain set of commands on an "empty" machine after each commit or create a release (tag) (any interpreter, compiler or DBMS can be preinstalled there). For example, you created a release on Github with a button, and somewhere in the background of Travis it runs tests for you and collects the release. Convenient, isn't it?
I have been using Travis for about two years, launching the assembly of my add-ons in it. It greatly simplifies life, eliminating the need to collect and publish manually add-ons in the Releases section. I just press the button, fill in the fields, and ... That's it. Some time after creating the release, it has an archive with all the files.
You can collect projects in any language, as well as drive tests.
Looks cool, right? Let's collect releases for XF addons in Travis!
I attached an example config file for Travis to the resource, which will allow you to cleanly collect releases with preliminary import of the contents of the _output folder to the database (it is necessary that it is possible to generate XML files with phrases, etc.).
The essence of Travis is that they provide you with a clean virtual machine, where the packages you need are already installed, and then from the config you just “execute the commands”. Since the machine is bare, we will need to install XenForo. Therefore, it is necessary to fill in the archive somewhere. I will leave this question to you.
Log in to Travis-CI, log in, give rights. We find our repository, go to the settings:
Go to Environment Variables:
For my script, I need to fill in three variables (two of which need to be hidden):
As you guessed, you need to hide the last two variables. By default, Travis hides everything where Display value in build log is not explicitly turned on, so you can take it easy.
After filling in all the variables, we get the following picture:
Since we did not give permission to display BaseURL and FileName, they will be hidden during assembly, and will not even be displayed, respectively. And any attempt to output is stopped (the value will be replaced by [secure]):
Fill in all the fields? Fine!
For some time now, Travis allows you to check your config by running a test build with what is already in the turnip. Previously, you had to constantly commit .travis.yml with edits. Take advantage of this.
The item is in the same place as the transition to the settings:
In the pop-up window, select any brunch, write the name of the commit (if we want) and paste the config into the field:
After you have to wait.
Travis will look for free space for your empty virtual machine, after it starts and starts to deploy everything:
The entire
Upon completion of the assembly, the state of the repository will be updated, and you will be able to see whether the addon is going or not:
In my case, the addon is not even installed due to the lack of dependency in the form of installed [Telegram] Core, but this is a completely different story ...
If everything is fine, we commit .travis.yml and then push. The addon will rebuild again, because Travis will trigger by commit by default.
If something still went wrong - edit the script, try to restart the assembly.
So easily and simply you can configure the check of the ability to install the add-on with subsequent assembly. I will consider publishing releases on Github in the Releases section a bit later, in a separate resource. Or you can figure it out yourself. Everything is very simple. The official guide (if you can call it that) is here.
By the way, you can publish the final build anywhere. Although, instead of publishing to the options prepared by Travis, run a script that will do everything. This way you can automate the publication of releases in your forum (hello, REST API!).
An example of an add-on that is already being assembled in Travis (but so far without publishing releases; the config for Travis was made ~ 1.5 hours ago): XF-Telegram / Core - Travis CI
P.S.: In this config, it is assumed that all addon files are in the upload / folder on the Git. If this is not so, correct the path.
Author: @Kruzya
Those who are developing more seriously, of course, know about things like Continuous Integration (CI for short).
For developers of free projects that contain their code on Github (and not only), there are options for free CI. For Github, for example, this is Travis. What is it - I will not tell. To whom it is very interesting, google himself. In short, CI simplifies life by allowing you to execute a certain set of commands on an "empty" machine after each commit or create a release (tag) (any interpreter, compiler or DBMS can be preinstalled there). For example, you created a release on Github with a button, and somewhere in the background of Travis it runs tests for you and collects the release. Convenient, isn't it?
I have been using Travis for about two years, launching the assembly of my add-ons in it. It greatly simplifies life, eliminating the need to collect and publish manually add-ons in the Releases section. I just press the button, fill in the fields, and ... That's it. Some time after creating the release, it has an archive with all the files.
Looks cool, right? Let's collect releases for XF addons in Travis!
I attached an example config file for Travis to the resource, which will allow you to cleanly collect releases with preliminary import of the contents of the _output folder to the database (it is necessary that it is possible to generate XML files with phrases, etc.).
The essence of Travis is that they provide you with a clean virtual machine, where the packages you need are already installed, and then from the config you just “execute the commands”. Since the machine is bare, we will need to install XenForo. Therefore, it is necessary to fill in the archive somewhere. I will leave this question to you.
Log in to Travis-CI, log in, give rights. We find our repository, go to the settings:
- XENFORO_ADDON_ID. ID of your addon.
- XENFORO_BASEURL. The basic link to the server, where archives with the engine will be taken from.
- XENFORO_FILENAME. The name of the archive with the engine on the remote server.
As you guessed, you need to hide the last two variables. By default, Travis hides everything where Display value in build log is not explicitly turned on, so you can take it easy.
After filling in all the variables, we get the following picture:
For some time now, Travis allows you to check your config by running a test build with what is already in the turnip. Previously, you had to constantly commit .travis.yml with edits. Take advantage of this.
The item is in the same place as the transition to the settings:
Travis will look for free space for your empty virtual machine, after it starts and starts to deploy everything:
Job log is updated online, so you can see what is being done on the Virtual Machine right now.Upon completion of the assembly, the state of the repository will be updated, and you will be able to see whether the addon is going or not:
If everything is fine, we commit .travis.yml and then push. The addon will rebuild again, because Travis will trigger by commit by default.
If something still went wrong - edit the script, try to restart the assembly.
So easily and simply you can configure the check of the ability to install the add-on with subsequent assembly. I will consider publishing releases on Github in the Releases section a bit later, in a separate resource. Or you can figure it out yourself. Everything is very simple. The official guide (if you can call it that) is here.
By the way, you can publish the final build anywhere. Although, instead of publishing to the options prepared by Travis, run a script that will do everything. This way you can automate the publication of releases in your forum (hello, REST API!).
An example of an add-on that is already being assembled in Travis (but so far without publishing releases; the config for Travis was made ~ 1.5 hours ago): XF-Telegram / Core - Travis CI
P.S.: In this config, it is assumed that all addon files are in the upload / folder on the Git. If this is not so, correct the path.
Author: @Kruzya
Last edited: