Inconsistent SHA1 between deployment/logsearch-deployment.yml and bosh.io

[mymasse]

We just started using the deployment/logsearch-deployment.yml manifest and noticed that the SHA1 for the release is not the same as the one from bosh.io. The same goes for the logsearch-for-cloudfoundry release. We have a pipeline that pulls all required release from bosh.io and transfers these files to our air-gapped network. However I now need to add an ops file to modify the SHA. Wondering why the releases are different and which one should be use: the one from the manifest of the one from bosh.io?

[axelaris]

Hi @mymasse. When we cut a release, we build the tarball locally, then put it into S3 bucket. You can find a link to tarball in the manifest, together with SHA sum. As for bosh.io, they has it own scripts to build all releases. They build the release by they own, so SHA1 is differ. You can use whatever release you like.

[mymasse]

OK, weird didn't think bosh.io was building releases, Just looked at the bosh.io/releases repo and what do you they do build the release, so the different sha would be caused by maybe un-committed changes? So I guess nothing to worry

[mymasse]

So I think I found the difference, downloading from bosh.io I get logsearch-boshrelease-<version>.tgz and from your this repo I get logsearch-<version>tgz. Wouldn't that explain the difference in SHA1 (since the tar file in the tgz uses a diferrent name). I think bosh.io builds the release using the repo name, hence the boshrelease part in the name. To minimize confusion should the one you build be change to match the same name?

[axelaris]

I don't think so, because filename is not part of the file itself, so shouldn't affect SHA sum.

[mymasse]

But the tgz contains a tar called logsearch-version.tar, so wouldn't the tgz sha1 be affected by it

[axelaris]

logsearch-for-cloudfoundry tarball has the same name as on bosh.io, but SHA sum is differ :-(