drewdeponte / octopusci Goto Github PK

I see that a simple version of the page is already built. Are those just the default styles that come with Jekyll?

I was thinking about messing around with zurb/foundation for the project page so that we could have a responsive design. However, I also found http://octopress.org/ which @cyphactor may prefer. Foundation is really just a framework, while Octopress is more of a full blogging platform built on Jekyll. Thoughts?

A plugin should be developed that sends notifications to Flowdock.

https://www.flowdock.com/help/api_gem

It does this even if a warning is just output to the stderr. I think that the reasoning for this is because IO.popen() doesn't support stderr capturing and therefore when it tries to write to stderr it throws an IO Error.

The solution to fixing this problem is switching to popen2 or popen3 or something similar that provides the stdin, stdout, and stderr streams so that we don't get incorrect failures for this reason.

It is ideal to do this so that if the web app crashes or needs to be upgraded, etc the workers in the background can still just keep working away. It also seems there are issues with have the web app startup the workers when using passenger because passenger by default spawns up a few instances of the class.

We need to add the current version to the UI header so that users can see what version of ocotpusci they are running from the web interface.

All the command line tools should also have -v and --version switches that output the version information about the octopusci that they are using.

This is very important because we are about to make our official public release and being able to track bugs against versions is very valuable.

This command line tool is very important to help developers on board. It will basically allow developers to easily test the octopusci locally as if they had pushed some code to github and github had made a post back to their octopusci. The primary benefit to this though is that it would make it so our developers wouldn't have to setup a test github repo, hook up the post commit hook, and setup port forwarding to their development box from the outside world.

t

Sent via Hubroid

It seems there is some sort of issue using sudo in devel to run the octopusci-skel command. It looks to be some how related to bundler. The output of the failure looks as follows:

