As described in RFC-18, there is a need for a refactorization of Keep
and tBTC release processes in order to reduce human involvement and
make the processes faster and less error prone. A part of this task is
migration from CircleCI jobs to GitHub Actions.
Now that we have all CircleCI jobs from tbtc-dapp moved to GH Actions
(and verified), we can implement some final changes removing obsolete
CircleCI configs and cleaning up pieces of code used for workflows
testing. Here is a list of changes applied:
removed unnecessary comments
deleted ./circleci/config.yml (CircleCI jobs are no longer needed)
removed references to rfc-18... branches, which were used for
workflow testing
removed -wip suffix from name of the published image
added restrictions on workflow triggering conditions (see more info
below)
As we've migrated CircleCI jobs to GitHub Actions, we want to introduce
branch protection rules on master, requiring the passing of particular jobs
before merging PR to master. Those jobs in tbtc-dapp are:
dapp-build-and-publish
dapp-lint
What's more, we want to execute workflows containing those jobs only if
there were changes in particular paths. GitHub Actions allows for
specifying those paths by using on.<event_name>.paths syntax.
Unfortunately, such configuration for the pull-request event clashes
with the functionality of protected branches.
Example: If we set branch protection rule requiring the passing of
job_a and job_a will be part of workflow_a using
on.pull_request.paths = folder_a setting, the workflow_a won't be
started if we create PR that changes some files outside of folder_a.
Hence job_a won't be executed. But the PR will still require job_a
to be passing (or skipped) and will not allow for the merge of the PR
to the protected branch.
As skipping of the required jobs doesn't block the PRs from merging, we
decided to move the checking of paths for pull_request events from
workflow level to job level. It's not something natively supported by
GH Actions, but there is a dorny/paths-filter action that allows for
doing exactly that. We've set up the action to execute only if a
workflow was started by the pull_request event. Action checks the
list of files changed by the PR and when any of the files matches
provided filter, it sets the output to true. We then use that output
as a condition for execution of rest of the jobs in the workflow. This
way, if a particular job is required for the PR, but the path
conditions are not met, the job will be skipped (allowing for PR
merge).
Here is a summary of triggering conditions for Dapp workflow:
workflow dispatch:
Everything executed
push on master:
Everything executed if there are any changes OUTSIDE of these paths:
docs/**
infrastructure/**
pull_request:
Everything (except publishing) executed if there are any changes
OUTSIDE of these paths:
As described in RFC-18, there is a need for a refactorization of Keep and tBTC release processes in order to reduce human involvement and make the processes faster and less error prone. A part of this task is migration from CircleCI jobs to GitHub Actions.
Now that we have all CircleCI jobs from
tbtc-dapp
moved to GH Actions (and verified), we can implement some final changes removing obsolete CircleCI configs and cleaning up pieces of code used for workflows testing. Here is a list of changes applied:./circleci/config.yml
(CircleCI jobs are no longer needed)rfc-18...
branches, which were used for workflow testing-wip
suffix from name of the published imageAs we've migrated CircleCI jobs to GitHub Actions, we want to introduce branch protection rules on master, requiring the passing of particular jobs before merging PR to master. Those jobs in
tbtc-dapp
are:dapp-build-and-publish
dapp-lint
What's more, we want to execute workflows containing those jobs only if there were changes in particular paths. GitHub Actions allows for specifying those paths by using
on.<event_name>.paths
syntax. Unfortunately, such configuration for thepull-request
event clashes with the functionality of protected branches. Example: If we set branch protection rule requiring the passing ofjob_a
andjob_a
will be part ofworkflow_a
usingon.pull_request.paths = folder_a
setting, theworkflow_a
won't be started if we create PR that changes some files outside offolder_a
. Hencejob_a
won't be executed. But the PR will still requirejob_a
to be passing (or skipped) and will not allow for the merge of the PR to the protected branch. As skipping of the required jobs doesn't block the PRs from merging, we decided to move the checking of paths forpull_request
events from workflow level to job level. It's not something natively supported by GH Actions, but there is adorny/paths-filter
action that allows for doing exactly that. We've set up the action to execute only if a workflow was started by thepull_request
event. Action checks the list of files changed by the PR and when any of the files matches provided filter, it sets the output totrue
. We then use that output as a condition for execution of rest of the jobs in the workflow. This way, if a particular job is required for the PR, but the path conditions are not met, the job will be skipped (allowing for PR merge).Here is a summary of triggering conditions for
Dapp
workflow:master
: Everything executed if there are any changes OUTSIDE of these paths:docs/**
infrastructure/**
docs/**
infrastructure/**