Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set up CI #2

Open
jlndnn opened this issue Dec 18, 2020 · 3 comments
Open

Set up CI #2

jlndnn opened this issue Dec 18, 2020 · 3 comments
Assignees
Labels
good first issue Good for newcomers help wanted Extra attention is needed

Comments

@jlndnn
Copy link
Member

jlndnn commented Dec 18, 2020

Once we have figured out the local build process, we need to convert this to CI. As part of our org plan we get some free Github actions minutes per month - might be worth looking into.

@gdryke
Copy link

gdryke commented Mar 11, 2021

I think I've got some basics going here, at least the build! No tests yet really, right?

https://github.com/gdryke/focus-launcher-android/runs/2083445901?check_suite_focus=true

EDIT: ahh, failed as I saved this, but it's building! And I was able to build locally too...

@jlndnn
Copy link
Member Author

jlndnn commented Mar 17, 2021

Yes that's right, I haven't seen any tests so far. Build works fine for me locally too, will take a look at your CI yml, seems fine apart from the gradle step so hopefully it's something small 🤔

@tyler-dane tyler-dane linked a pull request Jul 19, 2021 that will close this issue
@tyler-dane tyler-dane added the good first issue Good for newcomers label Jul 19, 2021
@tyler-dane tyler-dane added the help wanted Extra attention is needed label Aug 5, 2021
@zed13 zed13 self-assigned this Aug 7, 2021
@zed13
Copy link

zed13 commented Aug 7, 2021

I propose new scheme for releases. There is three num version X.Y.Z:

  1. X - major releases for some significant changes
  2. Y - one or few feature release with bugfixes.
  3. Z - bugfix or hotfix.

There is different ways of branching. But I propose the following.

Use three kinds of branches:

  1. master branch - here we collect feature PRs and bugfixes for next release
  2. hotfix branch - is used when it's required to fix and publish something without release
  3. feature/bugfix branch - it used for every feature and bugfix. could be nested

At start of each release new version is set up in gradle build script and with PR (or without) master change it's version. In general it will looks like 1.0.10 -> 1.1.0.
All following PR's with new features and bugfixes should be targeted to master. When all required PR's merget to master we starts stabilization of master - testing and bugfixing.
When master is stabilized somebody marks last commit in master with tag release_X.Y.Z and builds artifact for Google Play.
When some critical bugs leaked to user we could make hotfix. Create hotfix branch from release tag of active release. Make required fixes. Test them. Publish hotfix to Google play. And don't forget to merge hotfix changes to master.

There is versionCode parameter for every app. It required by system and Gogole Play. You can't install app with the lower version code than versionCode of app which is installed on device. I propose to generate versionCode automatically. For some reason version code is integer number so the max value is limited by Java Integer.MAX_VALUE. The format for version code would be YYMMDDHHMM. Where:

  1. YY - current year last two digits
  2. MM - current month 1..12
  3. DD - day of month
  4. HH - hour of build
  5. MM - minutes of build.
    The date and time should be in UTC+0 to prevent issues for developers from different regions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants