-
-
Notifications
You must be signed in to change notification settings - Fork 748
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
ci: build pull requests #1228
ci: build pull requests #1228
Conversation
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 have no objections, would anyone from team like to comment on this?
This duplicates an existing workflow in the wrong branch. The PR target should be the compose branch and it should replace an existing release workflow if there is any |
The workflow will not run if it doesn't reach the main (dev), it can't simply stay in the compose-dev branch |
This workflow is meant to mimic the pr-build workflow for Flutter / the release workflow (without the push trigger) that was for compose on the previous repo and should be merged with main so that it triggers on pull requests for compose so that it can verify that the pr compiles / can be easily downloadable for testing purposes. #1235 is the potential release workflow for compose that will stay on |
Apparently, the workflow should also run if not on the main or dev branch, so it should be introduced with the compose branch if it is meant to create compose releases. |
@oSumAtrIX If I were to switch the branch to |
The conflicts happen because your source branch is based on the current dev branch. If you simply cherry pick your commits on top of the compose branch and force push it to the PRs source branch, this should solve the merge conflicts when you change the target to the compose branch |
Currently, there is a workflow present in the compose-dev branch, but it does not run @PalmDevs may know more about this. |
It simply uploads the build as an artifact in Actions, it doesn't create a release |
What do you mean by "it"? The workflow introduced by this PR or the existing one in the compose dev branch? |
The one introduced by this PR |
Sounds good, changing the target branch should be enough then. |
bf48e1d
to
4b24012
Compare
@oSumAtrIX done |
This comment was marked as outdated.
This comment was marked as outdated.
@Ushie I did some tests and for pull request workflows, it seems like the workflow has to be in the branch getting merged. Example:
|
It seems like what I said wasn't true, I'm not sure why I was strongly under the assumption that workflows are only recognised in the default branch, my comments can be ignored |
@Ushie No worries! |
Like this?
|
should it also be hashing other gradle files like |
Like this:
|
gradle-wrapper.properties should be kept, I'm not sure if other files are necessary |
sure, I just found that we do have a gradle-wrapper file. My bad. |
@oSumAtrIX Is this ready for merge now? |
Co-authored-by: oSumAtrIX <[email protected]>
Co-authored-by: oSumAtrIX <[email protected]>
a39b8ea
to
56ef9a1
Compare
@oSumAtrIX Is this ready to merge? |
@Ushie Anything else to add? |
@Ushie done |
This should hopefully allow
compose-dev
pr's to build the manager. (Though I haven't been able to test it much)This is a combination of flutter pr build and compose release.
This workflow is not for building & uploading to GitHub releases, it is meant for building/verifying compose pull requests.