Run as a daemon about buildasaur HOT 11 CLOSED

Hi @valeriomazzeo, thanks for the idea. Before I can look into it, I need to understand better what you're trying to achieve.

I see two things you're saying:

1. Running as a daemon
   Currently Buildasaur runs as a background app, which means there is no Dock icon and the configuration window can be closed. The app will keep running and you'll see a menu bar icon, from which you can open the config window again and also see the status of your syncers. AFAIK this is also how XBotBuilder works, it's just a background app.
   My question: What do you mean by running 'headless' in the context of Buildasaur?

• No need to have your project checked out when running Buildasaur
  
  I see your point and I was actually planning on making that easier. In the current implementation, all the necessary info is pulled straight from your project's Xcode files, so I will always need to check out the project somewhere, but by checking it out in a temp directory I would make this process much easier for the user when getting started. See #81.

And just to explain my original thinking - I am aware of XBotBuilder, but my issue with it is that you need to add way too many pieces of information, which can easily be inferred if you have access to the Xcode project. I set out to only ask for the absolute minimum pieces of information from the user and always try to figure out the necessary details automatically. XBotBuilder went a different way, by putting a bit more of the responsibility to setup the configuration correctly on the user (because it doesn't perform any validation, so you might end up with malformed bots), but at the same time it doesn't need to have access to your project's Xcode files. Bot projects are driven by different priorities, while XBotBuilder's might have been self-containment, for me it has always been the ease of getting up and running, especially for people who don't know the details of how all the Xcode files are structured and what they do.

However, I am absolutely willing to make changes to be able to work for more people, so I would really appreciate if you could describe your workflow and what you're trying to achieve. Thanks! 👍

from buildasaur.

First, let me thank you for taking this improvement into account.

What I am trying to achieve is to be able to run buildasaur as a service.

Please consider the following scenario:

There is a machine running OS X server with Xcode Server.
This machine has only an administrator account and it's managed remotely.
Xcode server doesn't need any additional user which means if the machine is restarted Xcode server is going to automatically start again (because is a service), without any need to login into any user account.

I think it would be nice and hopefully would make sense due to the nature of buildasaur for it to be a service rather than an app.

Maybe, I am missing something, but is it possible to run buildasaur from a system account that doesn't have any home folder and no login access? This would be equivalent to create a plist into Library/LaunchAgents and having launchd running it every time the machine start.

My thought is that buildasaur needs the window server to run because it loads some UI elements so that won't be possible in the current state of things.

This kind of setup would be more similar to what OS X does. There are some services like Xcode server and then there is a Server app which is an user interface to monitor/configure those services. In the same way would be nice if buildasaur was a service running as a daemon and the App only the interface that talk to that service.

I hope I have been clear enough in explaining the concept.

Thanks again 👍

from buildasaur.

Thanks, @valeriomazzeo, this makes a lot of sense.

I never considered this case, but it would be ideal to have it setup this way. Right now the syncing logic in Buildasaur is not dependent on its UI, only to get it started, but all preferences are saved on disk in ~/Library/Application Support/Buildasaur. So in theory I could make a build of it as a binary that would immediately load its prefs and start all its syncing right away. This is something that should be very easy to do, I just haven't had time to do it yet (I was busy with Xcode 7 support).

And yes, in theory we could add it to Launch Agents so that it gets started on startup. Again, something I thought about but haven't had time to do yet.

If I understand it correctly, we would have Buildasaur the service running at all times and you'd only launch the Buildasaur app to administer it, e.g. change its settings, start or stop it. I agree this will be the end game of what I eventually want Buildasaur to be.

One thing I'm not sure about is the lack of an additional user to achieve this. Xcode Server actually has its own group of users, called xcs. And the build user is called _xcsbuildd, for example. Open Activity Monitor sometime when Xcode Server is building your app and see processes from all users. This _xcsbuildd user has its home folder in /var/_xcsbuildd. This user is automatically created when you're installing Xcode Server with a binary hidden deep down in Xcode called xcssecurity. (I wrote about some of this stuff in an article I wrote about Xcode Server.)

I am planning a big UI redesign, multi-repo support and more for Buildasaur 1.0 that I will be working on this summer. If we can define a good spec together for how this should behave, I'm sure I could add it to the list for 1.0 (and if you'd be willing, I'd love your contributions). Again, it makes perfect sense and I'm sure there will be more people trying to use it in a similar fashion.

Feel free to post links to articles/apps that work in a similar way. That would help me learn how to do this properly. Or again, if you have experience with it, I'd love your contributions or even just feedback.

from buildasaur.

When setting up a launchd script (plist) you can specify the user that is going to run it.

In your case it would make sense to have a user called buildasaur that would be the owner of the process.

In this way the preferences could be either global or in ~/Library/Application Support/Buildasaur then relative to the home directory of the buildasaur user itself.

Please take a look at this gist: https://gist.github.com/jaredbeck/950922

As you mention I think the user can be created during the installation process and the gui can be used to administer it (maybe even remotely).

from buildasaur.

Cool, I added this to the run up to 1.0, so I'll try to work on this for the big release later this summer. I would love your contributions if you have time.

from buildasaur.

This: https://github.com/jatoben/CommandLine might be useful for the CLI.

from buildasaur.

Related to #100.

from buildasaur.

for the time being just having an autostart option would help, probably not ideal as the daemon idea but it will ensure that if the server is restarted buildasaur is able to run without any further interaction after login.

from buildasaur.

Sounds good, subscribe to #155.

from buildasaur.

Okay @valeriomazzeo, see #178 - I added the option to automatically launch Buildasaur on login. Combined with the autostart-syncers option already in 0.6, when 0.6.2 comes out (probably Friday), you'll be able to start Buildasaur on a server and when you reboot it, Buildasaur will automatically launch itself and start syncing. Hope that's close enough to what you originally needed. :)

from buildasaur.

yeah that's ok, obviously it still requires a login session to run which means you have to setup an user to automatically login on your server in order to start buildasaur, which is not ideal.

from buildasaur.