Over time that has grown into over 1000 lines of shell, e.g.
https://github.com/oilshell/oil/blob/master/devtools/release...
And this is why I'm writing a shell -- because it's good for automating things that you are otherwise too lazy to automate!
I find that "semi-automation" is a good middle ground. This is where shell is better than "real" languages. You don't have to commit to writing a polished program -- you just incrementally improve things and it makes problems go away.
The time you put in is saved immediately, as opposed to other languages, where you might spent 30 minutes writing something that will save you 2 minutes in the next year, which isn't necessarily worth it.
If you keep a text file with a bunch of terminal commands, then you might as well chmod +x it and put #!/bin/sh on the front. That's what a shell script is!
----
Here is the output of the release process, which has tarballs, change logs, documentation, test results, benchmarks, etc.
https://www.oilshell.org/release/0.7.pre5/
It's way to much to do by hand.
I’d love to take a look at your list
- Finalize source
- Legal check `LICENSE-dist.txt`
- Update `CHANGELOG.md`
- Bump version in `Makefile` and `Core.json`
- Commit "Bump version".
- Build (three OS's can be done in parallel)
- `m clean`
- `git pull`
- Make sure you have the latest `Fundamental.zip` package in source root.
- `m dist`
- Manually test installer and fragile features (audio drivers, patch loading) for ~10 minutes.
- `m notarize` (on Mac)
- `m upload`
- `git tag vX.Y.Z`
- `git push --tags`
- Release
- Update version title and URLs in `Rack.pug`
- `m upload`
- At this point, normal users have access to new version.
- Update server version in `config.coffee`
- `m restart`
- At this point, normal users will swarm to download new version. Keep an eye on server bandwidth.
- Publicize
- Twitter https://twitter.com/home
- Facebook https://www.facebook.com/vcvrack/
- Share on group
- Forum https://community.vcvrack.com/c/announcementsLaunching a VM via shell script is trivial. And you can install OpenSSH on Windows 10: https://github.com/PowerShell/Win32-OpenSSH
true. And that is a very sad state of affairs. I use the travis osx hosts for that, but it's not ideal. There's no interface, but at least you can check that the code compiles, runs, and passes automated tests. That's already huge!
For linux and windows hosts, it seems to me that it is a solved problem, as pointed elsewhere.
It's not, as long as you run it on genuine Apple hardware. We use a bunch of macOS VMs that are 100% legal.
The problem with macOS VMs is that there are a lot of compatibility issues, and in my experience it's a lot of effort to set up macOS VMs. If you have the space and the money, real machines are a lot easier to deal with.
Our main build machine is an actual Mac, because it's just so much easier to keep it running.
VMs are nice if you need a lot of different setups (eg. one app we distribute has components that need to be built on different versions of macOS, and VMs are nice for that).
In a larger team you’d have a small agent on each of your N (likely >> 3) machines, CI pushes to the agent for build/release/automated tests.
Then if those pass on a given system, it fires off a message to start manual QA validation for performance and other “intangibles”.
Then those steps must be removed. I thought the mantra "deploy is ONE step" was a more or less universally acknowledged truth.
So it is clearly possible to do -- and there are all sorts of tools which figure out what SPDX license entries apply for every dependency (or vendored dependency) of a given project.
For the latter though, Fossology, Scancode etc. can help.
Manual releasing allows me to iteratively improve the process and spot possible issues, whereas any automation would reduce build reliability.
I guess this depends on what your release process is; for example, most npm libraries benefit from CI that runs the build script and runs `npm version $TAG && npm publish`. There's not much that could be improved here, especially if the build script is just an alias for running `webpack`.
That's a hefty deploy protocol, though, and automating cross-platform builds may be more trouble than it's worth if you're releasing rarely.
It's pretty neat you follow a deploy checklist.
input("Build X")
input("Build Y")
input("Zip X & Y")
input("Upload release")
If you implement it as functions:
def buildX():
input("Build X")
def buildY():
input("Build Y")
def ZipUp():
input("Zip X & Y")
def Upload():
input("Upload release")
if __name__ == '__main__':
buildX()
buildY()
ZipUp()
Upload()
I wanted to give you an example, but it all seems so easy, I'm not sure where you're getting stuck.
If not fully automated, many CI platforms allow you to pause the pipeline by requiring manual confirmation from an authorized user. I know Jenkins and CircleCI support this off the top of my head. You could have the CI perform any relevant searches or diffs, then display that to the user to get manual confirmation. It’s still not “perfect”, but it does allow you to reliably get someone to look at the data and say “yes” or “no.”