This article covers all the Github Actions that we used for our project management.
TL;DR: Auto Tagging using Github Action.
Since our monolith project structure takes an average of 15 mins to build a single process, we decided to adopt the modularization structure to break down our project into various modules to speed up our build and simplify deployment. We decided to split up our modules of the project in the following ways:
- Interface Module: It contains only interfaces (protocols in swift) that help to organize Feature/Tab modules on Container Module for creating a new flavored app.
- Authentication Module: It contains login/SignUp related information.
- Session Module: It contains information about the User login sessions.
- Container Module: It acts as a base project.
- Tab Modules: It contains information about tabs available in the project)
- More Module: It contains information about extra features available in the project.
- Profile Module: This module contains information about configurable user profiles
Since Interface Module was used as a separate repository, all updates were pushed here. As a team, we need to ensure that a tag must be provided for each push to indicate its purpose. We need to create a manual tag for each push. Creating manual tags has its limit and is a tiring process. So we opted for an alternative way called Auto-Tagging. Auto-Tagging saves you the work of manually tagging every final URL and eliminates the errors you can introduce when you attempt to manually tag each URL.
Why is Bitrise CI/CD not amicable ?
We use Bitrise (CI/CD) in the main project to perform the following:
- Unit Testing
- Archiving
- Appstore Deployment
- Tagging
- Creating Release Notes
- Collecting SonarQube CodeCoverage
- Fastlane integration for other internal processes.
We should perform integration from scratch to use Bitrise for simple tagging on the Interface Module. So we decided to adopt Github Action which yields good results.
Github action helps you to meet the unique needs of your application.
On merging the pull requests successfully, Github will trigger an action to create a new tag.
Setup can be done by adding PAT (Personal AccessToken) under module repository secrets.
#Tag
Any commit message that includes major
, minor
, and path
will trigger the respective version bump. If more than one tag is available for commit, the highest-ranking one will take precedence. If there is no tag available in a commit message, then the system automatically patches to the default dump configured for the project. For example:
- #Major: 1.0.0
- #Minor: 0.1.0
- #Patch: 0.0.1 (default bump)
In the above example, if there is no tag in a commit message, the system automatically patches with the #Patch: 0.0.1 (Default dump confio]guredfpr the project)
#Custom_tag
Sometimes we need a user-friendly tag to differentiate the business logic. We can use CUSTOM_TAG to invalidate other settings.
Skip pull requests and push workflows
Github Actions allows you to skip push and pull request workflows. You can search for the following keywords to skip those operations: [skip ci], [ci skip], [no ci], [skip actions], or [actions skip].
DRY RUN
You can use this feature to test the workflow of the project without a tag. Adding VERBOSE with this feature helps you to understand much better.
DEBUG = DRY RUN + VERBOSE
Xcode 13 + Source Control
Creating Pull Requests in Xcode 13 is a turkey shoot. We shall see more on this in the upcoming article.
That’s it for this time! Feel free to comment if you have questions and follow to get notifications about future articles.
“Be the senior engineer you needed as a junior.” — Someone
👏👏👏👏👏👏👏