FINERACT-2421: Use hardened image

[adamsaghy]

Description

Describe the changes made and why they were made. (Ignore if these details are present on the associated Apache Fineract JIRA ticket.)

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]

I am asking this while it is still in Draft, If this gets merged, do i have to maintain my own secrets in my fork repository, to run github workflow integration test. if i raise new PR.

What i actually do, before raising PR, i run the same e2e workflow same as this repository. To make sure PR runs work successfully first time.

[adamsaghy]

I am asking this while it is still in Draft, If this gets merged, do i have to maintain my own secrets in my fork repository, to run github workflow integration test. if i raise new PR.

What i actually do, before raising PR, i run the same e2e workflow same as this repository. To make sure PR runs work successfully first time.

I am just testing the ground, there will be no need for any secret management from contributors side... this will not be merged for a while till all angles are covered and community decision was made: hence draft status

[IOhacker]

@adamsaghy seems that help from Apache Infra is required for setting the credentials for the DHI repository. I think that the README must include some instruction about the DHI credentials required for building/running the dockerized version. Everything else looks good for me.

[adamsaghy]

@adamsaghy seems that help from Apache Infra is required for setting the credentials for the DHI repository. I think that the README must include some instruction about the DHI credentials required for building/running the dockerized version. Everything else looks good for me.

Probably we need dual building. One for PRs and one if something got merged to develop. While the 1st can work on "public" images, the latter can be on hardened images... it's not perfect, but it could work.

[DeathGun44]

Hi @adamsaghy,

I saw your note about needing a 'dual building' strategy to unblock the PR checks for contributors without access to the hardened image secrets.

I've just forked the repo and am prototyping a change to the GitHub Actions workflow to handle this conditional logic (using the public image for PRs vs. hardened for main/develop).

If you aren't already working on this part, I'd love to polish it up and submit a PR to your branch to get these checks passing.

[Aman-Mittal]

Hi @adamsaghy,

I saw your note about needing a 'dual building' strategy to unblock the PR checks for contributors without access to the hardened image secrets.

I've just forked the repo and am prototyping a change to the GitHub Actions workflow to handle this conditional logic (using the public image for PRs vs. hardened for main/develop).

If you aren't already working on this part, I'd love to polish it up and submit a PR to your branch to get these checks passing.

I think Hardened image Must always be run at main upstream protected branch and it must have a check where forked repository do not use hardened images and secret maybe check like this can help

runs-on: ubuntu-latest
steps:
  - uses: actions/checkout@v4

  - name: Detect trusted context
    if: github.event.pull_request.head.repo.fork == false
    run: |
      echo "CI_IMAGE= <context>"

[DeathGun44]

Hi @adamsaghy,
I saw your note about needing a 'dual building' strategy to unblock the PR checks for contributors without access to the hardened image secrets.
I've just forked the repo and am prototyping a change to the GitHub Actions workflow to handle this conditional logic (using the public image for PRs vs. hardened for main/develop).
If you aren't already working on this part, I'd love to polish it up and submit a PR to your branch to get these checks passing.

I think Hardened image Must always be run at main upstream protected branch and it must have a check where forked repository do not use hardened images and secret maybe check like this can help

runs-on: ubuntu-latest
steps:
  - uses: actions/checkout@v4

  - name: Detect trusted context
    if: github.event.pull_request.head.repo.fork == false
    run: |
      echo "CI_IMAGE= <context>"

Thanks. That conditional check looks like the right direction for handling the fork context.