* Add checkout --merge-in-base support
When using this option, the checkout will try to merge in the
base branch into each module by running:
`git merge --no-edit origin/<base-branch>`
Retain the unmodified "BaseRevision" info in the Module struct
so it can be used in case it was overwritten by
`applyPullRequestsOverride()`
* only merge base if necessary
* Check if baseRevision is set
Co-authored-by: Bernd Ahlers <bernd@users.noreply.github.com>
---------
Co-authored-by: Bernd Ahlers <bernd@users.noreply.github.com>
* Update cobra and viper to their latest versions
* Start a changelog command
* Start changelog release command
* Add Document360 specific HTML formatter
* Add "new" command to create a new changelog entry
* Hide unfinished changelog release command for now
* Use Go version 1.19
* Update golang.org/x/sys to fix build error
* Clean workspace after each build
* Disable CGO for tests
* Remove wrong git checkout
* Update dependencies
The "assembly" boolean field was used to decide if a module should be
included in the open-source assembly descriptor. The enterprise assembly
descriptor included a hard coded list of plugins and wasn't generated like
the open-source descriptor.
We need to be able to generate the enterprise assembly descriptor as well
because we now have different artifacts in 2.4 and 3.0, for example.
To do this, we introduced the "assemblies" field which contains a list of
assembly descriptor IDs. The open-souce and enterprise assembly descriptor
templates now get a list of modules for a given assembly ID.
// graylog-assembly.xml
{{ range $assembly := index .Assemblies "graylog" }}
// ...
{{ end }}
// graylog-enterprise-assembly.xml
{{ range $assembly := index .Assemblies "graylog-enterprise" }}
// ...
{{ end }}
This makes it possible to configure one or more assemblies for each
module in the manifest. It also allows us to include each module in more
than one assembly.
The CLI tool will emit a warning for manifests which still use the old
"assembly" field.
IntelliJ cannot handle very long relative paths in the "<module>" tag
for some reason so we try to generate a short relative path. This was an
issue when the current working dir is inside a symlink.
