Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
test build_and_deploy_hold workflow (#1661)
this pr add a build and deploy workflow with hold state. - Requires an environment `production` set in repo's settings with a 'require reviewers' protection rule on for team slapshot as qualify members to approve before workflow start deployment. - `deploy_hold.yml` is made to use the environment `production` setting. The github action `build_and_deploy_hold`, after receiving approval, will deploy three set of assets in folders with name based on tag version, major version and minor version. (/v1.2.3, /v1.2, /v1) - For tag release for support branches, such as cases where v1.2.1 is release but there's a newer version v1.3.0 previously release, we don't want to deploy to v1 (major version) and only to v1.2 (minor version) and v1.2.1 (tag version). Added `should_deploy_major_version` job to ensure this behavior Note: There are some limitations in how secrets and environments can work with reusable workflows (discussions in this [github post](https://github.community/t/reusable-workflows-secrets-and-environments/203695)). There's also a [repo](https://github.com/AllanOricil/workflow-template-bug/blob/master/.github/workflows/workflow-inplementation.yml) with some examples to show issues with environment and secrets when use certain ways. To summarize: I can't set `environment` in the top level job and use `uses` to call `deploy` workflow. That's not supported and seems to [error out during testing](https://github.com/yext/answers-search-ui/actions/runs/1763550565/workflow): `workflow is not valid, unexpected value 'uses'`. This mean `environment` have to either: 1) get pass into the reusable workflow `deploy.yml` as an input (similar to my-workflow-job-4 in the example repo): - this requires a default `staging` environment without approval restriction and this would spam prs with messages of deploying to staging (as shown in this pr), which could get annoying and cluttering up prs. But if the team is alright with this, I can update to use this approach. 2) hardcode into the workflow (similar to my-workflow-job-3 in the example repo): - this is what I have in `deploy_hold.yml` workflow where environment is hardcoded to `production`. Supposedly, when trying to access secrets in an action with an environment specified, github would check for the environment secrets first before checking repo secrets automatically so we don't have to pass in the secrets. But that [didn't work during testing](850e86e) so I kept the secrets as inputs. I also can't combine all the deploy jobs into one with 'steps' field because `secrets` input field for workflows in `steps` field is not supported. But I think it make sense for them to be separate jobs anyway since they are not dependent on each other, even though it feels a little like duplicating code. J=SLAP-1818 TEST=manual push a tag to repo, and see build_and_deploy_hold workflow ran: https://github.com/yext/answers-search-ui/actions/runs/1763784557. Check in s3 buckets from this branch's dir and see the expected assets in folders with major/minor/full versions in there. push two tags: test-v3.4.0 and test-v3.3.0 in order. See that the first tag deploy all versions and the second tag cancel the major version deployment ([test](https://github.com/yext/answers-search-ui/actions/runs/1774931889))
- Loading branch information