restechnica / semverbot Goto Github PK

Is there an option to require to be on a specific branch when creating a release?

For example I would like to be able to configure so that,
It would require that a user would only be able to make releases from the main/master branch

Thanks, great tool!

Versions are not detected correctly in pipelines. Upon further investigation the sbot update version only run git fetch --unshallow, while it also needs git fetch --tags.

A solution would be to also include git fetch --tags.

Some of the github actions used are pretty old versions (actions/checkout@v2, actions/setup-go@v2) and could use some of the extra features of the new versions, like caching go.mod

Repo steps:

1. Make commit with the following commit message:

My work.
[release]

2. Run sbot predict version, output:

% sbot predict version
Error: failed to detect mode from git commit message "My work.
" with delimiters "[]"
Usage:
  sbot predict version [flags]

Flags:
  -h, --help          help for version
  -m, --mode string   sbot mode (default "auto")

Global Flags:
  -c, --config string   configures which config file to use (default ".semverbot.toml")

Success case:

1. Make commit with the following commit message: My work. [release].
2. Run sbot predict version, output: 1.0.0

Context:

I have the below dockerfile on an M1 mac:

FROM node:16
ARG SEMVERBOT_VERSION=1.1.0
# install sbot 
RUN curl -o /usr/local/bin/sbot https://github.com/restechnica/semverbot/releases/download/v$SEMVERBOT_VERSION/sbot-linux-amd64 && \
    chmod +x /usr/local/bin/sbot

CMD ["/bin/bash"]

I build the image with the command docker build . --tag testimage
We enter it via docker run --user 0 -it testimage /bin/bash

Behaviour:

Running the command sbot --help renders the following output:
qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory

Expected behaviour:

sbot --help should output the help options

Temporary solution:

Build the dockerfile using the command: docker build . --tag testimage --platform linux/x86_64
Run the image using the command: docker run --platform linux/x86_64 --user 0 -it testimage /bin/bash
sbot --help now outputs the correct information

Is this by design or a bug in docker or sbot?

We have started with a tagging strategy of using vx.y.z when we started to tag our versions, but at some point switched to not using a v prefix.

I saw #41 and this seems related.

We now have something like
...
10.0.1
10.0.2
10.0.3
v3.0.1
v3.0.2

Running sbot get version returns v3.0.2 while i want to continue on from 10.0.3.
I see that with the changes for 41 it's sorting with git.

Is there a way to pass a command line flag to only look at the last x tags made? Or ignore certain tags with a wildcard?

Just checked that on v1.0.0 i do get 10.0.3. So i could use that version instead of v1.1.0 but maybe a --cli flag would be possible to have both behaviours available in 1 version? Or did i miss this flag?

We are currently using gitversion, which handles this well, but is taking several minutes to calculate the next version in my pipelines, so looking for a more lean and faster alternative. Semverbot looks like a great tool if the above can somehow be managed :)

Situation

We have a repo that has the following tags

1.0.1
1.1.0
2.0.0
2.1.0
PROD

Behaviour

When running

sbot release version
sbot push version

sbot creates a new tag 0.0.1 as the last tag is PROD - This is by design at the moment

Expected behaviour

sbot should ignore the first x amount of non semver tags
when running the same commands the expectation is that sbot creates for example the 2.1.1 tag

Potential fix

Add a --dig / --depth comand line option / config file option that searches further back to find the 'latest' semver tag
This could also become the default in case the oldest tag is non-semver compliant

Example code

To retrive the last 3 tags in git, sorted by 'potential' semver structure you could use

git tag --sort=-version:refname | head -n 3

This would yield the following example output:

2.1.0
2.0.0
1.1.0

'ignoring' the PROD tag.

A solution in pkg/git/cli.go could be:

// GetLastNumberAnnotatedTags gets the last x amount of semver-like tags - default is 5 tags
// Returns the list of git tags and an error if the command fails
func (api CLI) GetLastNumberAnnotatedTags(amount int) (tag string, err error) {
	if amount == 0 {
		amount = 5
	}
	strAmount := strconv.Itoa(amount)
	return api.Commander.Output("git", "tag", "--sort=-version:refname", "|", "head", "-n", strAmount)
}

It looks like the upstream blang/semver module only supports v as a prefix when using ParseTolerant - so any configured prefix in semverbot doesn't appear to work.

