How to get TESTING_URI ?
Closed this issue · 4 comments
I am integrating firebase app Distribution system into my bitrise CI/CD
After apk uploaded to firebase app distribution i want to retrieve the TESTING_URI and add it to my env variable.
So that I can send that download url via slack message.
Any way to achieve it ?
@faruk0344 FYI this repo is for a github action to upload artifacts to firebase app distribution. This has nothing to do with bitrise.
If you actually care about the github action and not bitrise it works like this:
- name: Upload artifact to Firebase App Distribution
id: upload-artifact-to-firebase # this id is used in the next step to get the output
uses: wzieba/Firebase-Distribution-Github-Action@v1
with:
appId: ${{secrets.FIREBASE_APP_ID}}
serviceCredentialsFileContent: ${{ secrets.CREDENTIALS_FILE }}
groups: testers
file: file.apk
- name: Print app distribution links
run: |
echo "FIREBASE_CONSOLE_URI: ${{ steps.upload-artifact-to-firebase.outputs.FIREBASE_CONSOLE_URI }}"
echo "TESTING_URI: ${{ steps.upload-artifact-to-firebase.outputs.TESTING_URI }}"
echo "BINARY_DOWNLOAD_URI: ${{ steps.upload-artifact-to-firebase.outputs.BINARY_DOWNLOAD_URI }}"
Hi @addyi
I made my work inspired from guness/bitrise-step-firebase-app-distribution#67
Yes but this is for Bitrise not for GithubActions these are two different CI they don't have anything to do with each other.
Bitrise CI and GitHub Actions are both continuous integration (CI) platforms, but they are separate tools and operate independently from one another.
Bitrise CI is a third-party platform primarily focused on mobile app development (iOS, Android, etc.). It provides pre-built workflows and integrations tailored to mobile pipelines, including support for running tests, building apps, and even deploying them. Bitrise has its own interface, tooling, and configuration (through
bitrise.yml
) and is often chosen by mobile developers for its ease of use and extensive app-specific integrations.GitHub Actions, on the other hand, is a built-in CI/CD platform within GitHub itself. It allows you to create automated workflows directly in your GitHub repositories for various tasks like testing, building, and deploying code. You define these workflows using
.yml
files within the repo.So, while both tools help automate CI/CD processes, they operate separately and are often used for different purposes. They share no direct connection.