Introduce before_script which will be executed prior the command

[boesing]

Q	A
Documentation	yes
New Feature	yes

Description

This adds the possibility to pass gatekeeping commands to the action without actually polluting the real command.

• with Use XmlLint against tool configurations (PHPUnit, PHPCS, Psalm) laminas-ci-matrix-action#31, we want to introduce linting of phpunit, psalm, etc. configuration files
• in https://github.com/laminas/laminas-cache/pull/196/files#diff-3fb49ad00d3736f1ca8276f568f5d8bbe8c1604f6187ab5ecf921e1012f47c98R15, we want to install a very specific version of a composer dependency which won't be installed when using lowest or latest (due to the constraint ^1.0 || ^2.0 || ^3.0)
• I've added some xmlstarlet magic to modify convertDeprecationsToExceptions setting within phpunit.xml.dist in https://github.com/laminas/laminas-component-installer/blob/3c998d2b2755985c71cd4d5d9b294228f63d3a65/.laminas-ci.json#L6

All these quirks could be passed via that new JOB property instead of passing consecutive commands via the command property.

---

I am open to rename the property, I simply did not found a better naming (yet).

[Ocramius]

Is this some sort of before_script:? The name "gatekeeper" kinda implies that they stop something 🤔

[boesing]

They might stop something in case they fail.

We do have that .laminas-ci/pre_run.sh which can be created in every project.
Thats kinda similar logic and might stop the command from being executed (depending on how that script is configured).

[boesing]

So lets take the xmllint example from the link in the initial post, in case the linting fails - the command is not being executed.

So instead someone has to pass xmllint ... && whateverUsesTheLintedXmlConfig, we just have an additional entry in that new introduced property.

[Ocramius]

We do have that .laminas-ci/pre_run.sh which can be created in every project.
Thats kinda similar logic and might stop the command from being executed (depending on how that script is configured).

I don't fully understand how this new syntax is different, and whether it's supposed to replace the old one (to be deprecated, I suppose?) 🤔

[boesing]

I don't fully understand how this new syntax is different, and whether it's supposed to replace the old one (to be deprecated, I suppose?) 🤔

What syntax? Not sure if we are talking about the same thing.

1. we still support pre-run.sh since that is a script which can be created by projects using our CI action, no plans to drop that
2. we/I want to add a new way to provide additional commands to be executed via the matrix action

So the latter would be stuff like:

1. linting of tool configurations (such as xmllint for psalm.xml/psalm.xml.dist/phpunit.xml/phpunit.xml.dist and yamllint for whatever YAM configuration, etc.) - see Use XmlLint against tool configurations (PHPUnit, PHPCS, Psalm) laminas-ci-matrix-action#31
2. whatever else could be added as a command which needs to run beforehand which we are aware of in the matrix already

---

The current way of doing so would be polluting the JOB JSON by doing:

{"...": "...", "command": "xmllint psalm.xml.dist && vendor/bin/psalm --shepherd --no-cache --whatever"}

IMHO, this is not really readable and thus I would prefer something like:

{"...": "...", "command": "vendor/bin/psalm --shepherd --no-cache --whatever", "gatekeeper_commands": ["xmllint psalm.xml.dist"]}

(Still open to rename the property tho)

[Ocramius]

So, if I understand it correctly, gatekeeper_commands (to be renamed, indeed) is a better way of writing bash -c "$GATEKEEPER_COMMAND" && bash -c "$CI_COMMAND"?

Looking good, just probably better to call it before_script (like in https://docs.gitlab.com/ee/ci/yaml/#before_script)

[boesing]

[...] is a better way of writing bash -c "$GATEKEEPER_COMMAND" && bash -c "$CI_COMMAND"?

Exactly. Not sure if this is really necessary tho but given the fact that we do have some stuff depending on the commands name (BC compatibility for exclusion logic), adding additional stuff to the command property might become a burden when it comes to that exclusion logic.

call it before_script

Sounds good, will adjust the code when I find some time for it. Thanks!

[boesing]

I've renamed gatekeeper_commands to before_script and extended the README to outline the idea of before_script.

I also created #104 to have an additional after_script. I am thinking about moving some quirks to the matrix action after we released a container version which supports before_script and after_script:

laminas-continuous-integration-action/entrypoint.sh

Lines 195 to 199 in c2d713a

	if [[ "${COMMAND}" =~ phpunit ]];then
	echo "Setting up PHPUnit problem matcher"
	cp /etc/laminas-ci/problem-matcher/phpunit.json "$(pwd)/phpunit.json"
	echo "::add-matcher::phpunit.json"
	fi

laminas-continuous-integration-action/entrypoint.sh

Lines 201 to 209 in c2d713a

	if [[ "${COMMAND}" =~ markdownlint ]];then
	echo "Setting up markdownlint problem matcher"
	cp /etc/laminas-ci/problem-matcher/markdownlint.json "$(pwd)/markdownlint-matcher.json"
	echo "::add-matcher::markdownlint-matcher.json"
	if [ ! -f ".markdownlint.json" ];then
	echo "Installing markdownlint configuration"
	cp /etc/laminas-ci/markdownlint.json .markdownlint.json
	fi
	fi

[Ocramius]

LGTM 👍

Thanks @boesing