Concourse time resource not triggered on Mac OS X - macos

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.

Related

Stop github action matrix case

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

Application Verifier fails to start on 3 separate Windows machines here

Simply, I cannot run App verifier (WOW or 64-bit). It simply does not start. Event viewer says:
Faulting application name: appverif.exe, version: 10.0.18362.1, time stamp: 0x58ca3409
Faulting module name: ntdll.dll, version: 10.0.18362.1139, time stamp: 0x335bbdaf
Exception code: 0xc0000374
Fault offset: 0x000dfa1d
Faulting process ID: 0x2ad0
Faulting application start time: 0x01d6aa7ad4a12bf6
Faulting application path: C:\Windows\SysWOW64\appverif.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report ID: 235c3a4d-2d54-4436-99bf-b54a217c9a7f
Additionally, I tried to run appverif.exe (in system and syswow64) under Visual Studio and I see:
EDIT (Update based on comments)
Some are suggesting that Application Verifier does not have a GUI. However, last time I ran it, I saw the following:
I asked Microsoft employee Gov Maharaj (from application compatibility team) and they already know about the issue and the issue is fixed in an update for the Windows 10 2004 SDK which was released in December 2020 (19041.685.201201-2105.vb_release_svc_prod1_WindowsSDK.iso):
The Windows 10 SDK, Version 2004 SDK servicing update (released
12/16/2020) contains the following fixes. If you encounter these
issues, we recommend that you update your version of the SDK as soon
as possible to avoid them:
Resolved issue that prevented AppVerifier from working
Download and install the update to fix it.
I managed to run the verifier under a SYSTEM account using PsExec:
...PsTools\PsExec64.exe -i -s C:\Windows\System32\appverif.exe
I've tried the recommended methods - installing the latest windows SDK and running the program through 'PsExec64.exe -i -s' but neither worked. This program seems to be something Microsoft periodically breaks, judging by what I've read.
I ran appverif.exe through visual studio and saw the following call stack on crash:
ntdll.dll!RtlReportCriticalFailure() Unknown
ntdll.dll!RtlpHeapHandleError() Unknown
ntdll.dll!RtlpHpHeapHandleError() Unknown
ntdll.dll!RtlpLogHeapFailure() Unknown
ntdll.dll!RtlpFreeHeapInternal() Unknown
ntdll.dll!RtlFreeHeap() Unknown
msvcrt.dll!00007ffd44449c9c() Unknown
appverifUI.dll!00007ffc9a41f9d6() Unknown
appverifUI.dll!00007ffc9a411636() Unknown
appverif.exe!00007ff64965281b() Unknown
appverif.exe!00007ff6496615ed() Unknown
kernel32.dll!00007ffd43957034() Unknown
ntdll.dll!RtlUserThreadStart() Unknown
It seems to be crashing after a heap free.

Signing, Notarizing, hardening, etc. a macOS command-line binary?

What are the most appropriate ways to harden, code-sign, notarize, package, etc., a command-line binary (stdin, stdout, etc., no windows or icons) to allow distribution of the binary to macOS Catalina users, so that they can run the utility with the least amount of pain/hassle?
Assume the default/stock OS configuration of GateKeeper, etc.
Assume the users most likely currently don't have the installed tools or skills to compile from source.
Assume that a Terminal window popping up when running the utility won't scare them.
OLD ANSWER (2020):
I've started using https://github.com/mitchellh/gon recently, and am very happy with it. From the makers of Vagrant, Terraform, Packer, et al.
UPDATED ANSWER (2022):
Gon is very nearly abandonware at this point, which is disappointing. However, since then, Apple also released notarytool, which essentially does what Gon did.
I use GoReleaser for releases, and this is the notarization step in my .goreleaser.yml file. (You should be able to convert this back to a standard shell command pretty easily.)
signs:
- id: gatekeeper
ids:
- macos-archive
signature: "${artifact}"
cmd: xcrun
args:
[
"notarytool",
"submit",
"./dist/{{ .ProjectName }}-{{ .Version }}.darwin.universal.zip",
"--apple-id",
"{{ .Env.AC_APPLE_ID }}",
"--password",
"{{ .Env.AC_PASSWORD }}",
"--team-id",
"{{ .Env.AC_TEAM_ID }}",
"--progress",
"--wait",
]

