Gemfile #7

  • //
  • guest/
  • doug_scheirer/
  • helix-web-services/
  • main/
  • source/
  • Gemfile
  • View
  • Commits
  • Open Download .zip Download (410 B)
source 'https://rubygems.org'

gem 'rake'
gem 'rspec'
gem 'bundler'

gem 'helix_web_services_client', :path => 'helix_web_services_client'
gem 'helix_web_services', :path => 'helix_web_services'
gem 'git_fusion_strings', :path => 'git_fusion_strings'

gem 'unicorn'
gem 'railties'

group :development do
  gem 'p4util', '~> 0.4'
  gem 'asciidoctor', '~> 1.5'
  gem 'faker', '~> 1.4'
  gem 'yard', '~> 0.8'
end
# Change User Description Committed
#7 16079 Doug Scheirer Merge from main
#6 16025 Doug Scheirer require bundler?
#5 16024 Doug Scheirer Some cloud spec forking, got the mock_raymond to spin up in cloud testing, split normal vs cloud spec output
#4 16014 Doug Scheirer Merge down from main
#3 15839 Doug Scheirer Adding unicorn to the gemfile or tests don't run
#2 15726 Doug Scheirer merge from main
#1 15688 Doug Scheirer Populate -o //guest/perforce_software/helix-web-services/...
//guest/doug_scheirer/helix-web-services/....
//guest/perforce_software/helix-web-services/main/source/Gemfile
#1 15622 tjuricek Move source code to 'source/' subdirectory of branch.

build/ will remain where it is.
//guest/perforce_software/helix-web-services/main/Gemfile
#23 15077 tjuricek Add new 'model' technique, revised branch spec operations, test Auth::Middleware.

The Ruby client now does *not* strictly type anything, but extends OpenStruct with helper methods to help deal with inconsistent data formats.
See the OpenModel class documentation for more details.

The Auth::Middleware class is also *finally* implemented as well. This does not take into account all possible variations of server behavior (yet), but that will happen in follow-up work.
#22 15032 tjuricek Starting config and doc revisions.
System is now broken while revisions underway.

Configuration of the p4d connection is now done via a single HWSSettings middleware object injected into the Rack env.

The HWSP4Cleanup middleware now cleans up any p4 injected into the Rack env.

The Auth::App class now mostly just contains one method to generate a p4 ticket. /auth/v1/login.

Added yard documentation for the main project.

Yard docs have been reconfigured to dump into build/ directories. This should probably be done with each release. Hm...

The top level rake file contains a task, 'all:doc', to update our documentation. This should probably be run for each checkin. Hm...

Specs are now using Rack::Test on top of a 'live' p4d. I'd suggest you still use the p4util mechanism, which now dumps to a /tmp folder, so we can safely add P4IGNORE rules back into your local .p4config file.

Old 'perforce' application now called 'helix_versioning_engine'.

Removing cache data. Helix Sync may be slow. It may also get axed. We'll see.
#21 14151 tjuricek Add depot tree control and selection to the create projects page.

Styling and error checking is kept to a minimum for the time being. Our goal is just internal workflow and feedback.
#20 13975 tjuricek Reset subproject references in the top level Gemfile.

This allows a single RubyMine session to drive most of the development of the different projects (well, except for the Qt libraries).
#19 13972 tjuricek Removing old microservice implementations.

The system is now mostly a monolith. Eventually there will be a websocket service.
#18 13768 tjuricek Fixing the version of bundler to 1.8.9.

The recent changes to 1.9.x don't seem to work smoothly with RVM - 'rake install' (a task defined by bundler) seems to shell out to the 'gem' command, which doesn't appear to be configured quite right when launched via an RVM wrapper script.
#17 13707 tjuricek Infrastructure for including a "project management" React application.

This attempts to create a fairly simple installer that creates a 'static' folder based on ui/static that gets hosted by the nginx front end. Right now, it's the only app, so the default page is this application. It was called "pws2" during a prototyping phase.

Another prototype, "pws" and the related "project" module, is removed since that was a Sinatra-based approach that will be much more difficult to integrate into anything else.

I'm running into a couple of issues with notifications setup, it's still not 100%, so I'm disabling this for now from the default 'god' configuration. (The service isn't 100% functional yet, anyway.)
#16 13677 tjuricek Fixed issues with Sequel saving and displaying webhooks in notification_services.
#15 13635 tjuricek Exploring modular web applications with Sinatra.

