A contributor added .travis.yml about 3 years ago, before I had ever used it. But I've been around the block enough to know that getting stuff for free is temporary. (And to be fair, I did like Travis CI free service a lot better than I thought I would.)
So when I needed to enhance the continuous build back in January, I did it with a PORTABLE SHELL SCRIPT, NOT with yaml. Both Travis CI and sr.ht provide Linux VMs, which are easily operated with a shell script.
The script called "Toil" does the following:
1. Configures which steps are run in which build tasks (both Travis CI and sr.ht can run multiple tasks in parallel for each commit)
2. Logs each step, times it, summarizes failure/success
3. Archives/compresses the logs
3. Publishes the result to my own domain, which is A LOT FASTER than the Travis CI dashboard. (sr.ht is very fast too; it has a great web design.)
This ended up working great, so I have multiple CI services running the same jobs, and publishing to the same place: http://travis-ci.oilshell.org/
(I plan to create srht.oilshell.org for security reasons; it isn't ideal that both services have a key to publish to the same domain.)
----
I think this is the future of the Oil project: shell scripts to enable portability across clouds. If you want to be fancy, it's a distributed or decentralized shell.
This is natural because shell already coordinates processes on a single machine.
- A distributed shell coordinates processes across multiple machines (under the same domain of trust)
- A decentralized one does so across domains of trust (across clouds)
My "toil" script is a lot more basic, but an analogous idea. I would like to create a slightly tighter but improved abstraction that runs on multiple cloud services. Notes on gg here:
If anyone wants to help, get in touch! If you are pissed off about Travis then you might want this :) I think these kinds of multi-cloud setups are inevitable given the incentives and resources of each party, and they already exist (probably in a pretty ugly/fragile form).
http://www.oilshell.org/blog/2020/11/fixes-and-updates.html#...
A contributor added .travis.yml about 3 years ago, before I had ever used it. But I've been around the block enough to know that getting stuff for free is temporary. (And to be fair, I did like Travis CI free service a lot better than I thought I would.)
So when I needed to enhance the continuous build back in January, I did it with a PORTABLE SHELL SCRIPT, NOT with yaml. Both Travis CI and sr.ht provide Linux VMs, which are easily operated with a shell script.
The script called "Toil" does the following:
1. Configures which steps are run in which build tasks (both Travis CI and sr.ht can run multiple tasks in parallel for each commit)
2. Logs each step, times it, summarizes failure/success
3. Archives/compresses the logs
3. Publishes the result to my own domain, which is A LOT FASTER than the Travis CI dashboard. (sr.ht is very fast too; it has a great web design.)
This ended up working great, so I have multiple CI services running the same jobs, and publishing to the same place: http://travis-ci.oilshell.org/
(I plan to create srht.oilshell.org for security reasons; it isn't ideal that both services have a key to publish to the same domain.)
----
I think this is the future of the Oil project: shell scripts to enable portability across clouds. If you want to be fancy, it's a distributed or decentralized shell.
This is natural because shell already coordinates processes on a single machine.
- A distributed shell coordinates processes across multiple machines (under the same domain of trust)
- A decentralized one does so across domains of trust (across clouds)
-----
Really great work in this direction is gg:
https://buttondown.email/nelhage/archive/papers-i-love-gg/ comments: https://lobste.rs/s/virbxa/papers_i_love_gg
which is a tool that runs distributed programs across multiple FaaS providers like Amazon Lambda, Google Cloud Functions, etc.
https://github.com/StanfordSNR/gg
My "toil" script is a lot more basic, but an analogous idea. I would like to create a slightly tighter but improved abstraction that runs on multiple cloud services. Notes on gg here:
https://github.com/oilshell/oil/wiki/Distributed-Shell
If anyone wants to help, get in touch! If you are pissed off about Travis then you might want this :) I think these kinds of multi-cloud setups are inevitable given the incentives and resources of each party, and they already exist (probably in a pretty ugly/fragile form).