keep-network / tbtc-dapp

Deposit BTC and redeem TBTC
http://dapp.test.tbtc.network/
MIT License
33 stars 31 forks source link

Cleanup after moving to GH Actions #391

Closed michalinacienciala closed 3 years ago

michalinacienciala commented 3 years ago

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:

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:

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:

michalinacienciala commented 3 years ago

@nkuba, please set following jobs in branch protection settings as required for PR merge: