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
Investigate and use travis build stages #3476
Comments
Without modifying the build to upload a binary bundle somewhere, we'll have to re-run the packaging steps for each part of each stage: https://docs.travis-ci.com/user/build-stages#Data-persistence-between-stages-and-jobs |
Right. Ideally we'd jshint, build, and upload somewhere, then run tests, then publish. In the short term we could leave it as is, or go with a slightly slower but cleaner strategy of building for each step. |
Hi @rmhowe, This ticket has not been touched in 90 days. Is it still relevant? (See triaging old issues for more detail) |
@garethbowen is this something that will be looked at in the near future? Perhaps as a devops task for 3.0? |
Yeah I think this is still relevant and Horti may make it easier. What we have is a Horti repository for all the successful builds which can then be installed. We need some way to push to a repository but mark it as not ready for deployment but make it available for Travis build stages to install it. |
A couple of suggestions for this:
|
I prefer option 1 because there's no risk of a bad build getting installed in production. |
So is this triaged with low priority? |
Sounds good to me. |
Instead of rebuilding the app for each test run, use build stages to: 1. build, lint, unit test, integration test, and publishes to a temporary horti market db 2. in parallel: e2e tests in node 8, e2e tests in node 10, production tests 3. move the published package to the main horti db I removed a test for the audit db as we no longer use the audit db and it was broken with this change. #3476
We currently have a complicated script which we copied from some guy on the internet which tries to determine if all travis builds in one run have finished successfully, and then pushes the app to the market. This is really useful so we can test against different versions of node or different version of CouchDB.
This has been made obsolete by a new feature in travis called Build Stages.
Investigate replacing the custom script with the generic build stages configuration.
It might be that we can split out more stages, for example, our ideal build might be:
The text was updated successfully, but these errors were encountered: