metadata/message about original *code* commit

[jessesuen]

When we make commit messages, we should somehow include git message of the actual code change. This can avoid situations like the following (our current hacky way):

[krancour]

@jessesuen I have a question about the emphasis on code in the title...

As it stands now, k8sta (just like Argo CD) doesn't interact with your source code repositories at all and only deals with config/deployment repos.

Am I misunderstanding the title?

[jessesuen]

The title is intentional. My point about our current approach is not helpful enough and having a more information incorporated into the gitops repo to indicate the actual change, would save users time.

We have a few techniques of getting the information:

1. Part of the assumptions we will have is that we incorporate references to the original code repo (e.g. the -80b2859 in 00638-80b2859). So we always have the option of looking up the original code repo for the title associated witht the hash:
2. When the initial commit is made to the gitops repo for the image tag, e.g. when we watch for the docker push, we could perform the lookup at that time and incorporate metadata in the form of git notes or the git message itself. This metadata will continue to get propagated as the image is moved through environments.

[krancour]

The title is intentional.

I suspected it was.

My point about our current approach is not helpful enough and having a more information incorporated into the gitops repo to indicate the actual change, would save users time.

Agree 100%. I just have way more questions than answers atm, but between the two of us and @alexmt, I'm sure we'll manage to answer them.

For the sake of discussion:

(e.g. the -80b2859 in 00638-80b2859)

1. If a ticket is created because this image was pushed, it's easy to recognize the 80b2859 as a sha that correlates to a commit ID in the source code repo, but what isn't clear is which source code repo(s). I'm not sure where that info comes from unless we ask users to provide it in their track definitions. There could also be multiple images involved in a single gitops repo, and those multiple images might have their source in multiple repos. Do we ask the user to map it all out for us? "This image repo maps to this source code repo?" In many cases they'd have to supply creds also. Today, users don't have to supply creds of any kind (K8sTA gleans creds for gitops repos from Argo CD, but Argo CD doesn't have creds for source code repos). It seems doable, but this also seems like it's asking a lot of the users, so I just want to work through how this impacts the overall experience. What if we do something like making this level of configuration optional and if a user provides it, we can give them better commit messages?

2. Do we really want to insist users adhere to this tagging scheme? It feels strange to say that we can't accommodate semantic versioning.

   1. Related: What about users who are deploying images they don't control and they have no say over the tagging scheme? Imagine I have a gitops repo with a bunch of manifests for running a publicly available image like Wordpress.

3. Not all changes would necessarily be triggered by a new image. Non-exhaustive examples:

   1. Changes to env var values or networking options (for instance) in the gitops repo don't necessarily map back to source code change at all. If they do, we don't have any way of inferring which.

   2. Subscribing to an image repo is probably basic usage. It's easy to imagine scenarios where it won't work out well -- for instance, a monorepo that pushes multiple images upon release and all of those are referenced by the gitops repo. You wouldn't want to start migrating changes after the first of n images hits its repo. You'd want to wait for all n. We don't support this yet, but we might want to consider using a webhook or something so that a user's release process can explicitly signal k8sta that a release has occurred and all n new images are ready. Actually... in this case, the webhook's body could contain a lot of useful information, which probably makes this one of the easier cases to deal with.

   Edit: ☝️ Thinking about it more, I actually think that is so generally useful that I'd like to develop some support for (inbound) webhooks sooner rather than later if you agree. It would provide a better foundation for continuing to work on this issue. See #96.

4. Edit: The 80b2859 in 00638-80b2859 points to a single commit, but the sum total of the changes between this image and the previous might include changes from many commits. How would we surface all of that?

I don't expect you to have answers at the ready for all of these. This is all just food for thought. We can riff on these questions and ideas in our Thursday touchpoint.

[jessesuen]

What if we do something like making this level of configuration optional and if a user provides it, we can give them better commit messages?

Do we really want to insist users adhere to this tagging scheme? It feels strange to say that we can't accommodate semantic versioning.

No you're right. We will provide opinionated flow that will work best with the tooling, but we should absolutely accommodate semantic versioning. They will just miss out on features such as this one and get a generic "upgraded to 1.0.3" message, which is probably good enough since semantic releases have well defined release payloads (compared to continuous CI/CD of SaaS).

[krancour]

Great point that semantic versions, by nature, already have rich info.

[github-actions[bot]]

This issue has been automatically marked as stale because it had no activity for 90 days. It will be closed if no activity occurs in the next 30 days but can be reopened if it becomes relevant again.

[highb]

At my org, I've implemented a github action called action-promote, that adds metadata to the promotion commit into our deployment repos. I do find this information useful because there are many places that images could be promoted from and being able to trace back to the code repo in an unambiguous way has come in helpful several times for me. As an example of the sort of info that I include, here's an anonymized commit description generated by my action.

---
GITHUB_EVENT_NAME: push
GITHUB_JOB: promote
GITHUB_REF_URL: https://github.com/org/repo/tree/refs/heads/master
GITHUB_REF: refs/heads/master
GITHUB_REPOSITORY_URL: https://github.com/org/repo
GITHUB_REPOSITORY: org/repo
GITHUB_RUN_ID: 123456789
GITHUB_RUN_NUMBER: 1234
GITHUB_SHA_URL: https://github.com/org/repo/commit/59247d97e98b7b80086185ea8af39639fcc5ee9c
GITHUB_SHA: 59247d97e98b7b80086185ea8af39639fcc5ee9c
GITHUB_WORKFLOW_RUN_URL: https://github.com/org/repo/actions/runs/123456789
IMAGES: dockerhuborg/my-service
CHARTS:
OVERLAYS: env/my-service/integration
MANIFEST_JSON: {"env/my-service/integration":{"images":[{"name":"dockerhuborg/my-service","newName":"12345.dkr.ecr.us-west-2.amazonaws.com/dockerhuborg/my-service","newTag":"sha-59247d97e98b7b80086185ea8af39639fcc5ee9c"}]}}

Obviously, the GH workflow specific URL info isn't useful in Kargo but perhaps a link back to the Kargo event that started the promotion would be? I do think that having an integration with the underlying app code repo would be extremely helpful for devs to easily trace back to their code changes, regardless of if the image is tagged with a sha or SemVer.

[github-actions[bot]]

This issue has been automatically marked as stale because it had no activity for 90 days. It will be closed if no activity occurs in the next 30 days but can be reopened if it becomes relevant again.