require 'helix_versioning_engine/change_service' require 'helix_versioning_engine/submit_service' module HelixVersioningEngine # Add methods related to changelist resources. class App < Sinatra::Base # Convenience method to list changelist metadata with some common filtering # options. # # parameters: # - `max` = number # - `status` = pending|submitted|shelved # - `user` = perforce login # - `files` = pattern get '/helix_versioning_engine/:api/changes' do |_| require_p4 max = params['max'] if params.key?('max') status = params['status'] if params.key?('status') user = params['user'] if params.key?('user') files = params['files'] if params.key?('files') p4 = env['p4'] args = ['changes'] args.push('-m', max) if max args.push('-s', status) if status args.push('-u', user) if user args.push(files) if files results = p4.run(*args) results.to_json end # Create a new changelist with edits to multiple files. post '/helix_versioning_engine/:api/changes' do |_| require_p4_with_temp_client description = params['Description'] || 'Edited files' files = params['Files'] depot_paths = files.map { |f| f['DepotFile'] } p4 = env['p4'] client_root = env['p4_root'] client_name = p4.client change_service = ChangeService.new(p4: p4, client_root: client_root, client_name: client_name) files = files.map{ |f| HelixVersioningEngine::ChangeService::File.from_json(f) } change_service.submit(files: files, description: description) '' end # Uses describe to produce the list of opened files regardless of client. # # There is a little bit of an open question regarding performance. The # p4ruby usage here does *not* generate diffs of changes, which the base # command line seems to want to do. If the output accumulates a lot of RAM # for large diffs, we could be in trouble. get '/helix_versioning_engine/:api/changes/:change' do |_, change| require_p4 results = env['p4'].run_describe('-S', change) results.to_json end # This will perform a submit -e for the indicated change. # # If the change happens to reference a stream client, this will have to # generate a different kind of temporary client. We defer the client # creation logic to the service layer. post '/helix_versioning_engine/:api/changes/:change' do |_, change| require_p4 submit_service = SubmitService.new(p4: env['p4'], env: env) submit_service.submit_shelf(change) '' end end end
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#1 | 15741 | ptomiak | Branch HWS for my use. | ||
//guest/perforce_software/helix-web-services/main/source/helix_web_services/lib/helix_versioning_engine/app/changes.rb | |||||
#1 | 15622 | tjuricek |
Move source code to 'source/' subdirectory of branch. build/ will remain where it is. |
||
//guest/perforce_software/helix-web-services/main/helix_web_services/lib/helix_versioning_engine/app/changes.rb | |||||
#4 | 15240 | tjuricek |
Set api level via request path on all Helix Versioning Engine methods. This will allow migration of applications to different P4D versions. Our internal methods (like project API) should attempt to handle backward compatibility similarly. P4WEBAPI-118 |
||
#3 | 15132 | tjuricek | Provde a basic submit -e mechanism on classic perforce workspaces. | ||
#2 | 15110 | tjuricek | Revise changes methods for new p4 connection handling, add server specs, remove model references in client, and update asciidoc documentation. | ||
#1 | 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. |
||
//guest/perforce_software/helix-web-services/main/helix_web_services/lib/perforce/app/changes.rb | |||||
#2 | 13839 | tjuricek |
Conversion of the p4_project_service microservice to new monolithic system. This may not have an HTTP front end in the monolithic system. Project services are really just about how the core object model is structured. It's likely that each application will add their own wrinkles and extensions to the system, so it's unlikely we'll need a generic "project model". Exactly how extensions are registered and used is still a bit TBD at the moment. Previously they were to be registered webhooks, that model may change. Does not include tests yet. |
||
#1 | 13799 | tjuricek |
Start with branch specs hosting in a new monolithic 'helix web services' project. Converting from a microservice to a monolithic architecture due to resource constraints at getting a deployable system running. Additionally, since it's not expected that people will upgrade often, the major benefit of microservices - being able to add services individually without affecting others - is not really a major benefit. The Ruby SDK will be consolidated into a single 'helix web services client' project. It may end up being distributed via Rubygems. This only runs branch specs at the moment. I want to get a CD pipeline setup for the monolithic server before revising more methods. |
||
//guest/perforce_software/helix-web-services/main/p4_web_api/p4_web_api/lib/p4_web_api/app/changes.rb | |||||
#1 | 13412 | tjuricek |
Initial version of the web-services mainline. This is a collection of several projects, that will likely often get released together, though many of them may not always be relevant. See the README for more information. |