3 ms·

But how do you tell a spell script to be a multi staged build? You can't just write `set OS=macos` and suddenly your OS changes from debian to macos. The best y

But how do you tell a spell script to be a multi staged build? You can't just write `set OS=macos` and suddenly your OS changes from debian to macos. The best you could do is to ssh into that machine but how do you tell your build system to provision a machine with such parameters? You would essential have to build a new build system just for that. Or you could just use a config file -- whether you call it config.ini, .gitlab-ci.yaml, or build.json should not matter. Furthermore, how would you execute a bash script on Windows? You would have to at least tell it to enable Linux Subsystem and make sure it is a Pro version. I personally don't like to have a whole shell script inside .gitlab-ci.yaml file either -- that's why I have a seperate script called setup.bash/build.bash inside a CI folder and juse write `script: ./ci/build.bash` inside gitlab-ci.yaml. But nobody ever told you, you cannot do that. The gitlab-ci.yml is just a configuration file for the build system to tell it what you want your environment(s) to be. I agree that error reporting for YAML files suck -- but at least they are more consistent and easier to parse then XML files. And they are also way more readable then JSON files -- they have essential features such as long strings, and comments. The only annoying thing with Gitlab CI (and any other CI system) is to make sure it works. It often takes me 10 tries to make sure everything works correctly.

specialist 8y ago
Multi-stage? I dunno. Simplify your workflow? "just write `script: ./ci/build.bash` inside gitlab-ci.yaml" Yup. Then why have the YAML? I said shell script, not bash. The first "CI/CD" (as the kids now call it) I ever did was on Windows. Worked great.
- Matt3o12_ 8y ago
  > Multi-stage? I dunno. Simplify your workflow? How would you simplify testing on multiple systems/oses? Or have one project written be tested for multiple versions of that language (because you need backwards compatibility)? It's nice if your build system is as simple as make build test publish and only need to have it work on a Linux distribution of your choice, but some many projects, that's just not enough. Your .gitlab-ci file is just a file to tell your build system: for debian-python3.{3,4,5,6} execute that, for windows: do that. Btw: debian-python:devel is allowed to fail because it is not stable. It's just nice to have an idea if it might work for further versions.
  - specialist 8y ago
    I can't comment directly, obviously. All I have is my faith (irrational belief) that we can reengineer our workflows to ease our own suffering. I used to create prepress (print manufacturing) software for Mac (old and new) & Windows. Multi platform, multi executables, multi language, multi target builds. It'd pull all the resource bundles (L10N/I18N), recreate the the screen shots, rebuild the PDFs (manuals, marcom). The QA box farm would rerun all the regressions (combo of VirtualPC and VMware boxes) on multiple versions of multiple OSes (eg Japanese Windows) with all the necessary drivers (eg security dongles, which totally sucked). We'd end up with CD images and downloadable zips on our private website for VARs and high end customers. Seemed to work pretty good. I used to do a lot of electronic medical records stuff. My team (of 4 core devs) supported five regional exchanges (the first to market), 80 hospitals plus all their partners, pharma scripts, labs (internal and external), feeds to the govt (eg CDC, SSI). Basically 100s of data feeds of every mutant format and protocol imaginable. At the time, all of the data had to be stored on each customer's servers. Meaning we had to deploy and support in situ. Meaning firewalls, reverse SSH, forklifting files into place, whatever was permitted. We did multiple builds per week. Most deploys were push. Some we had to setup as pulls. We implemented auto updates, but never had the QA/Test resources to achieve the necessary confidence, which was a shame. Seemed to work pretty good. Sure, today's cloud deploys are complicated in other ways. But the more stuff changes, the more it all looks the same. PS- Rereading your comment... Maybe consider changing some of the steps from push to pull. I was super inspired by the architecture of postfix (email server). Trying to mimick it simplified a lot of my own efforts.

specialist 8y ago

Multi-stage? I dunno. Simplify your workflow? "just write `script: ./ci/build.bash` inside gitlab-ci.yaml" Yup. Then why have the YAML? I said shell script, not bash. The first "CI/CD" (as the kids now call it) I ever did was on Windows. Worked great.

Matt3o12_ 8y ago
> Multi-stage? I dunno. Simplify your workflow? How would you simplify testing on multiple systems/oses? Or have one project written be tested for multiple versions of that language (because you need backwards compatibility)? It's nice if your build system is as simple as make build test publish and only need to have it work on a Linux distribution of your choice, but some many projects, that's just not enough. Your .gitlab-ci file is just a file to tell your build system: for debian-python3.{3,4,5,6} execute that, for windows: do that. Btw: debian-python:devel is allowed to fail because it is not stable. It's just nice to have an idea if it might work for further versions.
- specialist 8y ago
  I can't comment directly, obviously. All I have is my faith (irrational belief) that we can reengineer our workflows to ease our own suffering. I used to create prepress (print manufacturing) software for Mac (old and new) & Windows. Multi platform, multi executables, multi language, multi target builds. It'd pull all the resource bundles (L10N/I18N), recreate the the screen shots, rebuild the PDFs (manuals, marcom). The QA box farm would rerun all the regressions (combo of VirtualPC and VMware boxes) on multiple versions of multiple OSes (eg Japanese Windows) with all the necessary drivers (eg security dongles, which totally sucked). We'd end up with CD images and downloadable zips on our private website for VARs and high end customers. Seemed to work pretty good. I used to do a lot of electronic medical records stuff. My team (of 4 core devs) supported five regional exchanges (the first to market), 80 hospitals plus all their partners, pharma scripts, labs (internal and external), feeds to the govt (eg CDC, SSI). Basically 100s of data feeds of every mutant format and protocol imaginable. At the time, all of the data had to be stored on each customer's servers. Meaning we had to deploy and support in situ. Meaning firewalls, reverse SSH, forklifting files into place, whatever was permitted. We did multiple builds per week. Most deploys were push. Some we had to setup as pulls. We implemented auto updates, but never had the QA/Test resources to achieve the necessary confidence, which was a shame. Seemed to work pretty good. Sure, today's cloud deploys are complicated in other ways. But the more stuff changes, the more it all looks the same. PS- Rereading your comment... Maybe consider changing some of the steps from push to pull. I was super inspired by the architecture of postfix (email server). Trying to mimick it simplified a lot of my own efforts.