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()
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.
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”.
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.
Launching a VM via shell script is trivial. And you can install OpenSSH on Windows 10: https://github.com/PowerShell/Win32-OpenSSH
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).
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.”