Page History

...

1. Through the CLI, using 'bs run deployment prod', once deployed, but not replacing the current app, because some tests will be done while app is in production. If they pass then the latest tag will become the official tag, and will be officially deployed and recorded to deployment database. 

3 Way meet Jerry, Claudio, Patrick about app approval logic

...

1. w
2. yes that sounds good, these are some sample use cases we can cover:
   Use cases:
   1. if a pull request is created, then backend triggers a build/test, report back to the comments if successful
   2. if a reviewer requested changes, developer updates the pull request, and backend triggers the build/test again, report back to comments
   3. if a pull request is approved, merge onto main and backend trigger the build/test on main
   what do you think?
3. type of logic, where we do it
4. for pr, if we want backend to be monitoring the repo. 
5. what is the workflow? backend to cli user or to the repo
   1. typical case: user request build from backend (remote)
   2. but have option for local build, 
   3. nightly builds which a robot will request a build on its own
   4. should cli or backend to watch the pull request. 
   5. as a user if i use the cli to request a new branch, cli creates branch and calls to backend to the databae add that branch, then backend can monitor the pull request
   6. if the user want to fix something, create with cli a branch
   7. get workflow going from user to repo pull request to merge 
   8. we want some extra variables with approval behavior like who approves and whats requires
   9. can put the approval test rules in the backend, where backend can read the output test in like JSON format. 
   10. can use backend or github review
   11. example, when user starts remote build with cli, they can also pass in the approval rule like 80% tests pass etc.
6. but we want to have a small menu of possible rules, and each component will choose among them
7. another workflow: trusted commiters - has access to backdoor to pass own code review.
8. in the database or manifest, who is approval rules
9. TODO: send to Claudio the documentation we create for the exact workflow of how this going to work
10. can we have backend support github issues and Jira issues, to add coments to github/jira. It is possible.
11. unlike traditional ci/cd we dont want to deploy until the pamm starts, deployment to production should always be started by hand. 
12. have cater and github/issue cross-refrence
13. want feature to put a gate, deployment only allowed during time specified in the cater for the issue
14. new cater not problem but won't be rolled out until january/february
15. we also want a workflow where if someone in acr creates a cater