Giter Site home page Giter Site logo

semantic-release-expo's Introduction

Expo - Semantic Release

Latest Release Build Status Codecov coverage Code Climate grade

An Expo implementation for semantic release, so you don't have to bother.

Example

How it works

Semantic release will first determine a new version based on your likings. This plugin will then search for your Expo manifest(s) and update it accordingly. Not only will this update the version property within the manifest. It will also update the Android versionCode and iOS buildNumber platform too, based on the configuration.

Verify Conditions

Before such a smooth, carefree release can take place, the plugin must validate the existence of a manifest. This check takes place in the verify condition step of semantic release. The name of the Expo app, defined in the name property, is dumped to console to provide some feedback for successful validation.

Prepare

This plugin writes the actual changes to the manifest during preparation. After this step, you can publish to Expo, create a new build or add the changes in a release commit. The version property within the manifest is always updated. All of the platform specific changes are only applied when the platform is enabled.

It is highly recommended to add the Expo manifest (app.json) to the list of assets to include in the release commit.

Usage

Here is an example configuration with automated changelogs, package.json versions, Expo and git release commits.

{
    "verifyConditions": [
        "semantic-release-expo",
        "@semantic-release/changelog",
        "@semantic-release/git",
        "@semantic-release/npm"
    ],
    "prepare": [
        "semantic-release-expo",
        "@semantic-release/changelog",
        "@semantic-release/npm",
        {
            "path": "@semantic-release/git",
            "assets": [
                "CHANGELOG.md",
                "package.json",
                "package-lock.json",
                "app.json"
            ]
        }
    ],
    "publish": false,
    "success": false,
    "fail": false
}

Configuration

By default this plugin uses configuration that should work straight out of the box. Unfortunately, all apps are different and sometimes requires a specific release flow. To satisfy these needs, you can customize some of these settings below.

Multiple manifests

Normally, an Expo app should have a single manifest located at /app.json. But you might have good reasons to use non-standard or multiple manifests. For example, if you need to create multiple versions/flavours and allow then to work side-by-side, you need multiple manifests. To configure this plugin, you can provide a list of manifests to update.

{
    "prepare": [
        {
            "path": "semantic-release-expo",
            "manifests": [
                "app.test.json",
                "app.staging.json",
                "app.production.json",
            ]
        }
    ]
}

manifests accepts either a single string, or a list of strings.

Version templates

Unfortunately, right now there is no "universal" versioning which can be used across all platforms. For exmaple, iOS can simply use the exact semantic version (e.g. 2.5.1) but Android can't. To allow multiple "tactics" or personal favorites, you can change the so called "versioning templates". These templates uses lodash template to build new versions. Every version string, version, Android versionCode and iOS buildNumber can be modified independently.

{
    "prepare": [
        {
            "path": "semantic-release-expo",
            "versions": {
                "version": "${next.raw}",
                "android": "${code}",
                "ios": "${next.raw}"
            }
        }
    ]
}

versions accepts either a single string for all versions, or a (partial) object with templates. By default the ${recommended} template is used.

Version templates variables

Currently the following variables are available within the templates.

name type description
expo SemVer The semver-coerced Expo SDK version
last SemVer The semver-coerced last release version
next SemVer The semver coerced next release version
code Number The (Android) version code, using the versioning approach by Maxi Rosson
increment Number An incremented number of the previous version, discouraged because of non-deterministic behaviour.
recommended String or Number differs per versioning/platform, listed below
Recommended per version type
version example description
version 1.2.3 The "raw" next release version (also available in ${next.raw})
Android versionCode 290010203 The versioning approach by Maxi Rosson (same as ${code})
iOS buildNumber 1.2.3 The "raw" next release version (also available in ${next.raw})

In these examples Expo SDK 29.x.x and SemVer 1.2.3 is used.

License

The MIT License (MIT). Please see License File for more information.


with ❀️ byCedric & Contributors

semantic-release-expo's People

Contributors

bycedric avatar dependabot-preview[bot] avatar greenkeeper[bot] avatar jaulz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

semantic-release-expo's Issues

An in-range update of codecov is breaking the build 🚨

The devDependency codecov was updated from 3.2.0 to 3.3.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

