hi All,
I am working on GitHub integration with App Cloud. Please find the user
stories below.
User Stories
1.
Public git repo (Anonymous users will have read access)
Prerequisite:
-
It requires to create a webhook under the GitHub repo to invoke the
endpoint provided by App Cloud to notify whenever a ‘git push’ takes place.
While invoking the endpoint, a secret token will be used which is shared
between application (In App Cloud) and repo (GitHub) for authentication -
This is done by calling GitHub API programmatically while creating the
application in App Cloud.
1.
Non-buildable source (e.g: PHP application)
In this scenario, AppOwner is having a repo with php source code. In App
Cloud, he can create an application by providing the git url, branch,
personal access token and deploy policy. Underneath, the generated Docker
file will have the repo clone command. Hence when a new image is created,
it will contain the source.
Based on the condition associated in the deploy policy, the latest source
will be cloned when docker image creation happens.
1.
Buildable source (e.g: Java application)
In this scenario, AppOwner is having a repo with java source code. In App
Cloud, he can create an application by providing the git url, branch,
personal access token and deploy policy. Underneath, the repo will be
cloned, build via a kubernetes job with maven and then artifact will be
copied to the temp directory where docker image creation happens.
Based on the condition associated in the deploy policy, the repo will be
cloned, a build will be triggered via a kubernetes job and the new artifact
will be copied to the temp directory where docker image creation happens.
1.
Private git repo
Prerequisite:
-
It requires to create a webhook under the GitHub repo to invoke the
endpoint provided by App Cloud to notify whenever a ‘git push’ takes place.
While invoking the endpoint a secret token will be used which is shared
between application (In App Cloud) and repo (GitHub) for authentication -
This is done by calling GitHub API programmatically while creating the
application in App Cloud.
1.
Non-buildable source (e.g: PHP application)
In this scenario, user is having a repo with php source code. In App Cloud,
he can create an application by providing the git url, branch, personal
access token and deploy policy. Underneath, the generated Docker file will
have the repo clone command along with personal access token. Hence when a
new image is created, it will contain the source.
Based on the condition associated in the deploy policy, the latest source
will be cloned when docker image creation happens.
2.2. Buildable source (e.g: Java application)
In this scenario, AppOwner is having a repo with java source code. In App
Cloud, he can create an application by providing the git url, branch,
personal access token and deploy policy. Underneath, the repo will be
cloned with personal access token, build via kubernetes job with maven and
then artifact will be copied to the temp directory where docker image
creation happens.
Based on the condition associated in the deploy policy, the repo will be
cloned with personal access token, a build will be triggered via kubernetes
job and the new artifact will be copied to the temp directory where docker
image creation happens.
1.
No GitHub integration involved directly with the App Cloud
In this scenario, the user will take care of source repository as well as
the build process separately. App Cloud will be aware of only about the
built artifact.
1.
AppOwner has to upload the war file manually(This is already
supported in App Cloud)
2.
AppOwner has to create the application by providing the branch and
the secret token. Jenkins should be configured to call the App Cloud
endpoint with the security token and notify that the successfully built
artifact is ready for a given job (branch)
Deploy Policy: Specify the condition which requires to trigger a new
build/deployment.
1.
Manual deployment
2.
Auto deployment
1.
Cron Expression
2.
System configured time (e.g. Let’s say the time is configured to 10
mins. Which means if a deployment has triggered already, the system will
wait for another 10 minutes to trigger the next deployment
unless user does
a manual deploy)
Personal access token: Personal access tokens work the same as OAuth
tokens, and can easily be generated on GitHub.
As the first cut, we will be focusing on 'Public git repos - Non buildable
source' use case. Then App creation form will get a additional option as
depicted below to connect with GitHub repo.
to ''
The 'deployment policy' configuration will require for each branch
separately. Hence at the app creation, manual deploy policy will be enabled
by default. In order to enable rest of the policies, the UI will be
provided per version basis.
Feel free to share your thoughts/feedback on this.
--
Thanks and Regards,
Punnadi Gunarathna
Senior Software Engineer,
WSO2, Inc.; http://wso2.com <http://wso2>
Blog: http://hi-my-world.blogspot.com/
Tel : 94 11 214 5345
Fax :94 11 2145300
<http://lalajisureshika.blogspot.com/>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
