| # | Change | User | Description | Committed | |
|---|---|---|---|---|---|
| #5 | 15622 | tjuricek |
Move source code to 'source/' subdirectory of branch. build/ will remain where it is. |
||
| #4 | 15618 | tjuricek |
By default, writing spec results to spec-output, docs to doc-output. The archiving in a 'build' branch will be handled by the CD pipeline. |
||
| #3 | 15513 | tjuricek |
Add a product ID header for debugging purposes. This will generally display INVALID unless the version file has been created during the build. |
||
| #2 | 14794 | tjuricek |
Omnibus installation framework. Right now, this mostly just packages up most of the software for use within an embedded ruby distribution. Not everything is working because there are decisions to make I'm not entirely sure about. Things, like, "do we embed postgres", or "do I embed unicorn and generate a stupid init.d script". |
||
| #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/.p4ignore | |||||
| #11 | 13549 | tjuricek | Remove p4ws-versions.sh which had been incorrectly checked in. | ||
| #10 | 13544 | tjuricek |
Revise package and gem versioning. Packages will use [gem]-[changelist] as their versions. Gems will use a standard Ruby MAJOR.MINOR.REVISION format. P4WEBAPI-64 |
||
| #9 | 13534 | tjuricek | Remove automatically generated license files and unused run.sh files. | ||
| #8 | 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. |
||
| #7 | 13517 | tjuricek |
Revised Salt hierarchy to allow for CD clustering. Now, there are two main salt environments: 'build' and 'eval'. The 'eval' environment can be configured for testing or development by setting the Grain 'dev_pillar: True' or 'test_pillar: True'. The test modes may need a bit more effort to figure out exactly where I'll put the .deb files. The dev box passes p4_web_api tests. |
||
| #6 | 13512 | tjuricek |
Add 'test-ubuntu12' environment that sets up projects based on "production" packages. Packages are installed from source files that should have been created by the last 'build-ubuntu12' environment. Since the package building process "dirties" up the environment it's better to use a clean system to test package installation. |
||
| #5 | 13499 | tjuricek |
Simple p4_web_api omnibus installer. Successfully built using a test-kitchen VM for debian ubuntu 14.04. |
||
| #4 | 13491 | tjuricek |
Minimal .deb installer package for the p4_web_api The goal of this package is to provide a way of distributing the web application source via deb instead of something like the workshop or git. There will definitely be some changes as a complete deployment workflow is defined. This includes some vagrant machines for building the installer packages ('ubuntu') and testing out the environment ('salt'). |
||
| #3 | 13435 | tjuricek |
Added framework for QtTest to the p4_phoenix_services qt client (and fixing stupid compile errors). Also, ignoring .DS_Store. |
||
| #2 | 13414 | tjuricek | Add spec-output to commonly ignored paths | ||
| #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. |
||