[octopusci (master *=)]$ sudo ./bin/octopusci-skel 
Password:
/Users/adeponte/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- trollop (LoadError)
    from /Users/adeponte/.rvm/rubies/ruby-1.9.3-p0/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
    from ./bin/octopusci-skel:8:in `<main>'
[octopusci (master *=)]$ 

For some reason it can't seem to find the gems that were installed by bundler when I use sudo for some reason.

This should allow us potentially larger amounts of output storage as well as let us see the output as the job is happen. We may need to modify the current show output link to do more, and potentially use ajax with a timeout to continuously reload the currently visible region so that the user can see the output as it is happening.

push button config with loggly integration.

the text bleeds all over the place.

Sent via Hubroid

This button/link should increase the amount of jobs shown by 20.

This is basically a light weight API request that will return a JSON object which will provide the status of the most recent build of a specific branch name in a specific repository. For example the URI might look as follows:

http://octopusci.yourcompany.com/your_repo/branch_name/status

This will be used as another mechanism for us to get out that word that new releases are available, what those changes have been, etc.

for adding rails_best_practices, brakeman, etc gems to builds

Basically, the idea is that if I can run an install script from the gemspec somehow right after the gem has been installed then I can simplify the install process down to maybe just one command, gem install octopusci.

g

Sent via Hubroid

Basically, I had stopped all the octopusci-tentacles and no jobs were running. While the tentacles were not running 3 job build requests came in, in the following order.

1. my_project_name with branch master
2. my_project_name with branch unable_to_connect_to_social_media
3. my_project_name with branch master

It seems that all three requests came in and that the jobs identified by #1, #2, and #3 were executed and running because the Resque interface shows that three workers were working and were all kicked off at the same time. However, for some reason the oldest master jobs that was running did not get its state updated so it still looks as if it is in a pending state.

You can see this in the following screenshot:

https://img.skitch.com/20111111-r9sy6de1ruyf5r3pxquspj8732.jpg

octopusci-tentacles needs to pull from a config value to determine what non-root user it should be run as when it boots up.

The idea is two fold, one this would provide a working example for people that are just getting started. Two it would make the test status of octopusci even more visible.

This is important in the case where octopusci-tentacles is restarted because of config changes but you don't want to have to restart apache and the web app for those changes to take effect in the web app as well.

This might be as simple as spliting the config loading, but there could be consequences of doing that. For example you could potentially end up in a situation where web app thinks the config is in an old state and the tentacles are in a new state. This could be potentially very bad and create confusion based on miss-matching data.

It would be nice if pull requests for specific branches got updated by octopusci with info about those brranches builds and failures.

The scenario is the following. Lets say you have three stages setup test_a, test_b, and test_c. The current state of your octopusci install is that it is in the process of running two jobs one on test_a and one on test_b. You decide to use octopusci-tentacles to stop octopusci-tentacles so that you can update octopusci. When you run octopusci-tentacles stop it politely sends a msg to the job managers requesting that the job workers quit when the currently running jobs are finished.

The jobs are still running because they are long running jobs (45 min or so) and you have completed the upgrade and you are ready to start octopusci up again so you run octopusci-tentacles start. However, when you do this it currently resets the stage locker making all of the stages available to the jobs. This is a problem though because you currently still have two jobs running. Therefore, you can easily get in a situation where you have multiple jobs running on one stage which should never happen.

One solution to this would be to make octopusci-tentacles start no longer reset the stage locker. I remember back in the day with the first version of octopusci that I made them reset for some reason. However, that case may no longer be necessary.

So, I think the proper solution is to disable it from auto resetting the stage locker on start and provide a octopusci-reset-stage-locker command that can be called to reset the stage locker if that issues ever arrises.

There is a problem with the Git support where if local changes are made to one of the checked out repos in the workspace of Octopusci that it will fail to checkout the proper branch but still fall through and continue the build process with the incorrect version.

The start method should be trivial which is what it already does. The stop command is more complicated as when start happens it needs to store the pids inside of redis of the running workers. When stop is called it should read those pids from redis and send QUIT (kill) signals to those processes to kill them. To protect from accidentally having workers die and other apps steal their pids and us accidentally killing them we should check the process name for 'resque' to make sure it is good.

It should show you all the stages and if they are currently working on a job or not. Maybe show the job id if it is working on a job and not if its not.

We need this so we can get feedback from users about the blog posts that we make.

The idea is basically that I want to simplify the install somehow. I want to make it so that the install is as simple as possible. One, idea for being able to do that is to include thin/webrick or something similar as a dependency and then somehow set that up under the installed user account for Octopusci that way you don't have to worry about webserver configs, etc as a consumer. You just install it and then hit the URL and it works.

This view should probably reside at the following URI:

http://octopusci.yourcompany.com/defcon

This view should show you a listing of all of the repositories that Octopusci is managing and the status of the most recent build of their master branch.

It should also have a way of notifying the viewers if any of the statuses are bad. Maybe by changing the background color to red or something.

This might be a "someday" type of feature, but it would be cool if there is spare capacity to run my specs and cukes at the same time on two machines. Since the specs take like 10 min to run and cukes take like 45, I could get a response 10 minutes sooner if they ran in parallel. If the specs fail, it should be smart and tell the cukes to stop running?

This is needed because ansi2html will now work inside of html e-mails as they don't support style blocks. Instead they only support inline styles so we need a gem/form similar to ansi2html but one that simply outputs spans with inline styles setting the colors instead of giving each span a class with a color name which is defined somewhere else. I realize that this is moving the coloring to the be the standard colors and that makes it less configurable but that is something I am ok with as long as they work in the html emails.

Writing/debugging jobs needs to be much much easier. The job writers shouldn't have to worry about running a command a certain way to get the output properly. They also shouldn't have to worry about their job throwing an exception and crashing.

If a job throws an exception and crashes we need to update the job in the database with a different state that identifies that the job didn't completed because of an exception and log that exception and the associated traceback.

The reason this is valuable is in the scenario where you have a lot of output and have had to scroll down a long ways, it is annoying to have to scroll all the way back up to the top to collapse the output.