Auto-deploy/release lighthouse

tiger5226 commented

2018-07-25 00:55:57 +02:00

(Migrated from github.com)

Copy link

https://github.com/semantic-release/semantic-release

This is a really cool and popular package. Then we just need to process the github webhook when a tagged release is created to download, unzip and startup the binary.

Acceptance Criteria

Definition of Done

Tested against acceptance criteria
Tested against the assumptions of the user story
The project builds without errors
Unit tests are written and passing
Tests on devices/browsers listed in the issue have passed
QA performed & issues resolved
Refactoring completed
Any configuration or build changes documented
Documentation updated
Peer Code Review performed

https://github.com/semantic-release/semantic-release This is a really cool and popular package. Then we just need to process the github webhook when a tagged release is created to download, unzip and startup the binary. ### Acceptance Criteria 1. 2. 3. ### Definition of Done - [ ] Tested against acceptance criteria - [ ] Tested against the assumptions of the user story - [ ] The project builds without errors - [ ] Unit tests are written and passing - [ ] Tests on devices/browsers listed in the issue have passed - [ ] QA performed & issues resolved - [ ] Refactoring completed - [ ] Any configuration or build changes documented - [ ] Documentation updated - [ ] Peer Code Review performed

tiger5226 commented

2018-09-16 04:22:31 +02:00

(Migrated from github.com)

Copy link

This should be done soon. There is no reason we should keep wasting time manually pulling, building deploying lighthouse. It is time we never get back.

tiger5226 commented

2018-10-28 16:03:08 +01:00

(Migrated from github.com)

Copy link

1 - The update.sh file needs to be move to the prod environment and needs chmod 775 so lighthouse can execute it.
2 - An initial deployment of the changes needs to be done.
3 - SLACK_HOOK_URL environment variable needs to be applied to the prod environment ( I have this ).
4 - The travis.yml needs a commit that sets the production url for the notification.

The PR does a few things, it allows for a CI/CD workflow on the master branch. The CI is minimal and we can add more checks as we go. For CD there is a new autoupdate api. If it is not a PR, is the master branch and is signed by travis, it will run the update script which goes through the current manual deployment process. It also adds slack integration so we can see this workflow happening and can verify it was successful. With the addition of slack integration we will also be able to see any importer errors, or other app errors that need to be addressed.

I bit the bullet and got this done saturday. #127 is the PR. I had been holding off on this since July, but with recent changes being frequent enough with new contributors too, we are just losing time deploying for no reason. Once approved the following needs to happen. 1 - The update.sh file needs to be move to the prod environment and needs `chmod 775` so lighthouse can execute it. 2 - An initial deployment of the changes needs to be done. 3 - `SLACK_HOOK_URL` environment variable needs to be applied to the prod environment ( I have this ). 4 - The `travis.yml` needs a commit that sets the production url for the notification. The PR does a few things, it allows for a CI/CD workflow on the master branch. The CI is minimal and we can add more checks as we go. For CD there is a new `autoupdate` api. If it is not a PR, is the master branch and is signed by travis, it will run the update script which goes through the current manual deployment process. It also adds slack integration so we can see this workflow happening and can verify it was successful. With the addition of slack integration we will also be able to see any importer errors, or other app errors that need to be addressed.

Auto-deploy/release lighthouse #95

Acceptance Criteria

Definition of Done