codecov is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • βœ… codecov/project: No report found to compare against (Details).
  • βœ… codecov/patch: Coverage not affected. (Details).
  • ❌ Travis CI - Branch: The build errored.

Release Notes for v3.3.0

Added pipe --pipe, -l

Commits

The new version differs by 21 commits.

  • d81c4f4 Merge pull request #111 from TomSputz/pipe
  • aa5a2b0 feat(services): add Cirrus CI (#117)
  • 00d484b v3.2.0
  • ad51194 Satisfy ESLint configuration
  • 5f2d0e6 Fixed path to npm bin folder
  • afcf3e5 Fixed merge conflicts
  • 145cb46 updated PR with changes from upstream
  • 2b2ad02 merge package-lock.json from upstream
  • bf0c751 added documentation
  • 9445f72 fixed wrong fixture file names
  • 348cf7b lock dependencies
  • fbf17d2 remove timer because slow CI servers need more than half a second before data is flowing - switch to use --pipe or -l as signal to codecov to recieve data via stdin
  • b145b19 Merge branch 'master' into pipe
  • d460065 check if the stale state was due to using the data event instead of the readable event
  • e8ca9ed be very explicit about exiting process and clearing timeout

There are 21 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @types/jest is breaking the build 🚨

The devDependency @types/jest was updated from 24.0.9 to 24.0.10.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • βœ… codecov/project: No report found to compare against (Details).
  • βœ… codecov/patch: Coverage not affected. (Details).
  • ❌ Travis CI - Branch: The build failed.

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Readme Feedback

Topic and scope of discussion

Documentation

Motivation

This will help make the project more accessible to new users

Additional context

This is a mostly subjective post.

I would love to use this project, but have found it difficult to find some useful information in the readme. Below are some suggestions/ requests for information to be added to the readme.

  • An Installation section would be helpful. Is this package intended to be installed globally or as a dev-dependency? A simple npm i -g semantic-release-expo or npm i semantic-release-expo snippet would save people time.
  • The Usage section includes some kind of configuration file, but doesn't mention any associated name. What is this file called?
  • A Getting started section would be very awesome. Something that outlines the basic steps for incrementing versions/ building. Example:
    1. Install npm i semantic-release-expo
    2. Update .exporeleaserc (or whatever the config file is named) with versioning preferences:
    3. expo:build
    4. πŸ’°
{
    "prepare": [
        {
            "versions": {
                "version": "${next.raw}",
                "android": "${code}",
                "ios": "${next.raw}"
            }
        }
    ]
} 

*edit premature submit πŸ˜“

An in-range update of ts-jest is breaking the build 🚨

The devDependency ts-jest was updated from 24.0.0 to 24.0.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

ts-jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

Commits

The new version differs by 23 commits.

  • b43b3c1 chore(release): 24.0.1
  • 2d91a37 chore: update package-lock
  • 485d3f7 build(deps): bump semver from 5.6.0 to 5.7.0 (#1043)
  • 2bd2534 build(deps-dev): bump @types/node from 10.14.3 to 10.14.4 (#1041)
  • bdba560 build(deps-dev): bump @types/node from 10.14.2 to 10.14.3 (#1038)
  • 08766bf build(deps-dev): bump @types/node from 10.14.1 to 10.14.2 (#1036)
  • 5f92fd2 build(deps-dev): bump js-yaml from 3.12.2 to 3.13.0 (#1034)
  • a9c79e9 build(deps-dev): bump @types/yargs from 12.0.9 to 12.0.10 (#1032)
  • 245ab29 build(deps-dev): bump eslint from 5.15.2 to 5.15.3 (#1031)
  • 4e72e59 build(deps-dev): bump eslint from 5.15.1 to 5.15.2 (#1030)
  • fb7dd55 feat(config): specify package.json location (#823) (#1013)
  • 279edcd build(deps-dev): bump tslint from 5.13.1 to 5.14.0 (#1028)
  • 8b93228 build(deps-dev): bump @types/node from 10.12.30 to 10.14.1 (#1027)
  • b825c7f build(deps-dev): bump @types/lodash.memoize from 4.1.4 to 4.1.6 (#1014)
  • 6f0ab80 build(deps-dev): bump @types/lodash.merge from 4.6.5 to 4.6.6 (#1015)

There are 23 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @commitlint/travis-cli is breaking the build 🚨

The devDependency @commitlint/travis-cli was updated from 7.5.0 to 7.5.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@commitlint/travis-cli is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

add support for app.config.js manifest

Apparently this plugin only caters for app.json manifest format?
I am using app.config.js in order to use the extra manifest field. So it would be nice to have this supported.

A workaround is to inherit the version from package.json if using so and under app.config.js have:

import * as pkg from './package.json'

export default {
  name: 'my app',
  version: pkg.version
};

However, I'm not completely clear on whether this semantic-version plugin runs other actions which are useful, besides updating the version on the manifest?

Add Android/iOS version number configuration

Detailed description

Right now there is no way to customize a versionCode (Android) or buildNumber (iOS). Android will be increased with 1 and iOS will use the exact version name, just like the normal version. I'd figure some people want to customize this. It should work a bit like the build-in tag/version functionality. The only still-unsolved-thing is the build numbers from Android. There is currently no way of detecting the exact build number (integer).

An in-range update of @types/fs-extra is breaking the build 🚨

The devDependency @types/fs-extra was updated from 5.0.4 to 5.0.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/fs-extra is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Error: Cannot find module '@semantic-release/error'

Get this error when running Github Actions:

Error: Cannot find module '@semantic-release/error'
Require stack:
- /home/runner/work/chargeport-emp/chargeport-emp/node_modules/semantic-release-expo/build/src/scripts/prepare.js
- /home/runner/work/chargeport-emp/chargeport-emp/node_modules/semantic-release-expo/build/src/index.js
- /home/runner/.npm/_npx/2106/lib/node_modules/semantic-release/lib/plugins/utils.js
- /home/runner/.npm/_npx/2106/lib/node_modules/semantic-release/lib/plugins/index.js
- /home/runner/.npm/_npx/2106/lib/node_modules/semantic-release/lib/get-config.js
- /home/runner/.npm/_npx/2106/lib/node_modules/semantic-release/index.js
- /home/runner/.npm/_npx/2106/lib/node_modules/semantic-release/cli.js
- /home/runner/.npm/_npx/2106/lib/node_modules/semantic-release/bin/semantic-release.js
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:889:15)
    at Function.Module._load (internal/modules/cjs/loader.js:745:27)
    at Module.require (internal/modules/cjs/loader.js:961:19)
    at require (internal/modules/cjs/helpers.js:92:18)
    at Object.<anonymous> (/home/runner/work/chargeport-emp/chargeport-emp/node_modules/semantic-release-expo/build/src/scripts/prepare.js:18:30)
    at Module._compile (internal/modules/cjs/loader.js:1072:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)
    at Module.load (internal/modules/cjs/loader.js:937:32)
    at Function.Module._load (internal/modules/cjs/loader.js:778:12)
    at Module.require (internal/modules/cjs/loader.js:961:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/home/runner/work/chargeport-emp/chargeport-emp/node_modules/semantic-release-expo/build/src/scripts/prepare.js',
    '/home/runner/work/chargeport-emp/chargeport-emp/node_modules/semantic-release-expo/build/src/index.js',
    '/home/runner/.npm/_npx/2106/lib/node_modules/semantic-release/lib/plugins/utils.js',
    '/home/runner/.npm/_npx/2106/lib/node_modules/semantic-release/lib/plugins/index.js',
    '/home/runner/.npm/_npx/2106/lib/node_modules/semantic-release/lib/get-config.js',
    '/home/runner/.npm/_npx/2106/lib/node_modules/semantic-release/index.js',
    '/home/runner/.npm/_npx/2106/lib/node_modules/semantic-release/cli.js',
    '/home/runner/.npm/_npx/2106/lib/node_modules/semantic-release/bin/semantic-release.js'
  ]
}

release.config.js

module.exports = {
  branches: [{ name: 'main' }, { name: 'beta', prerelease: true }],
  plugins: [
    '@semantic-release/commit-analyzer',
    '@semantic-release/release-notes-generator',
    'semantic-release-expo',
    '@semantic-release/changelog',
    '@semantic-release/npm',
    '@semantic-release/github',
    [
      '@semantic-release/git',
      {
        message: 'chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}',
        assets: ['CHANGELOG.md', 'package.json', 'package-lock.json', 'app.config.js'],
      },
    ],
  ],
};

Plugin overwrites keys outside of `expo`

Hi!

I want to use this plugin together with react-native-google-mobile-ads. It is necessary to include additional configuration outside expo key as stated here: https://docs.page/invertase/react-native-google-mobile-ads#setting-up-google-admob

{
  "expo": {
    "name": "test-name",
    "version": "1.0.0",
  },
  "react-native-google-mobile-ads": {
    "android_app_id": "ca-app-pub-xxxxxx~xxxxxx"
  }
}

But when plugin executes, it deletes react-native-google-mobile-ads key.

Is there a way to preserve that configuration?

An in-range update of ts-jest is breaking the build 🚨

Version 23.1.0 of ts-jest was just published.

Branch Build failing 🚨
Dependency ts-jest
Current Version 23.0.1
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

ts-jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).
  • ❌ Travis CI - Branch: The build failed.

Commits

The new version differs by 39 commits.

  • 6916e7b Merge pull request #650 from kulshekhar/kulshekhar-patch-1
  • 54a30eb Bump the version (minor)
  • 9e61969 Merge pull request #626 from huafu/feature/upgrade-babel-and-fix-tsconfig
  • ef21f50 Merge branch 'master' into feature/upgrade-babel-and-fix-tsconfig
  • c67ba4d Merge pull request #649 from kulshekhar/greenkeeper/monorepo.react-16.4.2
  • 9a6904f Merge branch 'master' of https://github.com/kulshekhar/ts-jest into feature/upgrade-babel-and-fix-tsconfig
  • 8a94008 chore(package): update react-test-renderer to version 16.4.2
  • 6e73fb9 chore(package): update react to version 16.4.2
  • c947791 chore(package): update @types/node to version 10.5.5 (#646)
  • fd24ae6 Merge pull request #640 from jmheik/to-dev-deps
  • e2028da Merge branch 'master' into to-dev-deps
  • 4396dde Merge pull request #641 from jeznag/patch-1
  • 7d78123 Merge branch 'master' into patch-1
  • b38e4ca Add TypeScript ^3.0.0 as supported peer dependencies (#644)
  • 1e287f3 Add more details on using module name mapper

There are 39 commits in total.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @types/fs-extra is breaking the build 🚨

Version 5.0.3 of @types/fs-extra was just published.

Branch Build failing 🚨
Dependency @types/fs-extra
Current Version 5.0.2
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

@types/fs-extra is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push The Travis CI build failed Details

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @types/node is breaking the build 🚨

The devDependency @types/node was updated from 11.13.3 to 11.13.4.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @commitlint/travis-cli is breaking the build 🚨

The devDependency @commitlint/travis-cli was updated from 7.2.1 to 7.3.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@commitlint/travis-cli is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

[Android]: "recommended" strategy defaults versionCode to 0

@byCedric , great work with this plugin!

.releaserc

  "prepare": [
    {
      "path": "semantic-release-expo",
      "manifests": ["app.json"]
    },

log

[5:10:30 PM] [semantic-release] [semantic-release-expo] β€Ί β„Ή Expo manifest version changed (1.0.3 => 1.1.0) in app.json
[5:10:30 PM] [semantic-release] [semantic-release-expo] β€Ί β„Ή Expo manifest android version changed (1 => 0) in app.json
[5:10:30 PM] [semantic-release] [semantic-release-expo] β€Ί β„Ή Expo manifest ios version changed (1.0.3 => 1.1.0) in app.json

as you can see while app.json version and ios version are getting the right value, android is getting version code 0

Invalid iOS buildNumber on alpha/beta releases

Hi Cedric,

I've just detected that when publishing a new release to an alpha branch, semantic release by default creates a version tag like 1.0.0-alpha.3 and semantic-release-expo copies that tag to the expo.version and expo.ios.buildNumber fields in App.json.

However, trying to publish an Expo project with a buildNumber lie that throws an error:

[19:44:04] Error: Problem validating fields in app.json. See https://docs.expo.io/versions/v35.0.0/workflow/configuration/
 [19:44:04]  β€’ Field: ios.buildNumber - 'ios.buildNumber' should match pattern "^[A-Za-z0-9\.]+$".

The referred Expo documetation refers to an Apple developer doc explaining that the accepted form for a buildNumber like this should be something like 1.0.0a3

What would you suggest?

Changing the semantic-release-expo prepare.versions.ios lodash template? (my knowledge of lodash templates is close to none, could you suggest one?)

Changing the semantic-release tagFormat?

I would greatly appreciate your opinion/support on this.

An in-range update of semantic-release is breaking the build 🚨

Version 15.9.1 of semantic-release was just published.

Branch Build failing 🚨
Dependency semantic-release
Current Version 15.9.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

semantic-release is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).
  • ❌ Travis CI - Branch: The build failed.

Release Notes v15.9.1

15.9.1 (2018-07-30)

Bug Fixes

  • clarify EPLUGINCONF error message (d8c84a0)
Commits

The new version differs by 3 commits.

  • b2d82c2 docs: specify for each step if one or more plugins are required/allowed
  • 31ec1eb docs: fix configuration doc syntax
  • d8c84a0 fix: clarify EPLUGINCONF error message

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Add linting

Detailed description

TypeScript is a great language, it helps you prevent certain mistakes you something make accidentally. But I think this project could also benefit from some extra linting. The commit messages (commitlint) can be linted, as well as the project code itself (tslint/eslint). Even put the npm audit in the travis pipeline wouldn't hurt anyone I think...

An in-range update of codecov is breaking the build 🚨

The devDependency codecov was updated from 3.1.0 to 3.2.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

codecov is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

Commits

The new version differs by 3 commits.

  • e427d90 feat(services): add azure pipelines (#114)
  • 023d204 Use small HTTP dependency (#110)
  • 500f308 Update Readme

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @commitlint/travis-cli is breaking the build 🚨

The devDependency @commitlint/travis-cli was updated from 7.5.1 to 7.5.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@commitlint/travis-cli is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

Commits

The new version differs by 3 commits.

  • d0507bd v7.5.2
  • 48a8602 fix: failing sentence-case for subjects with slashes (#574)
  • 4075903 fix(cli): replace old links with new organisation links (#578)

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Update (readme) documentation

Detailed description

The available "life cycle methods" of semantic release should be documented for this plugin. As well as all customization plugin settings and personally I would like an example too.

Support multiple manifests

Detailed description

Sometimes you need multiple manifest, each set for a different environment. When deploying through CI you can then copy one of the presets, based on the current branch, to the location of the actual manifest. With this you have easy multiple builds/environment support.

Unfortunately, right now this isn't supported. This plugin only updates a single manifest. It would benefit everyone if multiple manifest locations can be configured.

An in-range update of @types/node is breaking the build 🚨

Version 10.5.0 of @types/node was just published.

Branch Build failing 🚨
Dependency @types/node
Current Version 10.3.6
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @types/jest is breaking the build 🚨

The devDependency @types/jest was updated from 24.0.6 to 24.0.7.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

android.versionCode - should be integer

Description of the bug

When I try to build the application via Expo, I see this error:

Field: android.versionCode - should be integer.

To Reproduce

Unfortunately, I cannot tell in detail now.

Expected behavior

The version should be dumped as integer.

Actual behavior

The version is dumped as a string:
image

Additional context

Might be cause by upgrade to Expo v30? Or maybe from the new template mechanism? But actually I only see tests where the version code is supposed to be an integer.

An in-range update of @types/node is breaking the build 🚨

Version 10.5.4 of @types/node was just published.

Branch Build failing 🚨
Dependency @types/node
Current Version 10.5.3
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).
  • ❌ Travis CI - Branch: The build failed.

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @types/node is breaking the build 🚨

The devDependency @types/node was updated from 11.10.4 to 11.10.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details
  • βœ… codecov/project: No report found to compare against (Details).
  • βœ… codecov/patch: Coverage not affected. (Details).
  • ❌ Travis CI - Branch: The build failed.

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @peakfijn/config-commitlint is breaking the build 🚨

The devDependency @peakfijn/config-commitlint was updated from 1.0.0-rc.3 to 1.0.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@peakfijn/config-commitlint is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

An in-range update of @types/node is breaking the build 🚨

The devDependency @types/node was updated from 10.12.21 to 10.12.22.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Support publishing

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

An in-range update of @types/lodash is breaking the build 🚨

The dependency @types/lodash was updated from 4.14.120 to 4.14.121.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/lodash is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.