Does Google App Engine support session_affinity in the java flexible environment?

I have enabled the
network:
session_affinity: true
in my app.yaml but it doesn't work neither it's shown enabled when viewing the configuration by going to App Engine > Versions > Config > View.
Here is what I get there:
runtime: java
api_version: '1.0'
env: flexible
threadsafe: true
handlers:
- url: /.*
script: 'this field is required, but ignored'
automatic_scaling:
min_num_instances: 2
max_num_instances: 20
cpu_utilization:
target_utilization: 0.5
network: {}
resources:
cpu: 1
memory_gb: 4
disk_size_gb: 10
I'm using Spring Boot 2.1 btw.
Session affinity is a Beta feature. In order to use this feature you need to deploy with the beta command.
gcloud beta app deploy
After the deployment completes, you should see the below line in your config view.
network:
session_affinity: true
This is not a beta feature anymore, it's now available in mainstream gcloud but bugged, as explained here:
https://issuetracker.google.com/issues/154647126
For some reason, deploying does not display the parameter as set (in App Engine > Versions > Display config for a version) and it's not working for some people, I can confirm as I'm affected by the issue myself.
This bug is fixed in gcloud v356.0.0
Run gcloud components update to upgrade to the latest version.
Reference: https://issuetracker.google.com/issues/154647126?pli=1

Processing: Migrating to 2.0b1 from 1.51 - Issues on video library

I'm trying to migrate to new processing, as I use often in my life (it's an update, so I'm moving on...).
Here's my setup:
Mac OS X 10.7.3
Processing 2.0b1 (Launch Program in 32-bit mode)
$ java -version
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-11D50b)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
My setup used to work on Processing 1.5 - and all the problems that I'm seeing right now I not had using that release.
First:
Any examples from libraries/video/capture simply don't work. Sometimes it crashes, sometimes it freezes.
The console log after AsciiVideo:
DVFreeThread - CFMachPortCreateWithPort hack = 0xc083b7c0,
fPowerNotifyPort= 0xc085a0f0 DVFreeThread - CFMachPortCreateWithPort
hack = 0xc0809a60, fPowerNotifyPort= 0xc0808080 DVFreeThread -
CFMachPortCreateWithPort hack = 0xc08159a0, fPowerNotifyPort=
0xc082add0
I use the GSVideo too, and I tried to run the AsciiVideo from there.
The console error:
GSVideo version: 1.0.0 19200 Invalid memory access of location 0x0
eip=0x97cee3ba
and raised an error window
Process: java [25673] Path: /usr/bin/java
Identifier: com.apple.javajdk16.cmd Version: 1.0 (1.0)
Code Type: X86 (Native) Parent Process: JavaApplicationStub
[24849]
PlugIn Path: /var/folders/*/libjogl_desktop.jnilib PlugIn
Identifier: libjogl_desktop.jnilib PlugIn Version: ??? (???)
Date/Time: 2012-09-05 17:04:08.993 -0300 OS Version: Mac OS
X 10.7.3 (11D50b) Report Version: 9
...
I work with SimpleOpenNI, GSVideo, GLgraphics, SurfaceMapper... I decided migrate yesterday, to increase performance using the same CPU when I render videos.
I think it's better to ask this question on the processing forum.
Reason why you get this error is that the video library is rewritten from scratch in Processing 2, and it's based on GSVideo. Check the video examples in Processing 2.0b3.
Also, SurfaceMapper is currently not working with Processing 2.0, I'll look into that.
Best regards,
Jonas, Ixagon

Resources