Test OracleDB abstractions in a continuous integration environment

[photodude]

Apparently, someone has a workaround for testing Oracle DB on travis ci as well https://github.com/cbandy/travis-oracle

an Oracle account is required and the Oracle username and password has to be in the build environment variables either as hidden repository settings or encrypted variables

[Ocramius]

Talked at PHPBenelux with @continuousphp: they can provide CI for OracleDB too (can be integrated here)

[DeepDiver1975]

I've been chatting with @deeky666 these days - owncloud is willing to support the doctrine project here as well.

[Ocramius]

I'm fine with any approach, but it needs to be directly integrated with the PR feedback and commit CI status

[deeky666]

@DeepDiver1975 did you have time to investigate integration possibilities already? @Ocramius can you tell something about the approach you guys discussed?

[Ocramius]

@deeky666 @continuousphp is pretty much similar to travis-ci, but custom containers are provided. The deal is simple: building with continuousphp provides some visibility for them, but they also have to provide a patch with the oracledb testing (multiple versions).

[DeepDiver1975]

What I can offer: run PR testing on jenkins - similar to what is done already today: https://jenkins.owncloud.org/view/doctrine/

As of today we are only testing against oracle xe 11g

[deeky666]

@Ocramius I tried out @continuousphp. See here

Seems to be pretty straight forward. Should we add such a setup for now to at least be able to test one Oracle environment? I could PR that damn thing.

[Ocramius]

@DeepDiver1975 your offer is very kind, but let's try the @continuousphp setup first, mostly because that reduces the amount of customization and internal knowledge (CI PaaS is preferrable). @deeky666 I'd say that we can proceed there, and then fallback to custom jenkins ( @DeepDiver1975's ) if that fails.

[deeky666]

PR created: #2630

[Ocramius]

This is an improvement, therefore moved to 2.6

[deeky666]

@Ocramius while I agree that we don't backport improvements, I doubt this policy is useful here. The change is not really related to production code and helps identifying Oracle related bugs in the code. Why shouldn't we want to know if our backports also succeed on Oracle in 2.5?

[Ocramius]

I doubt this policy is useful here.

It may not be useful, but we're really just complicating our setup here, and doing so for the gazillion versions supported in 2.5.* is not gonna make our lives easier. Keeping this on master is a decent tradeoff, IMO

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.