this repo has no description
0
fork

Configure Feed

Select the types of activity you want to include in your feed.

[new release] dkml-workflows (1.1.0)

CHANGES:

New Features:
- Desktop testing for macOS/Intel (or macOS/ARM64 with Rosetta emulator) and Linux 32/64-bit on Intel/AMD
- Help messages for desktop testing on Windows
- Optional secondary switch `two` in addition to primary switch `dkml` enabled with
input variable `SECONDARY_SWITCH=true`

Breaking changes:
- The GitLab job names `build_linux`, `build_macos` and `build_win32` are now private job names `.linux:setup-dkml`,
`.macos:setup-dkml` and `.win32:setup-dkml`. This means in your own `.gitlab-ci.yml` you will need an "extends" statement,
like so:
```yaml
build_linux:
extends: .linux:setup-dkml # ADD THIS ONE LINE!
script:
- opamrun exec -- echo Build me some Linux stuff
```

*Why break the API?*

This change was done so you could do incremental staged builds where job A does only the setup (which caches the OCaml
compiler) and where the second job B does both the setup and the full build of your OCaml code. By using a private job
name that starts with a dot (.) like `.linux:setup-dkml`, both job A and job B can extend from `.**OS**:setup-dkml` to
share the setting up of the OCaml compiler cache.

The benefit you get for the extra complexity is that you are more likely to stay under GitLab runner
time limits; the shared SaaS GitLab runners time out jobs at 2 hours.
For example Job A can take one hour or more for Windows when you enable `SECONDARY_SWITCH=true`.

Hypothetically you could do a full build of your code without the caching of the OCaml compiler that took 2.5 hours.
GitLab would fail your full build with time limit failures. But by splitting job A from job B, job A takes 1-1.5 hours
while job B would only take 1.5 hours plus a few minutes for reading the cache of job A. Now both job A and job B
can work without running into time limits.

*Why is it a minor break?*

Since there was no announcement of the previous 1.0.0 version, it is unlikely anyone is broken. And if
anyone is broken, they just need to add three `extends: .setup_dkml_XXX` to their script.

Other changes:
- Performance: Linux CI now avoids ~10 second ManyLinux (dockcross) unnecessary recursive chown of root:root
owned container files. As long as calling user is root (which is true for GitHub Actions and GitLab CI/CD)
the chown operation is skipped.
- Remove unused `gl_tags` matrix variable

+35
+35
packages/dkml-workflows/dkml-workflows.1.1.0/opam
··· 1 + opam-version: "2.0" 2 + synopsis: 3 + "GitLab CI/CD and GitHub Action workflows used by and with Diskuv OCaml (DKML) tooling" 4 + description: 5 + "GitLab CI/CD and GitHub Action workflows used by and with Diskuv OCaml (DKML) tooling." 6 + maintainer: ["opensource+diskuv-ocaml@support.diskuv.com"] 7 + authors: ["Diskuv, Inc. <opensource+diskuv-ocaml@support.diskuv.com>"] 8 + license: "Apache-2.0" 9 + homepage: "https://github.com/diskuv/dkml-workflows" 10 + bug-reports: "https://github.com/diskuv/dkml-workflows/issues" 11 + depends: [ 12 + "dune" {>= "2.9"} 13 + "astring" {>= "0.8.5"} 14 + "bos" {>= "0.2.1"} 15 + "crunch" {>= "3.2.0"} 16 + "jingoo" {>= "1.4.4"} 17 + "uutf" {>= "1.0.3"} 18 + "odoc" {with-doc} 19 + ] 20 + dev-repo: "git+https://github.com/diskuv/dkml-workflows.git" 21 + # Until Dune 3+ the auto-generated '.opam' will have an invalid ["dune" "install" ...] step 22 + # that messes up with cross-compilation. Customized it to remove it. 23 + build: [ 24 + ["dune" "subst"] {dev} 25 + ["dune" "build" "-p" name "-j" jobs "@install" "@runtest" {with-test} "@doc" {with-doc}] 26 + ] 27 + url { 28 + src: 29 + "https://github.com/diskuv/dkml-workflows/releases/download/1.1.0/dkml-workflows-1.1.0.tbz" 30 + checksum: [ 31 + "sha256=7e2e96fe13c0c9419c2304beda22361b8a3820a9b0757d03490720f16ae312b7" 32 + "sha512=38ef672c6bcd16afbde4e058dae6c4f0584e6e192269497568c0ed3a54d6a0b3fa04905812819b8746b741f80dccdd37b159337a059a829169fa00f4db52df09" 33 + ] 34 + } 35 + x-commit-hash: "bf92f534506340d62055b5d24e04b94dfb07693f"