If the app has fairly unique content per page, Sinatra works really well actually. (Mostly because it's a thin layer over Rack.) Sharing anything though, basically means implementing a module or base class and implementing it everywhere.

An added benefit is that these applications could be used in Rails apps as well. I'd probably think hard about this, because Rails tends to be a resource hog.

Here's an example config.ru I used for running against the dev system:

require 'pms'

app = Pms::App.new

Pms::Login.settings.p4_web_api_url = http://172.16.100.20/p4_web_api/v1
ProjectApp.settings.phoenix_services_url = http://172.16.100.20/p4_phoenix_services/v1

app.settings.static = :true
app.settings.public_folder = File.absolute_path('../../ui/pms', __FILE__)

puts "public_folder is #{app.settings.public_folder}"

run app
#14 13525 tjuricek Setup God to manage both the p4 web api and p4 project services processes.

Apparently, there can only be one true god per machine.
#13 13520 tjuricek Created a 'cluster' build procedure that creates an installer on build, and executes the install on a test instance.

The main change is to package all gem dependencies via 'vendor/cache' (using the 'bundle package' command).

Right now, there appears to be an issue with test data initialization, which may need a revised approach.
#12 13500 tjuricek Reorganizing Vagrant definitions.

Each platform should allow developers to launch environments for development, builds, or 'production', so the entire CD process can be evaluated by anyone wiht access to the source tree.

This may eventually bring up a transient vSphere machine up and down, which may be necessary for sandboxing Omnibus related builds.
#11 13499 tjuricek Simple p4_web_api omnibus installer.

Successfully built using a test-kitchen VM for debian ubuntu 14.04.
#10 13481 tjuricek Tests for the p4 web api and p4 project services now pass against a development setup both in and out of the docker cluster.

Note that configuration *has not* been finalized, so conventions to dealing with development vs production need to be organized a bit.
#9 13480 tjuricek Creating several Rake tasks for our "hsm" configuration that are based on a Ruby API config file.

The config file points to machines and services in the system which then takes care of setting up the docker-machine environment and docker-compose configuration.
#8 13470 tjuricek Phoenix notification services, client API, including new phoenix_updater

This is an interim commit containing a first pass implementation of the phoenix_updater. Notably missing parts:

- The Qt API doesn't yet actually interact with the phoenix_updater
- The phoenix_services web service doesn't filter out notifications

I *may* end up creating another web application *just* to filter out notifications, since this may end up taking up a lot of background workers.
#7 13467 tjuricek Add a basic notification_services endpoint that can setup a trigger entry and accept basic POST requests.
#6 13421 tjuricek Skeleton of the p4 phoenix services

It's very likely that real 'business logic' will need to happen, but a lot of that is TBD. This is mostly to get the infrastructure in place before we start adding details, like, 'every new project lives under //phoenix/[project]/...', yada yada yada.
#5 13420 tjuricek Setup the main directory to launch specs in subprojects and a unicorn-based daemon via rake.

See rake -T for details, but this should allow for CI builds to collect output.
#4 13418 tjuricek Added p4_project_services to development config.ru, and reconfigured p4 web api client tests to use the new paths.
#3 13417 tjuricek Added a 'rake work/config.ru' task, that creates a local rack configuration.

This now includes the project services, which is not yet mounted. The p4 web api tests still pass though.
#2 13416 tjuricek Set up the p4_web_api related projects to be loaded by the parent Gemfile to make it a little easier to launch a test p4d with different seed data.

Also fixed a couple of minor issues related to the client api.

You'll notice that the 'rake api_reset api_init' task sets up a p4d for the p4_web_api tests, where the 'rake proj_reset proj_init' tasks set up p4d for project services testing.

An example p4_web_api.ru that can be used for launching just the p4_web_api:

require 'p4_web_api'

# Do *not* let your development environment variables pollute how the p4 web api runs!
ENV.keys.select { |k| k =~ /^P4/ }.each { |k| ENV.delete(k) }

api = P4WebAPI::App.new
puts 'changing paths'
api.settings.token_path = '/Users/tjuricek/dev/p4ws/work/tokens'
api.settings.workspace_folder = '/Users/tjuricek/dev/p4ws/work/workspaces'
api.settings.p4 = {'port' => 'localhost:1666', 'charset' => 'auto'}

run api
#1 13415 tjuricek Add some basic utility methods to the top level.