pantheon-systems / autotag Goto Github PK
View Code? Open in Web Editor NEWGit repository version tagging tool
Home Page: http://godoc.org/github.com/pantheon-systems/autotag
License: Apache License 2.0
Git repository version tagging tool
Home Page: http://godoc.org/github.com/pantheon-systems/autotag
License: Apache License 2.0
Hi,
Currently, If I do a go get github.com/pantheon-systems/autotag/autotag
it will fail with this message:
go: found github.com/pantheon-systems/autotag/autotag in github.com/pantheon-systems/autotag v1.3.6
go get: github.com/pantheon-systems/[email protected] requires
github.com/Unknwon/[email protected]: parsing go.mod:
module declares its path as: github.com/unknwon/com
but was required as: github.com/Unknwon/com
This is because replace directives are not honored by go get, and they will probably never will.
Removing the replace directive gives this error:
david$ go mod tidy
go: github.com/Unknwon/[email protected]: parsing go.mod:
module declares its path as: github.com/unknwon/com
but was required as: github.com/Unknwon/com
And this is caused by an old version of git-module which requires package github.com/Unknwon/com
with an uppercase U
.
go: finding module for package github.com/Unknwon/com
go: found github.com/Unknwon/com in github.com/Unknwon/com v1.0.1
go: github.com/pantheon-systems/autotag imports
github.com/gogits/git-module imports
github.com/Unknwon/com: github.com/Unknwon/[email protected]: parsing go.mod:
module declares its path as: github.com/unknwon/com
but was required as: github.com/Unknwon/com
If interested, I have a small PR that brings the github.com/gogs/git-module
(formerly github.com/gogits/git-module) to v0.8.3 and removes the need for a replace directive.
Hi, first of all thanks for this cool project.
I have a somewhat specific usecase where I would need to ignore some tags following a pattern when calculating the next version.
My approach would be to add build metadata to those commits so that they can be ignored later.
Example:
With this git log I would like to be able to run autotag and ignore the commits with meta so the next version in this example would be "v0.1.0".
My idea would be to add a "--ignore" option ("-i" for short) which allows specifying a pattern like "*meta*" to match the tag name against.
What do you think of it, would this be possible?
Thanks in advance :)
(truncating shas)
git rev-parse HEAD
: deac9d...
but:
autotag -v
:
2019/01/09 23:36:39 Opening repo at /volume/repo/.git
2019/01/09 23:36:39 Parsing repository tags
2019/01/09 23:36:39 Checking commits from 3a1901b... to 3a1901b...
2019/01/09 23:36:39 Writing Tag v0.1.10
3a1901b... - is 10 commits old and keeps getting tagged with every new commit to master
We're currently running git-module
version v0.8.3
: https://github.com/pantheon-systems/autotag/blob/master/go.mod#L9
We should update to the latest one (currently it's v1.1.5
): https://github.com/gogs/git-module/releases
Note that this has some breaking changes to the API that we'll need to resolve.
Due to GitHub handle change (to lowercase) for long term purpose, go get
may fail fetching github.com/Unknwon/com
.
Please consider take some time to update it to github.com/unknwon/com
in the go.mod
file.
I truly apology for the inconvenience and unintended troubles caused.
It would be interesting to support other versioning schemes besides SemVer. CalVer (https://calver.org/) comes to mind. Are there others we should consider?
$ autotag -b main -p rc
> v0.0.1-rc
$ autotag -b main -p rc
> 2023/01/26 19:35:00 Error auto updating version: error creating tag: exit status 128 - fatal: tag 'v0.0.1-rc' already exists
In a monorepo containing multiple go modules, versioning of each module is possible using the subdirectory prefix.
This way go get
will use the version specific to the module of the monorepo, if the repo is tagged with the module directory.
Example:
Monorepo:
github.com/sermojohn/go-monorepo-importer
Module 1:
github.com/sermojohn/go-monorepo/mod1
Module 2:
github.com/sermojohn/go-monorepo/mod2
autotag
could be provided with a flag referring to the subdirectory
of a go module in a monorepo, in order to:
This way autotag
can create tags that are compatible with Go modules
.
reference: https://go.dev/ref/mod#vcs-version
We are in need for this feature, so I have capacity to work on it and contribute to autotag, if you think this feature is valuable to this project.
I noticed that everytime I ran autotag
, it adds an incremented tag to the commit, even if that commit already has a semver tag.
Possible to make it check for a semver tag first and skip if one already exists?
Autotag is generally used in CI/CD pipelines. We should see about providing a GitHub Action that makes it as easy as possible to integrate.
Bonus points: Make it easy to combine with goreleaser. Not sure if that means documenting how to combine the autotag GH-action with goreleaser's own GH-action, or adding an optional step that supports goreleaser manually in our GH-action.
When running autotag
in a directory that lacks a ./.git
dir the error message could be better. Example
$ make build
$ cd autotag
$ ./autotag
Error initializing: no such file or directory
At minimum it should mention the directory it can't find.
Issue
Fails to recognize "!" as a breaking change and does not follow Semantic Versioning scheme. Results in MINOR bump instead of MAJOR. Introduced to this issue using the latest release but after further investigation tracked the genesis of the issue to release 1.3.14. The final 2 screenshots show release 1.3.13 working as expected.
To Reproduce
I created a dummy repo and attempted to replicate commits that helped discover the issue in the first place.
Expected Behavior
MAJOR version bump when the commit in question, latest commit, contains "!" in the message indicating a breaking change as in v.1.3.13 and prior.
Screenshots/Logs
In order to replicate I did a series of basic and more complicated commits with different keywords that may trigger a particular versioning rule.
The simple, 1 commit squash and merge PRs seem to be working correct. The commit at the top mimics the squash and merge PR that first introduced the issue. The expectation is that the tag should be 4.0.0, not 3.1.0. The tagging for the git log above was using the latest release of autotag.
Commit parsing in 1.3.14
Commit parsing in 1.3.13
It appears the sequential order of parsing commits in v1.3.14 is reverse that of v1.3.13, potentially making the versioning bump not use the latest commit?
System
macOS using latest release as the introduction to bug
Similar to #41 but for CircleCI using the Orb system.
You're building our golang app in desbian and you copy it in alpine.
You need to build it in alpine if you want to expose a alpine image
FROM golang:alpine AS autotag
ARG AUTOTAG_VERSION=v1.1.4
RUN apk add --no-cache git make
WORKDIR /home
RUN git clone https://github.com/pantheon-systems/autotag.git
WORKDIR /home/autotag
RUN git checkout $AUTOTAG_VERSION
RUN make build
use golang:alpine
instead of the one by circleci
We regularly tag dev preview versions as dev releases. It would be nice if this suffix was also supported.
just a nice to have, not a big deal.. a learning experience perhaps
From our readme:
autotag scans the master branch for commits by default. Use -b/--branch to scan a different branch.
It should look for both master and main.
We also need to change this repo to use main instead of master and since autotag's CI uses autotag it might be worthwhile to do these things at the same time.
Hello,
I'm trying to use Autotag
in one of my pipelines in Drone CI.
I always get the following error message:
2021/12/10 10:14:26 Error initializing: no stable (non pre-release) version tags found
Here's my pipeline configuration:
kind: pipeline
type: kubernetes
name: tag-repo
steps:
- name: autotag
image: node:14
commands:
- curl -sL https://git.io/autotag-install | sh -s -- -b /usr/bin
- git --version
- autotag -n -b dev
trigger:
branch:
- dev-ci
event:
- push
I'm adding git --version
to make sure that I have git 2.X+
available in the PATH.
And I'm using the -n
option just to validate if Autotag
is working correctly for now.
Here's the output:
1 + curl -sL https://git.io/autotag-install | sh -s -- -b /usr/bin
2 pantheon-systems/autotag info checking GitHub for latest tag
3 pantheon-systems/autotag info found version: 1.3.13 for v1.3.13/linux/amd64
4 pantheon-systems/autotag info installed /usr/bin/autotag
32 + git --version
33 git version 2.11.0
34 + autotag -n -b dev
35 2021/12/10 10:14:26 Error initializing: no stable (non pre-release) version tags found
If I run the same command locally in the same repository it manages to compute the next tag normaly.
Is there any trick or extra configuration that I need to make this work in Drone CI?
We currently support SemVer pre-release builds with the -
separator. The SemVer 2.0.0 spec also specifies a +
for embedding metadata such as git hashes.
https://semver.org/
https://semver.org/#spec-item-10
Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
<valid semver> ::= <version core>
| <version core> "-" <pre-release>
| <version core> "+" <build>
| <version core> "-" <pre-release> "+" <build>
We could support +
. A couple ideas come to mind:
v1.0.0+g01aabbcc
v1.0.0+g01aabbccddeeff11223344
%Y%m%d
, eg: v1.0.0+20200408
Maybe a flag to add arbitrary data as well? That might simplify # 3 by allowing the user to use shell expansions instead of having to parse the strftime string in autotag, eg: autotag -flagname $(date +%Y%m%d)
SemVer does not place any limits on pre-release names, I'm not sure there's a reason we should either.
It looks like autotag
is unable to move from v0.9.x to v0.10.0. Whatever you're using conventional or autotag, the bug exists for both.
if v != nil && v.String() > r.newVersion.String() {
this code compares string lexicographically. That's why "0.9.0" is greater than "0.10.0".
WISOTT
platform darwin/arm64 is not supported
I wasn't able to tag a bare repository which looks like this:
./
../
branches/
config
description
HEAD
hooks/
info/
objects/
refs/
Hey,
Are v
-prefixed tags supported?
With a little experiment I did (with the latest version of autotag
), this didn't seem to work for me:
My latest tag was v1.0.4
, so I'd expect my next (patch) tag would be v1.0.5
. From some reason, I've got 1.0.5
(without v
):
❯ git describe --abbrev=0 --tags
v1.0.4
and when running autotag
:
❯ ./bin/autotag -n
1.0.5
I even saw there is a flag that let you disable it (-e, --empty-version-prefix Do not prepend v to version tag
), so that hints it should work by default, no?
Is it on purpose? If yes, what am I doing wrong and how can I config it to work with v
-prefixed tags?
Thanks!
This issue, I think, is related if not the reason #72 was discovered.
It appears that the logic for determining versions, particularly in the context of !
, is not working as intended when that !
commit is not the most recent.
In the screenshots below, the last tag was 3.0.0 so the expectation for these tests is that the version bump should be 4.0.0.
If commit 3fd23e8f5482f0ad0027a624ff6682492f45dc64
were the last commit, autotag would output 4.0.0 as intended.
Lines 381 to 394 in 408aa18
It looks like in this loop the version bump is being set on each iteration, so long as as the bump is not nil
. This will overwrite a major bump with a minor depending on the order of parsing. I believe this is what was causing the bug as well in #72, the order itself actually was not the issue. There just exists a possibility where a minor bump overwrites the major bump.
I think in the loop above, just need to compare the current version to the previous version and somehow compare whether the current bump is greater than the previous and apply the biggest bump rather than applying the bump on non-nil
(L392).
Can you also ensure that this fixes the !
mirror, IE BREAKING in the body?
Would it be possible to add support for conventional commits?
You will find information on https://www.conventionalcommits.org/en/v1.0.0/.
This could maybe be implemented by an option to override the default regex.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.