Flutter Automated CI/CD for Android and iOS build does not upload artifacts

[anshgoyalevil]

Is your feature request related to a problem? Please describe.
We have a pull-request.yml workflow file in Talawa Repository, which runs Automated workflow for Android & iOS Builds. These builds are generated inside the Linux OS of Workflow Cluster, but are not uploaded to the GitHub for public release.

What does that mean?
We are already building flutter project in push-request.yml workflow and generating outputs (Like an android apk file, for example) and those outputs cannot be accessed by a user.

This would help others in getting a ready to use Talawa Mobile App File without even setting up flutter in their local machine.

Describe the solution you'd like
The GitHub supports actions/upload-artifact@v1 and v2 for uploading such files to the Repo.

Describe alternatives you've considered
There is no alternative.

Approach to be followed (optional)
The upload-artifact action can be used.
A sample APK file for Talawa App generated from the Workflow (https://github.com/anshgoyalevil/talawa/actions/runs/4350792962) is (https://github.com/anshgoyalevil/talawa/suites/11393074152/artifacts/586480489)

Additional context
This would create a huge impact for those who want to quickly test out the application in their devices, even if they don't know any programming language.

*More over, we can put the stable artifacts to GitHub Release, and assign versions to them. This would keep things working for users, even with breaking changes in some of the PRs

[anshgoyalevil]

@palisadoes

Could you please take a look at this important issue. If relevant, please assign it to me.

[SiddheshKukade]

Hey @anshgoyalevil ,
I don't think we should put out the artifacts just yet as our application is not ready.
Even for testing the new users have to create their own server instance to check the application working. So they have to do the setup anyways for the API.

But if we consider it to do I think then we should also deploy artifacts for the API as well and match them with semantic versioning to make sure that an xyz version of API works with xyz version of talawa app. As both the codebase keep on changing over the time.

What is your opinion?

@palisadoes sir, if this is valid idea, I would be interested to do that for the talawa-api generating artifacts for both linux/OSX and windows.

Please let me know if any issue to be created regarding this on the API.

[anshgoyalevil]

@SiddheshKukade

The idea of artifacts in Talawa Mobile Project would be beneficial for Talawa Api and Talawa Admin users.

There, developers need to test a lot of things, like if an image is working in mobile app or not, or if anything is breaking and issue needs to be created on mobile project or not.

They need to setup the flutter environment, install jdk, and what not, just to run the app

With the introduction of artifacts, they can simply install the apk on their device, and test out the api as well as admin projects.

For artifacts of Talawa Api project, I think that too would be beneficial for Talawa Mobile users, but it would become very hard to maintain the release sync. Since the projects are currently in development stage, things are changing rapidly, and re-releasing Api version everyday would be hard, if not automated.

Just a suggestion, we can also create docker images for the api project, to ease out setting of developer environments.

[SiddheshKukade]

There is already docker implementation for the API and Admin.

[palisadoes]

@anshgoyalevil We tried docker, but there was a great majority of mentors who felt that the CPU overhead was too high especially for developers who may have lower powered laptops. We are working on a Bazel / Nix solution to address the ease of installation problem

[anshgoyalevil]

@palisadoes

I too felt that docker consumes a lot of memory.

And that is the biggest reason why I suggest adding upload artifact CI/CD to the push-workflow.yml file.

API and Admin Developers need to install flutter, jdk, android sdk, and what not, just to test their changes in mobile app.

Having a build file ready to be used, will save hours of developers.

---

Moreover, we are already building the project inside the workflow. You may checkout the workflow file, and see there. Wouldn't it be amazing, if we make use of those builds to get their result output, i.e., build apks.

[palisadoes]

I get the general idea, but this is not my forte. Mentors please comment on this:

• @tonythegr8
• @noman2002
• @DMills27
• @TheHazeEffect

[thesakshidiggikar]

Hi , Can you please let us know about where I can find community link for The Palisadoes Foundation for Gsoc?

[anshgoyalevil]

@thesakshidiggikar

https://join.slack.com/t/thepalisadoes-dyb6419/shared_invite/zt-1py4w5v1s-MgayaMqlfnvxWiHpWb2sFg

[palisadoes]

Hi , Can you please let us know about where I can find community link for The Palisadoes Foundation for Gsoc?

It's regularly updated on the README.md file of the Talawa GitHub page. Just visit this link and search for slack

• https://github.com/PalisadoesFoundation/talawa

[anshgoyalevil]

@tonythegr8
@noman2002
@DMills27
@TheHazeEffect

Mentors please give your suggestions over this issue.

It would greatly help the Talawa Admin and Api Developers.

[DMills27]

I am in agreement that this issue is needed, however, as Siddhesh mentioned the app is currently too tightly coupled at the moment and if we do this, it would require a significant amount of work for not much reward.

The method I'd use to go about doing this is to first create a testing and development environment for Talawa that doesn't require the MongoDB connection string, or GraphQL URL to get in to the app. This can be done using flutter flavours or with a branching strategy, etc. Then we can focus on the CI/CD pipeline. This upshot of this is that it would allow users to get a feel of the app without having to setup the codebase, and can thus be used to identify issues much more quickly.

[noman2002]

I agree with @SiddheshKukade that the app not ready yet for the artifacts. We should wait for while to get the app perfectly functional then we can proceed with this. And I also I agree with Dominic for the flutter flavor thing.

[palisadoes]

Closing. This would be a good GSoC 2024 idea.