Skip to content

Move the deployment to the after_success phase on Travis #829

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
May 11, 2016

Conversation

brasmusson
Copy link
Contributor

The benefits are that only if the test for all modules passes are the modules deployed, and that the tests for all modules are also executed on Java8.

@brasmusson brasmusson force-pushed the travis-deploy-after-success branch from 0e8670a to 887779a Compare January 18, 2015 15:01
@SierraGolf
Copy link
Contributor

I know it is experimental, but are you aware of the deployAtEnd flag?

@brasmusson
Copy link
Contributor Author

I did not know about the deplyAtEnd flag. It is an option for the Java7 job, where all modules built are also deployed, but not for the Java8 job, where all modules are built and tested, but only the java8 module is deployed.

script: mvn -q install -P examples
jdk:
- openjdk7
matrix:
include:
- jdk: oraclejdk7
script: mvn -q deploy --settings .travis-settings.xml -Dno.gem.deploy=true
# skip the default install (mvn install -DskipTests=true) to speed up the build
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't that inherited from above? btw. on java8 you just wrote the comment without the actual skipping

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, it is inherited from above, because that oraclejdk8 job did execute true for install (even though just the comment was specified on the job itself).

@SierraGolf
Copy link
Contributor

Yeah, you are right about the java 8 job. Btw. maybe it is better to use one job (manually calling the jdk_switcher) instead of a matrix in order to make sure that all artifacts are deployed only when their dependent artifacts have been deployed.

as you said the java 8 job only deploys that one artifact, but it can not be sure that its dependent artifacts have been deployed.

@brasmusson
Copy link
Contributor Author

Actually, the big improvement I saw when starting out on this PR, was to not only build (which the install step did), but also run the test for all the modules on Java8. If using the after_success there for that, it could also be used in the oraclejdk7 job, and ...

I don't know how important it is, how much effort to spend, to make sure the modules only deployed after tests for all modules have passed, and all dependent artefacts have been deployed. Deploying all modules from the Java8 job, would be one solution to that.

@SierraGolf
Copy link
Contributor

I don't see much effort there, you basically just put a few calls in one script, but I would agree that it might be overkill to do these changes for yet theoretical problems. However I think deploying all artifacts from java 8 might cause real problems. I think this would make all modules only work on java 8, or am I wrong? I think you would get the Unsupported major.minor version 52.0 error.

@brasmusson
Copy link
Contributor Author

This declaration in the pom should make the modules (except the java8 module, of course) to work on Java6 and later, so it should be possible to deploy all modules from the Java8 job, if it is worth while to switch it from the Java7 job.

@SierraGolf
Copy link
Contributor

ah, ok.

@brasmusson brasmusson force-pushed the travis-deploy-after-success branch from 887779a to aa5bf63 Compare January 20, 2015 18:39
@dkowis dkowis merged commit 21b14b4 into cucumber:master May 11, 2016
@lock
Copy link

lock bot commented Oct 25, 2018

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.

@lock lock bot locked as resolved and limited conversation to collaborators Oct 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants