feat: allow ability to set working directory of go app

[wilsonjord]

Allows use of hybrid repos where the go application may be in a different directory from the project root.

Main idea is the introduction of a working-directory input, which has a default value of .. This default value results in the same behaviour as currently seen, that is, the go application is in the project root.

This working-directory can be changed and passed through to the relevant reusable workflows, and utilities.

The working-directory functionality is based on golangci-lint-action functionality (https://github.com/golangci/golangci-lint-action/tree/3cfe3a4abbb849e10058ce4af15d205b6da42804?tab=readme-ov-file#how-to-use)

Rationale: some repos have a monorepo structure, containing several projects of mixed languages (for example the docker-gamit repo, with a golang applications and bash applications). The ability to specify worker-directory for golang-specific workflows, allows for a monorepo structure like the following:

docker-gamit
    - go-app
    - bash-scripts

Layouts like this ensure that one project (say, bash-scripts containing .-prefixed application files), are not treated as part of a go application, and vice versa.

[ardrigh]

We should have discussion about why this is needed before it's added across everything

[wilsonjord]

@ardrigh I have added a rationale to the description. If this isn't sufficient, let me know the best way to discuss, if it's a meeting, or Slack discussion etc.

[wilsonjord]

Just checking on the status of this review

[ardrigh]

I think we should cover this at the App Support meeting this afternoon

[ardrigh]

Allows use of hybrid repos where the go application may be in a different directory from the project root.

Main idea is the introduction of a working-directory input, which has a default value of .. This default value results in the same behaviour as currently seen, that is, the go application is in the project root.

This working-directory can be changed and passed through to the relevant reusable workflows, and utilities.

The working-directory functionality is based on golangci-lint-action functionality (https://github.com/golangci/golangci-lint-action/tree/3cfe3a4abbb849e10058ce4af15d205b6da42804?tab=readme-ov-file#how-to-use)

Rationale: some repos have a monorepo structure, containing several projects of mixed languages (for example the docker-gamit repo, with a golang applications and bash applications). The ability to specify worker-directory for golang-specific workflows, allows for a monorepo structure like the following:

docker-gamit
    - go-app
    - bash-scripts

Layouts like this ensure that one project (say, bash-scripts containing .-prefixed application files), are not treated as part of a go application, and vice versa.

This is more an argument for splitting the Go components into a separate repo.

We are no longer limited on the number of GitHub repos we have, we don't need to stay within the constraints that was the reason for hybrid repos to be created.

The reasoning for splitting the Go code into a separate repo is in https://github.com/GeoNet/docker-gamit/pull/219

[ardrigh]

After the discussion at the App Support meeting today, waiting for @quiffman or @sue-h-gns to organise a new meeting/forum to discuss these types of changes, and looking at improvements to repo setups.

[Mossman1215]

between app support meeting and the linked ticket I will close this PR as un merged
future action is to clearly communicate repository standards for layout and CI & CD