Skip to content
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

Closed
garethbowen opened this issue May 14, 2017 · 9 comments
Closed

Investigate and use travis build stages #3476

garethbowen opened this issue May 14, 2017 · 9 comments
Labels
Priority: 3 - Low Can be bumped from the release Type: Technical issue Improve something that users won't notice
Projects

Comments

@garethbowen
Copy link
Member

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:

  1. Run sanity checks (jshint)
  2. Build the app and pass on as an artefact (is this even possible?)
  3. Run unit tests with one instance per for Chrome and one for Firefox
  4. Run integration tests with one instance for CouchDB1, CouchDB2, Chrome, and Firefox. (Maybe also Chrome at mobile resolution but this will likely require a different test suite.)
  5. Publish to the market
@garethbowen garethbowen added 1 - Scheduled Type: Technical issue Improve something that users won't notice and removed 1 - Scheduled labels May 14, 2017
@alxndrsn
Copy link
Contributor

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

@garethbowen
Copy link
Member Author

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.

@medic-bot
Copy link

Hi @rmhowe,

This ticket has not been touched in 90 days. Is it still relevant?

(See triaging old issues for more detail)

@medic-bot medic-bot added the Status: Blocked waiting for triage Blocked waiting for prioritisation label Jan 31, 2018
@rmhowe
Copy link
Contributor

rmhowe commented Jan 31, 2018

@garethbowen is this something that will be looked at in the near future? Perhaps as a devops task for 3.0?

@garethbowen
Copy link
Member Author

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.

@alxndrsn
Copy link
Contributor

alxndrsn commented Feb 1, 2018

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:

  1. separate staging server/build db specifically for travis, with builds identified by travis build number. This would mean that at the end of a successful build, the built artifact has to be uploaded a second time.
  2. store these builds in the same db as the rest of the builds, but with doc IDs such as travis-12345. This might cause some bloat in changes feed and view generation on the staging server (unlikely an issue in the medium term), but would mean we can deploy artifacts for failed builds from horti without needing to support multiple staging dbs.

@garethbowen
Copy link
Member Author

I prefer option 1 because there's no risk of a bad build getting installed in production.

@rmhowe
Copy link
Contributor

rmhowe commented Feb 5, 2018

So is this triaged with low priority?

@garethbowen
Copy link
Member Author

Sounds good to me.

@rmhowe rmhowe added Status: 1 - Triaged Priority: 3 - Low Can be bumped from the release and removed Status: Blocked waiting for triage Blocked waiting for prioritisation labels Feb 7, 2018
@rmhowe rmhowe removed their assignment Feb 7, 2018
@garethbowen garethbowen self-assigned this Dec 5, 2018
garethbowen added a commit that referenced this issue Dec 6, 2018
garethbowen added a commit that referenced this issue Dec 10, 2018
@garethbowen garethbowen added this to To do in 3.4.0 via automation Dec 20, 2018
@garethbowen garethbowen moved this from To do to In progress in 3.4.0 Dec 20, 2018
SCdF pushed a commit that referenced this issue Dec 21, 2018
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
@garethbowen garethbowen removed their assignment Jan 7, 2019
3.4.0 automation moved this from In progress to Done Jan 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: 3 - Low Can be bumped from the release Type: Technical issue Improve something that users won't notice
Projects
No open projects
3.4.0
  
Done
Development

No branches or pull requests

4 participants