bitrise-io/bitrise-contrib

bitrise-contrib's Issues

Step: re-sign IPA

Use case

create both an AdHock and an AppStore ipa in the same workflow

Right now you have to use multiple Archive steps, using a Script or Schemes to change the code signing settings

With resign it could be as easy as defining the other signing identify / profile

Related UserVoice request, if you'd like to vote: https://bitrise.uservoice.com/forums/235233-general/suggestions/13084962-step-re-sign-ipa

Proxy Step

Hi,

I’m working on a proxy step.
The goal of this step is to be able to analyze the request made by the app during testing.

In order to make this work I will have to build 2 steps one that enable the proxy and one that disable it and extract the log.

The proxy that I will use is Privoxy.

I will need to do a be root to run networksetup in order define a proxy on OSX.
Can I run sudo in a step?

The way that I see the second step is to be able to run multiple regex against the logfile. In order to do that it will be great if the user can add new inputs in the interface, but I don’t know how to make it in step.yml file.

Thanks,

Build Cache [BETA]

Public discussion of the Build Cache (BETA!) feature.

Feel free to add any comment/note, a use case you have, examples which can help others or can help us to further refine the system, etc.

Related DevCenter documentation (work in progress): http://devcenter.bitrise.io/v1.0/docs/using-the-build-cache

On Slack we have a special #beta-build-cache channel dedicated for discussion about the Build Cache.

TODO before general availability

• Bitrise.io : Build Cache API
• Steps to use the Cache: Pull & Push
• CocoaPods Install step: use the --no-repo-update flag of pod if the Cache is available, to automatically skip CocoaPods' repository update ( related issue for the step: bitrise-steplib/steps-cocoapods-install#5 )
• Bitrise.io : "Delete cache" feature
  • should there be a delete cache button/action for every branch separately? Or only a single delete cache button, which removes all the caches of the app? - right now it's per-cache/per-branch, you can find the related "Cache Management" section on the Settings tab of the app, where you can delete the caches one-by-one in the popup
• Bitrise.io : "Download cache" feature, to make it easy to inspect the content of the cache
• Cache setup guides:
  • CocoaPods based project
  • Docker build caching
  • Carthage (link for inspiration: https://github.com/guidomb/carthage_cache)
  • Xamarin Components caching
  • NuGet package caching
  • Fastlane related caching
  • RubyGems related caching
  • ReactNative & NPM caching
  • Android/Linux: gradlew
  • Custom file / dir
  • experiment: DerivedData
  • Full source code cache, git pull
• Add the two Cache Steps to the base configuration (the one generated for new apps)
  • Question: should we include the Cache steps by default in the configurations? It might conflict with the project if the dependency is already included in / committed into the repository.

Integrate with InstallrApp

I suggested it in UserVoice: https://bitrise.uservoice.com/forums/235233-general/suggestions/12886044-add-support-for-uploading-artifacts-to-installr

InstallrApp https://www.installrapp.com/ is a service for distributing iOS and Android builds (similar to HockeyApp and others). They have an API http://help.installrapp.com/api/ and it would be great to be able to push .ipa's and .apk's there as well :)

OS X project type support

Requirements:

Steps

• Xcode Test for OS X project
  • a simple xcodebuild -project $BITRISE_PROJECT_PATH -scheme $BITRISE_SCHEME test is enough
  • xctool does NOT support Xcode 7 UI Tests yet (related issue: facebookarchive/xctool#534) ; normal Unit Tests work with xctool as well
  • @vasarhelyia now published a Mac OS X specific version of Xcode Test step: xcode-test-mac
• Xcode Archive for OS X project
  • the base $BUILD_TOOL -project $BITRISE_PROJECT_PATH -scheme $BITRISE_SCHEME archive call works (which creates the .xcarchive) even with xctool
• Certificate and Provisioning Profile step
  • Certificate can be handled the same way as the https://github.com/bitrise-io/steps-certificate-and-profile-installer step does ; Provisioning Profiles can be handled similarly, but OS X profiles have different extension and have to be stored in a different folder
  • Solved in the PR: https://github.com/bitrise-io/steps-certificate-and-profile-installer/pull/7/files

bitrise.io

• detect OS X projects at project validation
  • actually this is only required to determine which Xcode steps should be added to the base Workflow, does not affect the validation or the other base bitrise.yml steps
• enable accessibility on VMs for Xcode UI test
  • and UI Testing of OS X Apps require OS X El Capitan - we should upgrade the VMs (only Yosemite is available atm)
• Allow to upload OS X App specific Provisioning Profile

Install Cordova (Android projects)

I'm eager to create a step for Cordova installation.

Appropriate request in uservoice: https://bitrise.uservoice.com/forums/235233-general/suggestions/9285630-install-cordova-and-ionic

Integrate with AWS CodeCommit

Support for Infer ?

It's would be great to have the support for Infer.

Collaboration with Spotify
Moving Fast with Software Verification

Cheers,

Step to ZIP a directory and then export the path as an environment variable

Inputs would be the target directory path (to compress) and the path where the zip file should be placed.

Output is an environment variable to that path, although this might not be required as you can provide the zip file path (input) as an env var too.

Sauce Labs Integration #step

Create a Step for Souce Labs - related docs: https://saucelabs.com/mobile/ios-app-testing/selenium-ios

Xcode code coverage stats

Xcode 7 can create code coverage reports. Great, succinct, article on it here.

It would be awesome if Bitrise could display the stats from the Coverage.profdata generated by Xcode, right inline with the test results, in the Build Viewer and in the Dashboard.

The process could look something like this:

Preconditions:
The Xcode Test step has a new checkbox for gather code coverage status (default = ON)

Flow:

1. Xcode Test step is carried out with coverage flag
2. Bitrise analyses Coverage.profdata file created by xcodebuild (could take inspiration from Slather)
3. Bitrise shows coverage percentages with apps in the Dashboard:

1. Bitrise displays more details coverage report in the Build Viewer, containing stats for specific files or perhaps lines etc.
2. Bitrise creates a badge that can be used in READMEs to show coverage percentage

Android : set build number; similar to the Xcode/iOS version

Set the android:versionCode= and maybe android:versionName= in AndroidManifest.xml to the $BITRISE_BUILD_NUMBER env's value.

@jamesmontemagno 's implementation : https://gist.github.com/jamesmontemagno/cb429ecc57716eb6c42f

Xcode/iOS version of the Step: https://github.com/bitrise-io/steps-set-xcode-build-number

Support for CodePush

... would be just great. Especially in combination with using React Native.

http://microsoft.github.io/code-push/

Google Firebase Android testing service step

All technical info can be found here bitrise-io/android#36 (especially: bitrise-io/android#36 (comment) ) and here https://github.com/bitrise-docker/android/issues/35

This could be transformed into a Step.

Integrate with https://appetize.io/

Hi, I think it could be a good idea to have an integration with https://appetize.io/ that provides an API.

Faux Pas App support ?

I am working on it.

mackoj/fauxpasapp-bitrise

Faux Pas App

[Step] "bridge" an environment variable - assign the value of one Step's output to another Environment Variable

Assign the value of one env to another one (Step outputs are just regular Environment Variables)

Ex: if different tools use different envs for the same thing, like ipa path

Something simple like:

#!/bin/bash

set -e

source_env_value="${!source_env_key}"
echo "source_env_key: $source_env_key"
echo "source_env_value: $source_env_value"

echo "=> Mapping $source_env_key to $target_env_key"

set -x

echo -n "$source_env_value" | envman add --key "$target_env_key"