You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Blowdryer supports GitHub, GitLab, and Bitbucket in the following modes: COMMIT, TAG, and optionally TREE. The key property these modes share is that they are immutable. Blowdryer can compute the URL for any of these resources without making a network call, and once it has downloaded that URL, Blowdryer will never need to request it again. Immutable builds are a good practice, they let Blowdryer support fully offline builds, and it's a performance improvement as well.
Rather than basing your build on links to immutable scripts, you could base them instead on mutable scripts, e.g.
The advantage of this would be that as the scripts in master improved, all of the builds which rely on them will also improve. But the downside is that your builds will no longer be reproducible. If you check out an old commit, the scripts at blowdryer-acme branch master might have changed, and so the build results will change. This will make it very difficult to track down regressions, because you can't tell if the changes came from the repo you're looking at, or from the repo you're pointing to from blowdryer.
build = f(repo) is easy to work with. Pointing to a mutable branch changes that to build = f(repo, current_time)
But I want to do it anyway
I am pretty sure this is a bad idea, but if you want to do it, I am happy to merge a PR which adds support for mutable branches. If you make such a PR, it should be implemented roughly along these lines:
publicclassBlowdryerSetup {
..
publicenumGitAnchorType { TAG, COMMIT, TREE } // no new branch modepublicclassGitHub {
Stringanchor;
GitAnchorTypeanchorType;
...
publicGitHubbranchBuildNotReproducible(Stringbranch) {
anchorType = GitAnchorType.COMMIT;
anchor = networkRequestLookupCommitSha(branch);
returnthis;
}
}
Basically, if you want to bring mutability into blowdryer, it should all be resolved within the blowdryerSetup block, so that the mutability doesn't ripple throughout the system.
The text was updated successfully, but these errors were encountered:
Blowdryer supports GitHub, GitLab, and Bitbucket in the following modes:
COMMIT
,TAG
, and optionallyTREE
. The key property these modes share is that they are immutable. Blowdryer can compute the URL for any of these resources without making a network call, and once it has downloaded that URL, Blowdryer will never need to request it again. Immutable builds are a good practice, they let Blowdryer support fully offline builds, and it's a performance improvement as well.Rather than basing your build on links to immutable scripts, you could base them instead on mutable scripts, e.g.
The advantage of this would be that as the scripts in
master
improved, all of the builds which rely on them will also improve. But the downside is that your builds will no longer be reproducible. If you check out an old commit, the scripts atblowdryer-acme
branchmaster
might have changed, and so the build results will change. This will make it very difficult to track down regressions, because you can't tell if the changes came from the repo you're looking at, or from the repo you're pointing to from blowdryer.build = f(repo)
is easy to work with. Pointing to a mutable branch changes that tobuild = f(repo, current_time)
But I want to do it anyway
I am pretty sure this is a bad idea, but if you want to do it, I am happy to merge a PR which adds support for mutable branches. If you make such a PR, it should be implemented roughly along these lines:
And the usage would be
Basically, if you want to bring mutability into blowdryer, it should all be resolved within the
blowdryerSetup
block, so that the mutability doesn't ripple throughout the system.The text was updated successfully, but these errors were encountered: