FINERACT-2421: Rework Github Actions workflow

[adamsaghy]

Description

This PR is trying to improve on multiple ways of our CI execution:

• Having a common action to setup and build Fineract -> action.yml

• Reusing this common setup and build across Fineract -> Building a workspace and upload as artifact is reverted till further investigation around restrictions / limitations and costs. Alongside i would like to compare execution times, usage metrics between the two approaches.

• Uploading and archiving artifacts (logs) only if workflow job fails. In case of success, these are not relevant anymore -> No need to upload and store them

• Retention days to be reduced to 1 day: More than enough to evaluate logs, no need to further collect and store them

• Compression level to be increased, even the used artifact storages should be minimal -> Consideration for users who are running Fineract CI on private repo or their own runner.

• Timeout: Increased timeout to ensure, even if the job is queued for a longer time, still fit into the timeframe

• Limiting branches to be used to execute full CI -> By default only develop (later main) and releases and tags to be considered

• Adding concurrency group and cancel prior execution in case a CI execution is triggered on a newer version of the code changes / PR

chat

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• Write the commit message as per our guidelines
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow our coding conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• This PR must not be a "code dump". Large changes can be made in a branch, with assistance. Ask for help on the developer mailing list.

Your assigned reviewer(s) will follow our guidelines for code reviews.

[Aman-Mittal]

@adamsaghy try rebasing now.

[meonkeys]

Looks fine, I guess? I'd also appreciate a brief explanation of the changes.

[meonkeys]

Please provide a brief explanation of the changes.

[adamsaghy]

Please provide a brief explanation of the changes.

Updated the description. Thank you for reminding me!

Thanks for adding description.

[meonkeys]

LGTM, but I don't have much experience with github actions. I do a lot of local builds.

[Aman-Mittal]

@adamsaghy I think we can also allow upload logs in case of release ready branches. What do you think on that? While on PR we can only upload failure logs but release ready branches i think it would be great practice to keep logs on that.

[adamsaghy]

@adamsaghy I think we can also allow upload logs in case of release ready branches. What do you think on that? While on PR we can only upload failure logs but release ready branches i think it would be great practice to keep logs on that.

I am not sure, i am following you on this one.

[Aman-Mittal]

@adamsaghy I think we can also allow upload logs in case of release ready branches. What do you think on that? While on PR we can only upload failure logs but release ready branches i think it would be great practice to keep logs on that.

I am not sure, i am following you on this one.

My reasoning behind this is that. from what i know that will be used by many forks and organizations so it will be beneficial for us in that case if something gone wrong in code despite passing checks and e2e.

Sometimes keeping this logs comes handy if there is any logical bugs or any undetected regressions later on. Or for rollback anything lateron.

I am not blocking this PR but for observability we need to rethink that.

[adamsaghy]

@adamsaghy I think we can also allow upload logs in case of release ready branches. What do you think on that? While on PR we can only upload failure logs but release ready branches i think it would be great practice to keep logs on that.

I am not sure, i am following you on this one.

My reasoning behind this is that. from what i know that will be used by many forks and organizations so it will be beneficial for us in that case if something gone wrong in code despite passing checks and e2e.

Sometimes keeping this logs comes handy if there is any logical bugs or any undetected regressions later on. Or for rollback anything lateron.

I am not blocking this PR but for observability we need to rethink that.

I dont think we did or used the logs for that ever...

Logical bugs: lead to bugfixes, but you wont be able to identify by going through the "green" tests...
Undetected regressions: same applies
Rollback: not sure how it matters...

The rule of thumb we were following so far: always go ahead.
In short, if something got broken and easy to fix: we fixed with a follow-up bug ticket, if not straightforward, we reversed to latest green build.