-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
3p Development RFC #82
Conversation
Signed-off-by: Mike Chang <changml@amazon.com>
2. A maintainer will manually execute the build step in Github Actions once all prechecks are green. An automated comment referencing a codeowners approval group can be added to the PR, which would notify maintainers. | ||
|
||
3. If the build fails, the 3P Package PR is kicked back for re-work | ||
4. Once the build step is complete, the package is automatically uploaded to Github packages for the O3DE org. The 3P package PR should be merged into 3p-package-source. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking the upload step should be performed after the PR is merged in 3p-package-source instead of after the build step. For example the PR may still need additional changes even after a successful build.
We could instead use a post merge publish step that a maintainer would approve.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We still need a way for the developer to test their changes in AR against Github Packages. This could be done locally, but a end to end test during the PR phase with the reference hash requires the package to be built and downloaded from a hard to tamper location in the O3DE account.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, I'm thinking we can provide a publish step for changes pushed to a branch which a contributor can use to test in their fork instead of building it into the PR build step. Either way is fine, just looking for a way to separate the PR workflow from the deployment workflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, if the contributor forked the repo, the GHA in their fork would follow along and publish the package in their account. This is outlined in the "3P Package Development Phase" section, but I'll make it more clear that it would be building and publishing in their account fork.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, if the contributor forked the repo, the GHA in their fork would follow along and publish the package in their account (at no cost them). This is outlined in the "3P Package Development Phase" section, but I'll make it more clear that it would be building and publishing in their account fork.
Signed-off-by: Mike Chang <changml@amazon.com>
Signed-off-by: Mike Chang <changml@amazon.com>
Signed-off-by: Mike Chang <changml@amazon.com>
Co-authored-by: allisaurus <34254888+allisaurus@users.noreply.github.com> Signed-off-by: Mike Chang <changml@amazon.com>
Co-authored-by: allisaurus <34254888+allisaurus@users.noreply.github.com> Signed-off-by: Mike Chang <changml@amazon.com>
Signed-off-by: Mike Chang <changml@amazon.com>
Outlines a plan to utilize Github Actions and Github Packages to build and host 3p packages