[FOLIO-874] Update folio-testing-platform Created: 03/Oct/17 Updated: 12/Nov/18 Resolved: 06/Oct/17 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | Continuous Integration |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P2 |
| Reporter: | Wayne Schneider | Assignee: | Wayne Schneider |
| Resolution: | Done | Votes: | 0 |
| Labels: | ci, sprint23 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 6 hours, 45 minutes | ||
| Original estimate: | Not Specified | ||
| Sprint: |
| Description |
|
There may be a use for this project as a reference yarn platform to make it easier for stripes developers to catch cross-repo dependency mixups. |
| Comments |
| Comment by Matthew Jones [ 04/Oct/17 ] |
|
I agree that maintaining a folio-testing-platform which CI uses, rather than one generated on the fly, will make it easier for developers to catch such errors. It will also help developers troubleshoot existing failures reported by CI more quickly. There are a few other things we might consider, so I'm going to include my notes about the recent build failures in general. I'm hoping to identify areas for discussion and improvement, not point blame in any way. These can be move to another ticket if more appropriate.
Unintentional breaking changes
Locally linking packages in a development environment
Use of interim snapshot or hash between releases
Webpack builds not reporting failures to CI
Difficulty in reproducing testing build
|
| Comment by Wayne Schneider [ 04/Oct/17 ] |
|
https://github.com/folio-org/folio-testing-platform has been updated to be current. I committed a yarn.lock to the repo, as well. My thought is to commit a new yarn.lock every time one is generated by the regularly scheduled stripes-testing CI job. Does this make sense, or is it too aggressive? It will certainly lead to lots of commits, which is a lot of noise. |
| Comment by Wayne Schneider [ 04/Oct/17 ] |
|
A couple of comments on Matt's useful summary:
|
| Comment by Matthew Jones [ 04/Oct/17 ] |
|
Re: yarn.lock, I'm not too concerned about the added noise. However, it seems updating it every time is not much different than excluding it from the repo. Well, okay I do see having it there would help a developer to recreate locally exactly what is happening in CI at any given moment. This will be helpful in troubleshooting. The next CI build would then omit yarn.lock to get the latest available changes anyway, correct? |
| Comment by Matthew Jones [ 04/Oct/17 ] |
|
I have not used yalc. The description sounds like it might be helpful though. Some other thoughts that come to mind for improvements:
|
| Comment by Wayne Schneider [ 04/Oct/17 ] |
|
I updated folio-ansible to use folio-testing-platform, but it caused unexpected side effects on folio-testing.aws.indexdata.com, so I rolled back part of the change. |
| Comment by Wayne Schneider [ 04/Oct/17 ] |
|
OK, John Malconian found the problem, so folio-ansible (and folio-testing) are now being build from the folio-testing-platform repo. |
| Comment by Wayne Schneider [ 04/Oct/17 ] |
|
John Malconian – I think if we are to update the yarn.lock file through CI, it will have to be part of the Ansible plays in the folio-infrastructure project. |
| Comment by Wayne Schneider [ 06/Oct/17 ] |
|
The folio-testing-platform is working fine in CI. I'll open another issue about updating the yarn.lock file from a CI build. |