Stop github action matrix case - yaml

I want to use a github action matrix for different build types, but there's one case of the matrix that I'm not interested in supporting. How do I stop this case from running but still get the build to marked successfully.
In this particular case I want to build Windows and Ubuntu, 32bit and 64bit but I'm not interested in supporting 32bit on Ubuntu. So my matrix would be:
strategy:
fail-fast: false
matrix:
os: [windows-latest, ubuntu-latest]
platform: ['x64', 'x86']
My current solution is to stop each action running by adding an if expression:
- name: Build Native
if: ${{ ! (matrix.os == 'ubuntu-18.04' && matrix.platform == 'x86') }}
While this works okay, I feel there ought to be a more elegant way of solving this. Can anyone help make my yaml script more beautiful?

Perhaps the strategy.matrix.exclude directive is suitable?
From the documentation:
You can remove a specific configurations defined in the build matrix
using the exclude option. Using exclude removes a job defined by the
build matrix.
So in your case, probably something like this:
strategy:
matrix:
os: [windows-latest, ubuntu-latest]
platform: ['x64', 'x86']
exclude:
- os: ubuntu-latest
platform: x86

There are situations where one wants to include or exclude specific matrix coordinates so as not to run some of them, yet (stretching the question a bit) also still want the job to run for a couple of these coordinates, so as to track the evolution of it across commits, while not blocking the whole process.
In that situation, continue-on-error at the job level, combined with matrix include and exclude is very useful:
Prevents a workflow run from failing when a job fails. Set to true to allow a workflow run to pass when this job fails.
This is similar to GitLab CI's allow_failure, although at time of writing GitHub Actions UI only has two states (red failed and green passed) whereas GitLab introduces a third one (orange warning) in that case.
Here is a real-life workflow example:
jobs:
linux:
continue-on-error: ${{ matrix.experimental }}
strategy:
fail-fast: false
matrix:
os:
- ubuntu-20.04
container:
- 'ruby:2.0'
- 'ruby:2.1'
- 'ruby:2.2'
- 'ruby:2.3'
- 'ruby:2.4'
- 'ruby:2.5'
- 'ruby:2.6'
- 'ruby:2.7'
- 'ruby:3.0'
- 'ruby:2.1-alpine'
- 'ruby:2.2-alpine'
- 'ruby:2.3-alpine'
- 'ruby:2.4-alpine'
- 'ruby:2.5-alpine'
- 'ruby:2.6-alpine'
- 'ruby:2.7-alpine'
- 'jruby:9.2-jdk'
experimental:
- false
include:
- os: ubuntu-20.04
container: 'ruby:3.0.0-preview2'
experimental: true
- os: ubuntu-20.04
container: 'ruby:3.0.0-preview2-alpine'
experimental: true

Related

Add SWIFT_ACTIVE_COMPILATION_CONDITIONS via XcodeGen

Goal🚩: I want to add Xcode Target Build Settings - Active Compilation Conditions via XcodeGen.
Is there any soultion to achieve this?
I've tried to add this code into project.yml file but didn't work.
targets:
...
configs:
Debug:
SWIFT_ACTIVE_COMPILATION_CONDITIONS: DEBUG
PreRelease:
SWIFT_ACTIVE_COMPILATION_CONDITIONS: PRERELEASE
Release:
SWIFT_ACTIVE_COMPILATION_CONDITIONS: RELEASE
And my desired result is this image.
enter image description here

GitHubActions on Windows host (powershell?): exit code of previous lines being ignored

