Skip to content
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

Support publishing #45

Open
mattyclarkson opened this issue Oct 10, 2018 · 3 comments
Open

Support publishing #45

mattyclarkson opened this issue Oct 10, 2018 · 3 comments
Labels
feature A new feature request
Milestone

Comments

@mattyclarkson
Copy link

Description of the feature

During the publish step the plugin could automatically perform a expo-cli publish. It would only do this if the environment was correctly verified during verifyConditions

Motivation

It would be really handy to have builds published automatically to Expo as part of the semantic-release workflow.

Additional context

It would be really cool if you could add rules to determine the channel that the release is published to. Not really sure how we could do that. There is semantic-release/semantic-release#563 for supporting channels for NPM packages, so would probably make sense to wait for that to be resolved before we figured out what to do for channels.

For now we could just specify which channel to publish to in the configuration. It could publish by default to the default channel (duh) but it would most likely best if it published to alpha. Then you can manually change the channel for specific version with expo-cli publish:set -p <id> -c <beta|production>.

I happy to do the leg work getting this feature together if you're keen for it. Currently using this plugin in https://github.com/ef-carbon/react-native-demo

@mattyclarkson
Copy link
Author

Braindump: Reading the Publishing documentation there are certain keys that require a rebuild of the native side. It might be a stretch goal for this to automatically kick of an actual build or warning or something when an native build is required.

@byCedric
Copy link
Owner

byCedric commented Oct 10, 2018

Hi Matt! Great feature request! Let's get this in 😄 And thanks for the link where you use it, it's always fun to see it in action. 👍

Ok, so let's break it down into multiple steps. First, we need to add the expo publish part right? I would recommend splitting the release channel part into a separate feature request. This way we can manage it a bit easier and, if necessary, wait on the semantic release channels. Thanks for the link, that sure looks damn interesting! 😄

How do you feel about this?

  1. Verify conditions step runs expo doctor combined with expo whoami. This should not only validate your project but also check if the current environment may push to Expo.

  2. Publish step will build and publish your project with expo publish. I guess we should also implement some configuration about what platforms needs to be built. (mixed up publish and build, my bad) And, of course, the release channels! But let's get a working version first.

If you want to get some work done already, feel free to do so! I'll try to make some time available too for this. I can't tell when yet, but I'll keep you posted!

Again, thanks for the awesome suggestion! ❤️

@byCedric byCedric added the feature A new feature request label Oct 10, 2018
@mattyclarkson
Copy link
Author

Adding expo doctor in the verifyConditions totally makes sense, forgot about that command: haven't ran that for a while.

I was thinking the verifyConditions could do expo login -u $EXPO_USERNAME -p $EXPO_PASSWORD if those two environment variables were available. They can then be added as secret CI keys.

On board with adding the stretch goals later, the MVP for this is essentially run expo publish as part of the semantic-release publish step (plus the necessary verifyConditions to support that)

@byCedric byCedric added this to the 3.0.0 milestone Dec 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature A new feature request
Projects
None yet
Development

No branches or pull requests

2 participants