I'd like to suggest that if you're trying to provide a service to apps on Cloud Foundry with UAA, you might want to bosh-deploy UAA. Deploying it to Cloud Foundry is possible, but (and folks from the

We haven't done anything beyond proposing the interface and implementing the option to respect permissions. Since the time of this proposal, BPM has implemented a feature that should allow us to run B

Another point: most (certainly not all, but most) CVEs are stemcell, buildpack, or rootfs bumps that can be consumed safely/have minimal integration concerns. Even those that are in more substantive r

I don't agree with the claim that we didn't introduce major breaking changes in the past - we did. Routinely. `cf-release` was sem-ver only insofar as every version was a major version. Changes just a

Hello! We're the CF Platform Logging team. We maintain `syslog-release` and have been working to improve and regularize platform logging behavior. This is a proposal intended to establish reasonable e

Thanks for the nudge! Our backlog should absolutely be public, and now it is. The platform logging improvements team is new, and we've got some startup/setup pains. Sorry for the inconvenience! Regard

Release Integration has an open CI instance and repo, too. You can see the job for branch-freshness (and code here), and the pipeline for running tests against PRs (and code here). Also happy to help

Yes, you're understanding me right, David. RelInt's automation around this focused on branch freshness. If a branch wasn't updated in a couple of weeks (or a month, I think), a CI job would start fail

I support this idea. The CF Release Integration team encourages other teams to use branches on their repos when PRs are appropriate, and in cases of closer collaborative relationships, commit directly

Yeah, but do they do rolling restart or vertical scaling? I'm unaware of any. A blue-green deploy to boost RAM is definitely an option, but it seems like over kill, especially if you're already using

The cf CLI also respects a .cfignore file in the top level of your repo, if there's stuff you'd like to explicitly exclude from push.

Are your Gemfile and Gemfile.lock files literally named Gemfile and Gemfile.lock, and both checked present at the top level of the directory you're pushing from, on the machine you're pushing from? Th

Agreed: the simple/hierarchical model of permissions is less flexible and composable. Having each roll have the permissions of the one "under" it plus a new layer limits the business rules this can be

Tim, Alternatively, if you don't want to have a separate system domain for whatever reason, I recommend you create a "system" org and space with the admin account and use create-route to reserve any r

If the app doesn't have a bound route, it's not health checked on DEAs. If it fails without actually exiting, the system won't notice. (On Diego, the health check has to be explicitly disabled.)

I suspect it might be forward VS backwards slashes in the file path that's tripping things up, there. Does using / in the Linux file path help?

My pleasure. As for question two, you can't have more than one app with the same name in a space. You could put a second app with the same name in a different space, but I would ask why you feel the d

On point 1, you need to quote your start command. Otherwise, the space is a problem. Also, the word memory should be replaced with the -m flag.