Packages for the newly released Debian 10 "buster" distribution can now be built by adding debian-10 to the list of your targets in your .pkgr.yml file:
targets:
debian-10: trueHappy packaging!
Repository URLs for deb and rpm downloads have been updated for all repositories, as part of a change that decouples the application that builds your packages (packager.io), from the one that hosts them (dl.packager.io). This is quite a big change under the hood, but all previous repository URLs should keep working (if not, please email ASAP at support@packager.io). Download tokens from private repositories have all been migrated as well.
As it stands, the previous URLs will keep being supported for some time, and you will receive an email a few months in advance when a date has been set for their removal. However, you are strongly encouraged to update your URLs in documentation and scripts as soon as possible, since you will not incur additional redirects, and the analytics will also work better if you use the new URLs.
Speaking of analytics, the ones currently displayed are frozen while we re-import the previous stats into the new hosting backend. An announcement will be made when they are back to normal.
In terms of new notable features, I have introduced the following:
faster builds, as well as explicit duration indication (for new builds)
more realtime updates across the site
active builds across all your repositories will be displayed on your dashboard page
a "Last Release" section allows to quickly see the install instructions for the latest package release in a specific distribution
revamped navigation menu to be able to quickly switch to another organization/repository
possibility to enable/disable authenticated access to packages
Also, the project's page explicitly states the mode you're in, and the consequences:
I hope you'll find the revamped UI easier to navigate, and please let me know if you encounter any issues.
The python buildpack has just been added to Packager.io. You can now package and serve all your python apps for Ubuntu, Debian, CentOS/RHEL, and SuSE distributions!
To test it, just enable your python app, trigger a build, and it should just work! If not, please send an email at support@packager.io
For reference, we're using the official Heroku python buildpack, with only minor changes to get precompiled python binaries for your target platform(s).
For those of you who use a lot of short-lived branches, and build packages for all of them, it may have been slightly annoying to not have those branches removed from Packager.io when you remove them from your git repository.
This is no longer the case, as branch presence is now kept in sync with your repository. We also went back in time and removed any existing branch on Packager.io that is no longer present in the corresponding git repository.
Happy packaging!
Rejoice, we've just added official support for 3 more distributions! The latest Debian stable ("jessie"), CentOS/RHEL 7, and last but not least Suse Linux Enterprise Server 12. Which means with every code push you can now automatically package and publish your Rails, NodeJS, or Go app for up to 8 target distributions!
Happy packaging!
When you package a Rails application on Packager.io, by default you'll end up with init scripts to run your application with the web server you defined in your Procfile. This allows you to install the package on any server and get your application running very easily with my-app scale web=1.
However, if you're already using Passenger for your deployments, you might want to keep it that way, in which case you can still benefit from the ease of installation provided by packages, but serve your application using Passenger.
In the rest of this article, we're assuming that nginx and Passenger are already installed on your server, and that your application name is my-app. You can very easily adapt the following instructions for apache2 + Passenger.
Passenger will need to know which ruby you want to use to load the application. We could directly point to the ruby binary embedded with your package, however it would not load any of the environment variables that you defined, which would not allow the application to start properly. The easiest way to fix this is to create a new file that will delegate any arguments to the CLI that comes with every package, which will take care of all of this for you.
For instance, you could create a new file in packaging/ruby with the following content:
#!/bin/sh
exec "/usr/bin/my-app" "run" "ruby" "$@"
Then give it the right permissions, commit to your repository and push:
chmod a+x packaging/ruby
git add packaging/ruby
git commit -m "Add packaging/ruby"
git push
Wait a few seconds until your new package is generated, then install it on your server with the usual instructions.
We can now simply update the nginx configuration so that the passenger_ruby configuration option points to your application's ruby. A minimal nginx configuration would look like:
server {
listen 80;
server_name my-server.com;
root /opt/my-app/public;
passenger_enabled on;
passenger_ruby /opt/my-app/packaging/ruby;
}
Reload nginx:
service nginx reload
That's it! Passenger should now load and serve your application when you access http://my-server.com:80.
Passenger provides a mechanism to restart your application by touching a specific file at tmp/restart.txt. We can choose to automate this process by adding a postinstall hook to our package, and we'll also automatically run the database migrations if a DATABASE_URL is properly set:
In your .pkgr.yml file add the following line:
after_install: packaging/hooks/postinstall.sh
Now create a new file at packaging/hooks/postinstall.sh with the following content:
#!/bin/bash
set -e
if my-app config:get DATABASE_URL ; then
my-app run rake db:migrate
fi
touch tmp/restart.txt
exit 0
Finally, add and commit these files to your repository and push to generate a new package:
git add .pkgr.yml packaging/hooks/postinstall
git commit -m "Automatically migrate and restart our app"
git push
Now, every time you install a new version of your package, migrations will be run and Passenger will restart your application.
Happy packaging!
OpenProject is currently the most active project on our platform, with more than 10000 package downloads and 1500+ active installations over the world. Below is a screenshot of their download map a few days ago:
Head over their blog post to learn more about their use of the Packager.io service.
Joola is a data middleware for building custom analytics applications, written in NodeJS. And they just wrote a great blog post explaining how easy it is to package and distribute a NodeJS app for several distributions using Packager.io.
Also, the rationale behind their decision should be familiar to anyone who has ever wanted to distribute a NodeJS app:
However, while [installing via npm] works well for developers, it's not ideal for users for several reasons:
- Every time your install Joola, it needs to download and install all the dependencies.
- Some dependencies require compilation, which may fail.
- Dependencies have their own life-cycle, so we might have a situation where a user is using a newer dependency package than one we've tested.
- The installation process can be lengthy if we include the
geo-ipdictionary for IP lookups.- npm is designed for libraries, so the user ends up with
./node_modules/joolainstead of using "proper" system folders.- npm installation process does not relate to group, user, directories, permissions etc... creation, so we're quite limited in providing Joola as a service.
- Users can install the package either globally or locally and we want to have uniformed configuration/logging/etc... folders.
Check out the full blog post !
It took a bit longer than expected, but Ruby 2.2.0 is now available on Packager.io.
Happy packaging!
