Fix/continuous delivery

[Ellen-Wittingen]

If the workflow fails with an error message about blobs along the lines of the following: buildx failed with: ERROR: failed to solve: [...] blob [...] then all recent cache files for staging on the Caches page need to be deleted and the workflow needs to be executed again. Instructions for this were added to the README.md.

Also added the option Perform all jobs, regardless of whether there are actual changes? to force the workflow to re-execute all its jobs. This was added because if the previous workflow run errored after staging was merged into master it will detect no changes and skip the Continuous Integration and Publish Image jobs, which means the changes won't go live.

[guidojw]

Can you make this one boolean too? I think I made it like this because boolean was not an option back in the day, but I see the UI nicely supports it now. Don't forget the checks below :)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 13.79%. Comparing base (26f13a0) to head (d96386b).

Additional details and impacted files

@@           Coverage Diff            @@
##           staging     #834   +/-   ##
========================================
  Coverage    13.79%   13.79%           
========================================
  Files          450      450           
  Lines         3067     3067           
========================================
  Hits           423      423           
  Misses        2644     2644           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

changes have been implemented

[DrumsnChocolate]

@lodewiges there's a problem with your commit: you have not taken care of the places where the value of this input is used. You can't change a type without updating the usages of the variable.
Will you be able to identify the occurrences in the workflow, and fix them? You can find all of these in continuous-delivery.yaml. An example is line 49:
INPUT_MERGE: ${{ github.event.inputs.merge }}
the line is followed by usage of INPUT_MERGE where the variable is checked to be 'y' or 'n'. That will most certainly not result in expected behaviour now that we've changed it to a boolean.

[DrumsnChocolate]

see comment

[DrumsnChocolate]

only one last request

[DrumsnChocolate]

Suggested change

	if: github.event.inputs.merge == true
	if: github.event.inputs.merge

can't we do this?

[lodewiges]

What i found online is that ==true is better. source: https://stackoverflow.com/questions/2953646/how-can-i-declare-and-use-boolean-variables-in-a-shell-script/21210966#21210966

[lodewiges]

we need to decide what would be better, and implement that everywhere, i forgot it in one line.

[DrumsnChocolate]

You are talking about shell expressions, I'm talking about GitHub expressions: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions

They are separate concepts.

I've doublechecked why I suggested this. I come to a slightly more nuanced conclusion now, based on https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_dispatchinputs
I think the conclusion is we can use inputs.merge and we don't need to check against a string, but when we use github.event.inputs.merge we do need to check against a string, because:

The workflow will also receive the inputs in the github.event.inputs context. The information in the inputs context and github.event.inputs context is identical except that the inputs context preserves Boolean values as Booleans instead of converting them to strings. The choice type resolves to a string and is a single selectable option.

[lodewiges]

I think implemented it correctly can you check?