I had this step in a macOS lane:
jobs:
macOS_build:
runs-on: macOS-latest
steps:
- uses: actions/checkout#v1
- name: Build in DEBUG and RELEASE mode
run: ./configure.sh && make DEBUG && make RELEASE
Then I successfully split it up this way:
jobs:
macOS_build:
runs-on: macOS-latest
steps:
- name: Build in DEBUG and RELEASE mode
run: |
./configure.sh
make DEBUG
make RELEASE
This conversion works because if make DEBUG fails, make RELEASE won't be executed and the whole step is marked as FAILED by GitHubActions.
However, trying to convert this from the Windows lane:
jobs:
windows_build:
runs-on: windows-latest
steps:
- uses: actions/checkout#v1
- name: Build in DEBUG and RELEASE mode
shell: cmd
run: configure.bat && make.bat DEBUG && make.bat RELEASE
To this:
jobs:
windows_build:
runs-on: windows-latest
steps:
- uses: actions/checkout#v1
- name: Build in DEBUG and RELEASE mode
shell: cmd
run: |
configure.bat
make.bat DEBUG
make.bat RELEASE
Doesn't work, because strangely enough, only the first line is executed. So I tried trying to change the shell attribute to powershell:
jobs:
windows_build:
runs-on: windows-latest
steps:
- uses: actions/checkout#v1
- name: Build in DEBUG and RELEASE mode
shell: powershell
run: |
configure.bat
make.bat DEBUG
make.bat RELEASE
However this fails with:
configure.bat : The term 'configure.bat' is not recognized as the name
of a cmdlet, function, script file, or operable program. Check the
spelling of the name, or if a path was included, verify that the path
is correct and try again.
Then I saw this other SO answer, so I converted it to:
jobs:
windows_build:
runs-on: windows-latest
steps:
- uses: actions/checkout#v1
- name: Build in DEBUG and RELEASE mode
shell: powershell
run: |
& .\configure.bat
& .\make.bat DEBUG
& .\make.bat RELEASE
This finally launches all batch files independently, however it seems to ignore the exit code (so if configure.bat fails, it still runs the next lines).
Any idea how to separate lines in a GithubActions workflow properly?
In PowerShell, you'll have to check the automatic $LASTEXITCODE variable after each call if you want to take action on the (nonzero) exit code of the most recently executed external program or script:
if ($LASTEXITCODE) { exit $LASTEXITCODE }
If you want to keep the code small, you could check for intermediate success vs. failure via the automatic $? variable, which is a Boolean that contains $true if the most recent command or expression succeeded, which in the case of external programs is inferred if the exit code is 0:
.\configure.bat
if ($?) { .\make.bat DEBUG }
if ($?) { .\make.bat RELEASE }
exit $LASTEXITCODE
Note that if you were to use PowerShell (Core) 7+, you could use the bash-like approach, since && and ||, the pipeline-chain operators, are now supported - as long as you end each statement-internal line with &&, you can place each call on its own line:
# PSv7+
.\configure.bat &&
.\make.bat DEBUG &&
.\make.bat RELEASE
However, note that any nonzero exit code is mapped onto 1 when the PowerShell CLI is called via -Command, which is what I presume happens behind the scenes, and assuming that an external program is called last. That is, the specific nonzero exit code is lost. If it is of interest, append an exit $LASTEXITCODE line to the above.

What is does the build information contain in conda env export?

When using conda env export it is possible to remove the build information with --no-build:
...
dependencies:
- _libgcc_mutex=0.1=main
- attrs=19.3.0=py_0
- backcall=0.1.0=py37_0
- beautifulsoup4=4.8.2=py37_0
- biopython=1.76=py37h7b6447c_0
- blas=1.0=mkl
- bleach=3.1.0=py37_0
...
and with --no-build
dependencies:
- _libgcc_mutex=0.1
- attrs=19.3.0
- backcall=0.1.0
- beautifulsoup4=4.8.2
- biopython=1.76
- blas=1.0
- bleach=3.1.0
- bzip2=1.0.8
- ca-certificates=2020.1.1
Could you explain in detail what exactly is this build information? The compiler and its version? What else is in there?
The build information is a hash of the variant keys in the recipe. Quoting the docs:
The takeaway message is that hashes will appear when binary compatibility matters, but not when it doesn't.
and
As of conda-build 3.1.0, this hashing scheme has been simplified. A hash will be added if all of these are true for any dependency:
Package is an explicit dependency in build, host, or run deps.
Package has a matching entry in conda_build_config.yaml which is a pin to a specific version, not a lower bound.
That package is not ignored by ignore_version.
OR
Package uses {{ compiler() }} Jinja2 function.
The documentation is here: https://docs.conda.io/projects/conda-build/en/latest/resources/variants.html#differentiating-packages-built-with-different-variants There's also a blog post (that I can't find now) with some more information.

How to use sibling Stack projects?

I've got a project structured thusly:
- proj/
- subproj1/
- stack.yaml
- subproj1.cabal
- ...
- subproj2/
- stack.yaml
- pkg1/
- ...
- pkg2/
- ...
- ...
And my subproj1/stack.yaml file contains this:
packages:
- .
- location: ../subproj2
subdirs:
- pkg1
- pkg2
extra-dep: true
I'm noticing inconsistent build behavior, when running "stack build" from within the subproj1/ directory. And I'm wondering if I have set up my project structure in an inherently unstable way. Would it, for instance, be more stable to use a single stack.yaml file, located in the proj/ directory?
Yes, unfortunately there are some known issues with this setup - https://github.com/commercialhaskell/stack/issues/3130 . Hopefully will be fixed at some point! One way to work around this is to set your STACK_YAML environment variable, so that stack invocations will ignore current directory.

Concourse time resource not triggered on Mac OS X

I'm new to concourse and really excited to start working with it but I have a problem running the hello world example described here: https://concourse-ci.org/hello-world.html (example with time resource)
I'm running this example on Mac OS X (El Capitan) with a standalone binary of concourse. I slightly edited my pipeline for mac to look like this:
resources:
- name: every-1m
type: time
source:
interval: 1m
jobs:
- name: navi
plan:
- get: every-1m
trigger: true
- task: annoy
config:
platform: darwin
run:
path: echo
args: ["Hey! Listen!"]
But for some reason the time resource is not triggered. The job 'navi' is never started. Any idea why this would happen?
Does it have anything to do with OS X?
When I directly trigger the navi job I get the following: every 1m - no versions available (image)
Sounds like you are running your worker on OS X. All the built-in resources require at least 1 worker in your pool that support the linux platform. This would account for the time resource never firing.

Resources