Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deploy_maven: Assuming reproducible builds, how about a do-not-fail-if-already-published config option #277

Open
paul-hammant opened this issue Dec 23, 2020 · 2 comments

Comments

@paul-hammant
Copy link

Is your feature request related to a problem? Please describe.

Context: Industry problem of how to keep release branches and CI forcing the maintainer of the release branch to update the version numbers of the modules that have change but not all versions numbers for the set of modules at the same time

Context: Refer: https://paulhammant.com/2018/05/23/examining-ci-cd-and-branching-models/

Context: Assuming reproducible builds ....

If a passing build with a so-configured deploy_maven were to attempt to publish an artifact, it could first check to see whether the artifact (GAV?) had been published already. If it has and the SHA1 for the items are the same, then it could simply pass that build step without uploading the items.

This would be optional. Without do-not-fail-if-already-published=true the build would fail as it does today as the items are already published.

To reiterate:

  1. with do-not-fail-if-already-published=false (or the property is absent) then the build continues to fail if the GAV is published.
  2. with do-not-fail-if-already-published=true then the build passes the GAV is not yet published
  3. with do-not-fail-if-already-published=true then the build passes the GAV is already published and it has the same hashes (the actual upload is silently skipped)
  4. with do-not-fail-if-already-published=true then the build fails the GAV is already published and it has the different hashes

Additional context

Reproducible builds are an industry quest. May companies are not doing Continuous Deployment (yet) and need careful choreography of release branches as they slowly dial up their release cadences over months/years.

If achieved, there's a positive consequence for binary repositories everywhere - all languages & all binary repo idioms. I detail a feature for deploy_maven here, but it equally applies to all deploy_XXX bazel rules. At least were SHA1 /SHA256 hashes are co-located with the items in the binary repo in question.

Caveats

I should never be allowed to name anything, so change do-not-fail-if-already-published to your preferred english expression.

paul-hammant added a commit to TrunkBasedDevelopment/bazel-distribution that referenced this issue Jan 9, 2021
@paul-hammant
Copy link
Author

I've half coded this. Anyone want to pair program with me for tests?

@mgosk
Copy link

mgosk commented Dec 11, 2022

@paul-hammant I don't have solution for your ticket, but I can propose alternative approach.

Instead of looking for artifact SHA1change, you can generate module version as SHA256 of its files.
https://github.com/mgosk/bazel-scala-example/blob/master/tools/version.bzl#L1
If anything changes in modules, version also will change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants