This repository has been archived by the owner on Nov 1, 2022. It is now read-only.
Ensure generated template modtime is Unix epoch #2473
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hiddeco
force-pushed
the
build/modtime-unix-epoch
branch
from
ce2ba3a
to
27ed447
Compare
stefanprodan
approved these changes
Sep 24, 2019
vsfgen which we use for maintaining an embedded copy of our templates does also include the modtime of the files. This poses a problem in combination with git, as in a project managed by git the modtime of a file depends on the time it was changed through a local git action (e.g. a checkout from a different state which results in a file write on disk) instead of the time of the actual change. This commit adds a wrapper around `http.FileSystem` that modifies the file mod times to always return Unix epoch. So that the only things resulting in a new `generated_template.gogen.go` are folder and/or file content changes.
hiddeco
force-pushed
the
build/modtime-unix-epoch
branch
from
27ed447
to
5ae91c6
Compare
|
Nice, thanks!!! |
squaremo
added a commit
that referenced
this pull request
Oct 17, 2019
For `fluxctl install`, we embed a set of templates in the fluxctl binary by generating a fake filesystem as Go code (pkg/install/generated_templates.gogen.go). But the code that generates the fake filesystem also _depends_ on the fake filesystem, since it does double duty as a program for generating example manifests from those templates. This leads to a problem: if anything has upset the generation process, it's not possible to regenerate the files, since the generation tool won't build. A related problem, worked around elsewhere (#2473), is that it's easy to introduce spurious differences in the generated code -- which, since it's checked in -- means painful merges. In general we don't care about the generated Go code, only about what it produces. This commit removes it from git and from the uncommitted change detection (`make check-generated`); and uses `fluxctl install` to generate the example files, removing the need for the code generating program to depend on the code it's generating.
squaremo
added a commit
that referenced
this pull request
Oct 17, 2019
For `fluxctl install`, we embed a set of templates in the fluxctl binary by generating a fake filesystem as Go code (pkg/install/generated_templates.gogen.go). But the code that generates the fake filesystem also _depends_ on the fake filesystem, since it does double duty as a program for generating example manifests from those templates. This leads to a problem: if anything has upset the generation process, it's not possible to regenerate the files, since the generation tool won't build. A related problem, worked around elsewhere (#2473), is that it's easy to introduce spurious differences in the generated code -- which, since it's checked in -- means painful merges. In general we don't care about the generated Go code, only about what it produces. This commit removes it from git and from the uncommitted change detection (`make check-generated`); and uses `fluxctl install` to generate the example files, removing the need for the code generating program to depend on the code it's generating.
squaremo
added a commit
that referenced
this pull request
Oct 17, 2019
For `fluxctl install`, we embed a set of templates in the fluxctl binary by generating a fake filesystem as Go code (pkg/install/generated_templates.gogen.go). But the code that generates the fake filesystem also _depends_ on the fake filesystem, since it does double duty as a program for generating example manifests from those templates. This leads to a problem: if anything has upset the generation process, it's not possible to regenerate the files, since the generation tool won't build. A related problem, worked around elsewhere (#2473), is that it's easy to introduce spurious differences in the generated code -- which, since it's checked in -- means painful merges. In general we don't care about the generated Go code, only about what it produces. This commit removes it from git and from the uncommitted change detection (`make check-generated`); and uses `fluxctl install` to generate the example files, removing the need for the code generating program to depend on the code it's generating.
squaremo
added a commit
that referenced
this pull request
Oct 17, 2019
For `fluxctl install`, we embed a set of templates in the fluxctl binary by generating a fake filesystem as Go code (pkg/install/generated_templates.gogen.go). But the code that generates the fake filesystem also _depends_ on the fake filesystem, since it does double duty as a program for generating example manifests from those templates. This leads to a problem: if anything has upset the generation process, it's not possible to regenerate the files, since the generation tool won't build. A related problem, worked around elsewhere (#2473), is that it's easy to introduce spurious differences in the generated code -- which, since it's checked in -- means painful merges. In general we don't care about the generated Go code, only about what it produces. This commit removes the generated file from the "uncommitted change" detection (`make check-generated`); and uses `fluxctl install` to generate the example files, removing the need for the code generating program to depend on the code it's generating. NB It's still necessary to commit the generated code, since other projects depend on the install package.
squaremo
added a commit
that referenced
this pull request
Oct 17, 2019
For `fluxctl install`, we embed a set of templates in the fluxctl binary by generating a fake filesystem as Go code (pkg/install/generated_templates.gogen.go). But the code that generates the fake filesystem also _depends_ on the fake filesystem, since it does double duty as a program for generating example manifests from those templates. This leads to a problem: if anything has upset the generation process, it's not possible to regenerate the files, since the generation tool won't build. A related problem, worked around elsewhere (#2473), is that it's easy to introduce spurious differences in the generated code -- which, since it's checked in -- means painful merges. In general we don't care about the generated Go code, only about what it produces. This commit removes the generated file from the "uncommitted change" detection (`make check-generated`); and uses `fluxctl install` to generate the example files, removing the need for the code generating program to depend on the code it's generating. NB It's still necessary to commit the generated code, since other projects depend on the install package.
squaremo
added a commit
that referenced
this pull request
Oct 21, 2019
For `fluxctl install`, we embed a set of templates in the fluxctl binary by generating a fake filesystem as Go code (pkg/install/generated_templates.gogen.go). But the code that generates the fake filesystem also _depends_ on the fake filesystem, since it does double duty as a program for generating example manifests from those templates. This leads to a problem: if anything has upset the generation process, it's not possible to regenerate the files, since the generation tool won't build. (A related problem, worked around elsewhere (#2473), is that it's easy to introduce spurious differences in the generated code -- which, since it's checked in -- means painful merges. The solution there still works here.) In general we don't care about the generated Go code, only about what it produces. This commit removes the generated file from the "uncommitted change" detection (`make check-generated`); and uses `fluxctl install` to generate the example files, removing the need for the code generating program to depend on the code it's generating. NB It's still necessary to commit the generated code, since other projects depend on the install package.
squaremo
added a commit
that referenced
this pull request
Oct 21, 2019
For `fluxctl install`, we embed a set of templates in the fluxctl binary by generating a fake filesystem as Go code (pkg/install/generated_templates.gogen.go). But the code that generates the fake filesystem also _depends_ on the fake filesystem, since it does double duty as a program for generating example manifests from those templates. This leads to a problem: if anything has upset the generation process, it's not possible to regenerate the files, since the generation tool won't build. (A related problem, worked around elsewhere (#2473), is that it's easy to introduce spurious differences in the generated code -- which, since it's checked in -- means painful merges. The solution there still works here.) In general we don't care about the generated Go code, only about what it produces. This commit removes the generated file from the "uncommitted change" detection (`make check-generated`); and uses `fluxctl install` to generate the example files, removing the need for the code generating program to depend on the code it's generating. NB It's still necessary to commit the generated code, since other projects depend on the install package.
mpashka
pushed a commit
to pulsepointinc/flux
that referenced
this pull request
Oct 24, 2019
For `fluxctl install`, we embed a set of templates in the fluxctl binary by generating a fake filesystem as Go code (pkg/install/generated_templates.gogen.go). But the code that generates the fake filesystem also _depends_ on the fake filesystem, since it does double duty as a program for generating example manifests from those templates. This leads to a problem: if anything has upset the generation process, it's not possible to regenerate the files, since the generation tool won't build. (A related problem, worked around elsewhere (fluxcd#2473), is that it's easy to introduce spurious differences in the generated code -- which, since it's checked in -- means painful merges. The solution there still works here.) In general we don't care about the generated Go code, only about what it produces. This commit removes the generated file from the "uncommitted change" detection (`make check-generated`); and uses `fluxctl install` to generate the example files, removing the need for the code generating program to depend on the code it's generating. NB It's still necessary to commit the generated code, since other projects depend on the install package.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
vsfgen which we use for maintaining an embedded copy of our templates
does also include the modtime of the files.
This poses a problem in combination with git, as in a project managed
by git the modtime of a file depends on the time it was changed
through a local git action (e.g. a checkout from a different state
which results in a file write on disk) instead of the time of the
actual change.
This commit adds a wrapper around
http.FileSystemthat modifiesthe file mod times to always return Unix epoch. So that the only
things resulting in a new
generated_template.gogen.goare folderand/or file content changes.