// ParseTolerant allows for certain version specifications that do not strictly adhere to semver
// specs to be parsed by this library. It does so by normalizing versions before passing them to
// Parse(). It currently trims spaces, removes a "v" prefix, adds a 0 patch number to versions
// with only major and minor components specified, and removes leading 0s.
func ParseTolerant(s string) (Version, error) {
	s = strings.TrimSpace(s)
	s = strings.TrimPrefix(s, "v")

I wonder if it would good to add to a simple string replacement on the configured prefix to v in https://github.com/restechnica/semverbot/blob/main/pkg/semver/parse.go#L5 as a work around?

I noticed there were no tests covering prefixes either.

Following comments on a introductory Reddit post, people have shown enough interest in the option of generating a semverbot configuration file for the semantic-release specification. It might even be made default.

Topics to investigate:

• should semantic-release be used as default?
• should it be implemented as an option for the init command? e.g. sbot init -t, --template semantic-release

Currently when you predict like: 'SOME_VAR=$(sbot predict version --verbose)' the predicted version is stored in to the variable. Would be great to have a verbose log of it as well with the --verbose flag.

e.g.:

16:28:21 + sbot update version --verbose
16:28:21 14:28:21 INF updating version...
16:28:21 14:28:21 INF fetching unshallow repository...
16:28:21 14:28:21 WRN ignoring failed unshallow fetch for now, repository might already be complete
16:28:21 14:28:21 INF fetching tags...
16:28:22 [Pipeline] sh
16:28:23 + sbot predict version --verbose
16:28:23 14:28:22 INF getting version...
16:28:23 14:28:22 INF 0.3.0
16:28:23 14:28:22 INF predicting version...
16:28:23 14:28:22 WRN falling back to patch mode
16:28:23 [Pipeline] sh
16:28:23 + sbot get version --verbose
16:28:23 14:28:23 INF getting version...
16:28:23 14:28:23 INF 0.3.0
16:28:23 0.3.0

People have posted really good questions on an introductory Reddit post, to the extent that the readme should be cleared up or replaced with a decent wiki. The questions can be compiled into an FAQ.

e.g.

16:04:00 WRN config file not found

These messages are a confusing, they happen when .semverbot.toml is not found, even when .sbot.toml is found afterwards. Possible resolution would be change the level to DEBUG for these messages.

It would be nice that instead of having a dedicated .semverbot.toml file in python repo's, we could add to the existing pyproject.toml file

eg pyproject.toml :

[tool.semverbot]
mode = "auto"

[tool.semverbot.config]
patch = ["fix", "bug"]
minor = ["feature", "feat"]
major = ["release"] 

This would possibly simplify the repo.
Open for suggestions / concerns / ...

semverbot returns exit code '0' even if the underlying git operation fails.

Steps to reproduce:
1 - use "read only" git identity to check out code
2 - run typical semverbot flow
sbot release version
sbot push version

Expected result:
sbot will return an error code to parent shell

Actual result:
sbot returns code '0'

Discussion:
I am using semverbot in CI/CD pipeline (Azure DevOps Pipelines). While working to configure the pipelines, several of my repos did not have the expected permissions to allow the pipeline runner identity to be able to push tags back to the repo. The pipelines did not fail when the sbot push version command failed to actually push the tag back to the repo. Investigating this, I found that the sbot command was returning an exit code of '0' even when the git operation failed.

Currently the golden standard is a .semverbot.toml config file in the root of a project. Let's offer a shorter .sbot.toml as well. Perhaps support not starting the file(s) with a dot. as well.

1. Have a config file like:

mode = "auto"

[git]

#[git.config]
#email = "[email protected]"
#name = "semverbot"

[git.tags]
prefix = "v"

[semver]
patch = ["fix", "bug"]
minor = ["feature"]
major = ["release"]

[modes]

[modes.git-branch]
delimiters = "/"

[modes.git-commit]
delimiters = "[]/"

2. log output:

12:44:19 DBG configuring git...
12:44:19 DBG user.email=
12:44:19 DBG user.name=

it is harmless, as exisiting git config would never be overwritten, but it is confusing. Would be good to make the logs more clear by showing already existing config values and configured values separately. e.g.

12:44:19 DBG configuring git...
12:44:19 DBG user.email [email protected] from-config=
12:44:19 DBG user.name from-git="Email Email" from-config=

Is this something that would be considered for this tool? Would be nice if it aggregated all the changes together and committed it.

These logs/prints are shown due to the git command exit status being different that 0 or the stderr containing bytes when it really shouldn't. Semverbot still works as intended but simply outputs strange logs.

The go Cobra library shows usage whenever an error occurs, even when the error is not due to faulty usage of the CLI. We can fix this with a combination of a logging implementation and using cmd.SilenceUsage = true.

Following comments on a introductory Reddit post, people have shown enough interest in the option of generating a semverbot configuration file for the conventional-commits specification. It might even be made default.

Topics to investigate:

• should semantic-release be used as default?
• should it be implemented as an option for the init command? e.g. sbot init -t, --template conventional-commits

If you leverage goreleaser for the build, github release, homebrew update, and scoop packages can all be done with minimal effort as it's built into that tool.

I suggest Scoop since it's similar to Homebrew, but focused on Windows dev tools.
Would be a nice way to make it more accessible to the different development platforms.

If you want a goreleaser config PR to help jump start just let me know. Be more than willing to help as I get some time.