oduwsdl
Consider moving to a matrix build using GitHub Workflow and/or TravisCI
In #624, @ibnesayeed suggested we moved to using GitHub Workflow. We currently use TravisCI but no build matrix. I have used a build matrix with WAIL (for example) and @ibnesayeed has with access-parser.
-
Q: What (dis-)advantages does GitHub Workflow use compared to TravisCI?
-
Q: Are there any barriers in using both? Are there any reasons not to do so?
-
[ ] Move to using a matrix build in TravisCI (current master) or abandon it in favor of GH Workflows CI.
-
[x] Consider pros and cons of keeping both services or opting for one over the other.
-
[x] Add GitHub Workflow for matrix testing.
-
[x] Incorporate Docker image building using GitHub Workflow
-
[ ] Publish an alternate Docker image on GitHub Packages.
-
[x] Consider using GH Workflows for publishing to PyPi in the future.
In the accesslog-parser repo we use both TravisCI and GH Workflow, but planning on retiring the former which was put in place before I included the latter.
Potential Advantages of Using Both Together
- The same code is tested in multiple places with different infrastructure backbone, so platform-specific failures might surface up, though containerized testing environments mask some of these benefits out
- The code is distributes in more places, potentially, gaining more visibility
- Identifying a failure as transient or systemic is easier as the latter will more likely fail in both the places
Potential Disadvantages of Using Both Together
- CI/CD pipeline is stalled as per the slowest channel of the two platforms (i.e., if GH performs tests in 30 seconds and TravisCI takes 5 minutes to pull the code and run tests due to network slowdown or overloaded queue then the next step in the pipeline has to wait for more than 5 minutes)
- Probability of transient failures increase with the increase of number or places where tests are performed, requiring manual interventions more often
- Inter-service access using access token increases the attack surface of credential leakage, especially when third-party services ask for more permissions than they need to function properly (or access permissions are not fine-grained enough)
@ibnesayeed Can you comment on how the two offerings (TravisCI and GH workflow) compare in the context for how we would anticipate to further use the services?
Perhaps we can add GH Workflow for testing (and in the future for other tasks like publishing to PyPi) while keeping TravisCI in place. After a while if we feel that GH's in-house CI is serving the purpose well and the external service is an unnecessary overhead then we can retire that, otherwise keep that running too. Additionally, we may also incorporate Docker image building and publishing here in GH itself.
@ibnesayeed 👍 I have updated the original post on this GH issue to reflect these tasks.
I have created and published an independent GitHub Action about IPFS setup in the marketplace that we can leverage in this repo.
@ibnesayeed Do you want to take the lead in integrating your Action into the Workflow?
Do you want to take the lead in integrating your Action into the Workflow?
Sure!
I have implemented it in #648, but Windows is still a pain that needs to be resolved later.
Ticked box above for #648. Let's still figure out the Travis config before closing this issue.
I have updated the list of tasks in the original post, broken some in more atomic forms, and checked some as appropriate.
PR #654 implements the last point, but it needs to be tested by releasing a version.
Ok, next release is planned in #644 to also include other fixes. Maybe edit the original post there to also entail these changes, GitHub issues, and PRs.