-
-
Notifications
You must be signed in to change notification settings - Fork 186
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: automate publishing to pub.dev #719
ci: automate publishing to pub.dev #719
Conversation
Thanks for opening this pull request!
|
The label |
Is the label only for issues? Or for PRs created using CI? |
Yes, most labels are only for issues, as a PR requires an issue reference anyway. In this case there is no label needed as far as I can see. |
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.
Looks pretty simple, any way we can dry run this to know whether it works? Does the package you're using have a dry run and/or debug option?
@mtrezza, pub has a dry run option, when activated, the command just checks if publishing would be possible. (Credentials are not tested, as far as I know.) The package supports setting it. https://github.com/k-paxian/dart-package-publisher#dryrunonly So we could set it to true, merge this to master, create a new test branch, update the pubspec.yaml versions in this branch and then create a temporary github release (name/tag does not matter, could be "test"). In the actions tab, we should see the action running and I assume we should see if it should work in the logs. For this, the account should not be needed, we should be able to set the secrets to dummy values. Some additional information:
Edit: Should I push a commit that sets dryRunOnly to true? |
Dont mind travis failing, it's the example app using deprecated stuff. We should fix it, but it's no priority. |
Yes please. Could we then simply try it out on the @RodrigoSMarques if we merge, it's important that you doesn't also publish manually. Could you please confirm that you are following this thread so we are all on the same page for publishing the next version? |
@mtrezza I've pushed the commit. Version 3.1.0 is "already" published to pub.dev. So if we create a github commit from the current master branch, the action should realize there is nothing to push and not run You asked @RodrigoSMarques to not publish right now. Is it planned to publish the development branch? Since dryRunOnly is set, we should not be able to screw something up while testing. |
I'm updating CHANGELOG.MD and README.MD and will be submitting a PR to the development branch. I will provide version 3.2. I'll let you know here as soon as I PR and merge it into the master. |
What is the purpose of the @RodrigoSMarques before we merge a PR or create a GH release or a tag, please let's discuss to make sure we are all on the same page. |
@mtrezza |
To prepare for the next step of release automation, we should use |
I think that's a good idea. Esp. since new contributors create a PR to master. |
For versioning see CONTRIBUTING.md. For branch model see parse-community/parse-server#7639 (comment), it's not yet in our docs. Note that the pre-release branches are optional. We have some repos in which we do not use them either because they are very simple repos or because we expect a high frequency of iterations and want to get developer feedback quickly. For the Parse Flutter SDK I assume we will be fine with only an |
Could you rebase this PR onto master? I'm not seeing the button to update the branch, although we have just merged the other PR. |
9f7afa4
to
6a901d0
Compare
Like this? |
pull_request is working!! Edit: It's getting late, I'll be back tomorrow. |
👍 Edit: later when automating publishing completely... When pushing to release, the logic is simple, just remove the prerelease part of the versions and publish. |
For manual release, the person manually creates a tag as part of the GitHub release form. In the workflow, the version tag needs to be taken from the release that triggered the workflow; this is a variable that is accessible in the workflow. For automated release, versioning will be determined by the auto-release framework, we'll have a more detailed discussion about this when we tackle step 2. |
So we just set the tag as the version in pubspec.yaml? I think it has to be right before already, since the code attached to the github release is otherwise dirty. |
I think so; manually setting the version in |
@fischerscode Do you know how I can find these tokens? Accord to the docs they should be in |
|
@mtrezza Just had a look, |
Thanks, that worked! For the record, the credential file location moved to:
|
So |
Yes, the secrets exist, with different names though, see my review comment. |
What happens if the dart publishing succeeds but the dart fails? Is that possible and what would be the consequences / complications? Should we change the workflow to first do a dry run of both and only if both pass start to actually publish each of them? |
You mean when dart is published and flutter fails? |
We could, should not be that hard. |
Note: Currently |
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.
Looks good! I think we can merge this and once we have the other issues fixed just do a test release and see what happens. What do you think?
Sounds good! |
New Pull Request Checklist
Issue Description
Related issue: #668
Approach
This PR approaches Nr.1 of this commit.
I've decided:
Feedback is more then welcome!
TODOs before merging
PUBDEV_GOOGLE_ACCOUNT_ACCESS_TOKEN
andPUBDEV_GOOGLE_ACCOUNT_REFRESH_TOKEN
secrets!- [ ] Add tests- [ ] Add changes to documentation (guides, repository pages, in-code descriptions)- [ ] A changelog entryMaybes:
Edit: Since testing this is almost impossible, it's untested.