Consider digest pinning for more build stability #67

New Issue

decentral1se · 2021-06-03T09:15:04Z

decentral1se commented

2021-06-03 09:15:04 +00:00

We could be doing something like this in the compose.yml files: node:14.15.1@sha256:d938c1761e3afbae9242848ffbb95b9cc1cb0a24d889f8bd955204d347a7266e where you pin directly to a digest that you expect. This would stop whacky stuff happening later on if upstream decides to cheekily overwrite the tag.

We could be doing something like this in the `compose.yml` files: `node:14.15.1@sha256:d938c1761e3afbae9242848ffbb95b9cc1cb0a24d889f8bd955204d347a7266e` where you pin directly to a digest that you expect. This would stop whacky stuff happening later on if upstream decides to cheekily overwrite the tag.

👀 1

decentral1se added the

enhancement

label 2021-06-03 09:15:18 +00:00

3wordchant commented

2021-06-13 12:35:57 +00:00

Down for this.

Do we know what exactly would happen if we did this, in those situations "if upstream decides to cheekily overwrite the tag"?

Would the deploy just fail (and would we want to / be able to show a more helpful error than Docker?), or will it still grab the old tagged image from Docker Hub?

Down for this. Do we know what exactly would happen if we did this, in those situations "if upstream decides to cheekily overwrite the tag"? Would the deploy just fail (and would we want to / be able to show a more helpful error than Docker?), or will it still grab the old tagged image from Docker Hub?

decentral1se commented

2021-06-14 14:56:50 +00:00

I think it would just error out with "I can't find that tag with that hash" and then yeah, as you say, I think we'd need to provide some explanation after that. We could of coures have a --force logic here to override. This seems a bit tricky to manage to set up, we'd probably have to publish our own test image and then overwrite it? For now, we could just do the pinning and figure out the rest later.

I think it would just error out with "I can't find that tag with that hash" and then yeah, as you say, I think we'd need to provide some explanation after that. We could of coures have a `--force` logic here to override. This seems a bit tricky to manage to set up, we'd probably have to publish our own test image and then overwrite it? For now, we could just do the pinning and figure out the rest later.

decentral1se added this to the Versioning and deploy stability milestone 2021-09-09 14:29:59 +00:00

decentral1se added this to the Beta release (software) project 2021-10-05 10:35:58 +00:00

decentral1se referenced this issue from coop-cloud/abra

2021-10-05 10:36:31 +00:00

feat: teach recipe sync to understand new versions #105

decentral1se commented

2021-10-05 10:39:19 +00:00

Note: coop-cloud/abra#105 (comment)

Should we stick with -${DIGEST} or do this pinning or what is best?

We want to reduce recipe config churn, fit in with what abra wants and use the simplest solution.

Note: https://git.coopcloud.tech/coop-cloud/abra/pulls/105#issuecomment-9177 Should we stick with `-${DIGEST}` or do this pinning or what is best? We want to reduce recipe config churn, fit in with what `abra` wants and use the simplest solution.

decentral1se commented

2021-10-05 11:09:43 +00:00

Before coop-cloud/abra#105 we had:

each service had a label with the tag + digest

After, we have:

only the app service with the tag

How do we guarantee that an update is what it says it is?

When we run abra catalogue generate, we store something like:

"1.0.0+1.14.3-rootless": {
  "1.14.3": {"image": "gitea", "tag": "1.14.3", "digest": "..."},
  ...
}

So here we store the digests. We can add a check there to this generation to ensure that the digest are always the same. And when we deploy something, we can make sure to do a comparison.

So, no recipe config changes + simpler label setup, I think!

Before https://git.coopcloud.tech/coop-cloud/abra/pulls/105 we had: - each service had a label with the tag + digest After, we have: - only the app service with the tag How do we guarantee that an update is what it says it is? When we run `abra catalogue generate`, we store something like: ```json "1.0.0+1.14.3-rootless": { "1.14.3": {"image": "gitea", "tag": "1.14.3", "digest": "..."}, ... } ``` So here we store the digests. We can add a check there to this generation to ensure that the digest are always the same. And when we deploy something, we can make sure to do a comparison. So, no recipe config changes + simpler label setup, I think!

3wordchant commented

2021-10-05 13:05:35 +00:00

This seems good, I guess to make things as Easy™ as the previous workflow we want some kind of helper to look up the hash so we don't need to find it manually?

👍 1

decentral1se removed this from the Beta release (software) project 2021-10-10 22:47:18 +00:00

decentral1se commented

2023-01-18 10:50:37 +00:00

New growing consensus in coop-cloud/recipes-catalogue-json#4 (comment) /cc @3wordchant I think we should 1) remove the digest generation from abra (see #379) and document how to pin specific images in the recipe config. Needs some more research tho.

New growing consensus in https://git.coopcloud.tech/coop-cloud/recipes-catalogue-json/issues/4#issuecomment-14885 /cc @3wordchant I think we should 1) remove the digest generation from `abra` (see https://git.coopcloud.tech/coop-cloud/organising/issues/379) and document how to pin specific images in the recipe config. Needs some more research tho.

~~decentral1se referenced this issue from coop-cloud/recipes-catalogue-json 2023-01-18 10:51:06 +00:00~~

Reinstate automatic catalogue generation #4

decentral1se referenced this issue

2023-01-18 18:09:13 +00:00

Remove digest handling from catalogue generation #379

Sign in to join this conversation.