Decide or document how OCI images should be named

[bendiknesbo]

For a Go application, we need a proper way to create the fully-qualified OCI image name.
The current iteration finds every Go module with an entrypoint, and then generates the following name:
$OCI_IMAGE_BASE/<goModulePath>/<entrypoint-name>.

The documentation lists 2 ways of configuring GitHub Actions:

1. Pre-pallet should specify an oci-image-base like oci-image-base: europe-docker.pkg.dev/helloworld-shared-0918.
2. Repositories created with the system-template from Inventory (using Pallets) should use oci-image-base: ${{ vars.PALLET_REGISTRY_URL }}.
   a. The vars.PALLET_REGISTRY_URL will be populated with a more specific value, like europe-docker.pkg.dev/pallet-helloworld-0918/pallet-helloworld-0918-default

We also have different ways of structuring our source-code: Some applications want to have their Go source-code in a directory traditionally named src, without wanting to have the src as part of the OCI name. Other applications have their source-code in a directory with the same name as the system, and they want this name to be part of the OCI name.

[bendiknesbo]

There are different ways to solve this:

• We can enforce a certain style that will work for pre-pallet repos, and post-pallet repos.
  • This will require teams to make changes to their repository-structure, just to be able to keep using Mage. These changes make rebasing/merging difficult during the migration.
• We can allow dynamic configuration (like omit the source-code path of the go.mod file from the OCI image name)
• We can use a proper system-name as part of the OCI image name, instead of the source-code path of the go.mod file
  • This can be read from multiple places, like a catalog-info.yaml, or from the module-name in go.mod, or from the repository-name
• Allow (by config) to not include the path of the go.mod as part of the OCI image name.
• We can simply document how it currently behaves, and let every team decide how they want to solve it.
  • This includes specifying that both europe-docker.pkg.dev/<gcp-project-id>/<gcp-artifact-registry-repository> and europe-docker.pkg.dev/<gcp-project-id> are valid values for the OCI_IMAGE_BASE, and which consequences this has.

[bendiknesbo]

@AtzeDeVries / @nhhagen, what do you think about adding this kind of configuration-possibility (in addition to extra documentation)?

Allow (by config) to not include the path of the go.mod as part of the OCI image name.

It would allow a pre-pallet repo to still have the source-code in e.g. src, but specify a OCI_IMAGE_BASE like europe-docker.pkg.dev/<gcp-project-id>/<gcp-artifact-registry-repository>

[AtzeDeVries]

I am a bit hesitant with adding extra config options. If require them, that is fine but if we cannot have them it is even better.

I just want to go back to the core on why we are doing it the current way, if this is smart and if what we need in the future. Note first that we want to move more into mono repo, where a system is the scope of the mono repo. This means that we need to support one or more service.

I see the following possible situations.

1. system with one service
2. system with two or more services that share a lot of code
3. system with two or more services that do not share a lot of code
4. a mix of 2 and 3.

for 1 and 2 we currently have this structure for the cmds.

<some root dir> # i am actually not sure now to name this, this is not by def the system name
   go.mod
   cmd/
      serviceA/main.go
      serviceB/main.go

for 3/4 we probably must have something like this

<some root dir> # i am actually not sure now to name this, this is not by def the system name
   go.mod
   cmd/
      serviceA/main.go
      serviceB/main.go
<some other root dir>
   go.mod
   cmd/
      serviceA/main.go

This leads me to the conclusion that to ensure unique OCI's the latter part of the OCI url needs to have
<rootdir>/<serviceName>.

other suggestions on how to structure very welcome.

[AtzeDeVries]

We also want to make magegration nice as well, so i think we should have good advice based on my previous comment.

I would actually suggest begin able to override this <rootdir> to an value that matches with the current repo. To this can be a string, or an empty string. I would like to have this really as an override, not as an config option. To me difference is that a override is a deviation from the default and config option is just a different config.

[bendiknesbo]

magegration
heh, nice!

What are your thoughts on the valid values of OCI_IMAGE_BASE then?
Right now it supports both GCP Artifact Registry with location+project, and location+project+repository.

I guess we should think forward to a time where every repository is a system-pallet monorepo, and then work backwards from there in how we can ease migration to that place. That will also make a non-pallet -> pallet migration easier in the future, if that is something we want to support.

In that case, every consumer should start to input a 3-part OCI_IMAGE_BASE that points to a preexisting repository. And then Mage can use whatever file path it wants inside that repository.

It's worth noting that Artifact Registry allows forwardslashes (/) in the image name, so we can add anything we want inside the repository. E.g. this is a valid OCI name: europe-north1-docker.pkg.dev/sandbox-bendik-august-nes-69db/my-repo/subpath1/subpath2/nginx.

[nhhagen]

Some of the topics were discussed in and might provide some insight, on the other hand time as passed and the context might have changed:

• Compile binaries from Go code #69
• Build OCI images #70

The current implementation is running on both pallet and non-pallet repos that follow the repository structure guidelines. The repository structure guidelines are not yet clear on having a src directory or not, I would opt for not and use the service name.

I'm in the camp of no config here, potentially consuming catalog-info.yaml files to ensure alignment with information in Inventory and Datadog. Given that we have a goal of system level monorepos that all follows the same pattern. When we all follow the same pattern things are easier for both humans and machines.

I like the suggestion of working backwards from the goal and ease migration. Overrides with and end-date and raise warnings want close to the end-data might be a way to go.

In the end the image names are just strings that point to a deployment artefact and is updated by a computer.

[bendiknesbo]

The repository structure guidelines are not yet clear on having a src directory or not, I would opt for not and use the service name.

This is kind of the root of the problem. What do we name the folder for multi-service systems, that share code? (2+ entry points in go)

[nhhagen]

That is correct. Aside from directories with names like src causing fluff in image names are there any technical problems?