This PR is part of a bigger work, spanning multiple repositories.
The main purpose of the work is to automate the process of workflows`
executions during product deployment, so that the workflows would be
triggered in a particular logical order and at the correct moment. By
that we mean:
workflows requiring the presence of artifacts created by other
workflows would not start before those upstream workflows are
finished
successfully executed workflows would automatically kick-off
downstream workflows specified in the config file
if any workflow in that chain of executions fails, the downstream
workflows will not be triggered
To achieve the above requirements, following changes were introduced:
A repository (called ci) managing the order of workflow executions
was created
The config/config.json file in ci repo describes the
upstream/downstream relations between product modules and workflows
The Main GH Actions workflow in ci repo allows for manual
triggering of workflow deploying specified module, by providing the
details of its upstream builds (to trigger deploy of the most
upstream module, Main must be triggered with empty
upstream_builds input)
The triggering of module workflows by the ci's Main workflow
happens thanks to a keep-network/run-workflow action working as an
intermediary (Main calls the run-workflow, which triggers
workflow deploying the specified module)
All NPM modules built as a part of the release process get versioned
with <base-version>-<environment>.<build-number>+<branch>.<commit>
version (thanks to keep-network/upstream-builds-query action that
reads versions of older deployments and thanks to
keep-network/npm-version-bump@v2 action that bumps-up the version
of the new artifact)
(note: tagging of artifacts and versioning of docker images will be
done at the later stage, outside this PR)
Deployment workflows that are about to successfully finish will be
executing the keep-network/notify-workflow-completed action as the
last step - the action will then trigger the ci's Main workflow
with appropriate inputs
Module workflows configuration has been adjusted to support the above
features
Conditions of execution of particular jobs/steps have been modified
after the changes contracts migration and deployments of artifacts
happens only for workflows triggered by the workflow-dispatch
event; actions like linting and sec scans are no longer executed for
workflows triggered by workflow-dispatch
Additionally, a couple of other changes were introduced to improve
the process of build management:
This PR is part of a bigger work, spanning multiple repositories. The main purpose of the work is to automate the process of workflows` executions during product deployment, so that the workflows would be triggered in a particular logical order and at the correct moment. By that we mean:
To achieve the above requirements, following changes were introduced:
ci) managing the order of workflow executions was createdconfig/config.jsonfile incirepo describes the upstream/downstream relations between product modules and workflowsMainGH Actions workflow incirepo allows for manual triggering of workflow deploying specified module, by providing the details of its upstream builds (to trigger deploy of the most upstream module,Mainmust be triggered with emptyupstream_buildsinput)ci'sMainworkflow happens thanks to akeep-network/run-workflowaction working as an intermediary (Maincalls therun-workflow, which triggers workflow deploying the specified module)<base-version>-<environment>.<build-number>+<branch>.<commit>version (thanks tokeep-network/upstream-builds-queryaction that reads versions of older deployments and thanks tokeep-network/npm-version-bump@v2action that bumps-up the version of the new artifact) (note: tagging of artifacts and versioning of docker images will be done at the later stage, outside this PR)keep-network/notify-workflow-completedaction as the last step - the action will then trigger theci'sMainworkflow with appropriate inputsworkflow-dispatchevent; actions like linting and sec scans are no longer executed for workflows triggered byworkflow-dispatchREF: https://github.com/keep-network/keep-core/pull/2453 https://github.com/keep-network/keep-ecdsa/pull/777 https://github.com/keep-network/tbtc/pull/791 https://github.com/keep-network/tbtc.js/pull/122
TODO: same things as mentioned in https://github.com/keep-network/keep-core/pull/2453