Context cleaning - Better specs - Better speration of concerns - Pom generation #12
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
This way the api has a way to generate a context based on git state and have a bumped context in one place.
Before this commit, the api would merge default values for every operation in the `metav.api/make-context`. In an effort to separate the context generation based on git state from the different operations metav implements, the merging of default values for each operation is done in the operations themselves.
The way metav operations worked before was expecting the base context to be well formed and verify only the specific option for the given operation. Now each operation also checks keys of the base context using the new specs defined in `metav.domain.context`.
- We no longer use a global spec to check the options used in the cli since each operation checks what concerns it. - Added error handling using the checks in the CLI by catching exception and using exception msg as CLI exit msg. - Added a test verifying the proper handling of an error while reading a config file.
It makes for a more readable context.
Easier debugging.
Following the idea of « de-complecting » the different parts of metav.
Since the release operation as been exploded internaly into sub-operations, it made sense to move the default tag signing behaviour into `metav.domain.git-operations` and rename the config key :metav.release/without-sign to :metav.git/without-sign.
…ration. - Also added some docs to the `metav.domain.context` functions - changed the « dummy-deps.edn » to be readable by the tools.deps reader. - changing the « dummy-deps.edn » file warranted a change in the tests in how this file is copied into the generated test repos. - removed the `metav.domain/check-committed?` from the `:metav.domain.git-operations/tag-repo!-param` spec and put the check directly inside the function `metav.domain.git-operations/tag-repo!`. Having the check in the spec created a bug.
…the project’s utils ns.
JeremS
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Hey Jérémie,
I changed some things that I found I had not done as well as I could and that go along with the conversation we're having here.
Context cleaning
Right now metav, automatically adds to the execution context default values for every operations inside the
metav.api/make-contextfunction. It's a shortcut I had taken that doesn't satisfy me. If we want to keep the different aspects of metav separated, having spit or release default values in the context when we just want to do:is not ideal.
The changes I am proposing take care of that by putting the responsibility of merging default values on the operations themselves.
This way
metav.api/make-contextadds to its options only the keys it cares about.More specs
I created specs to verify that a context is well formed. It's used in the operations themselves. With these changes, operations will check that the context passed to them not only satisfies specs specific to their own options but also satisfies a common context spec.
Also I revised the way the context validation is made in the operations. Right now
spec/assertis used and isn't turned on by default. However the way these assertions are used in metav feel mandatory to me. I changed these assertions to use a check function mimicking spec's assert but being always turned on.Separation of concerns
Also with idea of metav doing 3 main things, versionning, spitting metadata and git synchronization I have tried to separate each of of these concerns in the code into function that compose cleanly. There still are the 3 operations display, spit! and release! but in the case of release the code has been rework to be a succession of more mono-purpose functions. The parts that now constitute the release function have been pulled into the api.
Pom.xml generation
I have added the option to generate a pom.xml file based on what is already available from clojure.tools.deps. It actually uses the sync-pom function from tools deps then goes to the generated/updated pom and adds the group-id, artefact-name and version based on what metav already establishes.
I'd like to know what you think of these changes.
Cheers,
Jeremy.