Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version Bump Automation #540

Closed
1 task done
girodav opened this issue Nov 28, 2023 · 1 comment
Closed
1 task done

Version Bump Automation #540

girodav opened this issue Nov 28, 2023 · 1 comment

Comments

@girodav
Copy link
Contributor

girodav commented Nov 28, 2023

This issue tracks the discussion around handling major/minor version bump automatically.

  • Should we have a workflow that is triggered on a git tag push event, that bumps this line to the next version? Since we do not have version branches, this wouldn't be that trivial to implement. What do we do if the current version in main is, for example, 1.11.1, but we want to create a tag for 1.20?

  • Should we bump the version based on Conventional Commits? E.g we add [bugfix] as prefix to the commit, and this automatically bump the minor version. How do we automatically handle multiple features/commit in a single release?

  • We do not provide support for other cloud providers apart from AWS, yet the version file is in the shared package. I would not worry about it right now, as no support for other cloud providers is in the horizon, but I'd keep in mind while choosing the best approach. Related to this, the current tag name pattern does not match what it is written in version.py (i.e lambda-vX.X.X instead of vX.X.X)

One possible approach is to trigger a github action to "release" (i.e creating git tag and possibly deploy on SAR) whenever version.py is modified.

Related tasks

Preview Give feedback
  1. enhancement
    v1v
@tommyers-elastic
Copy link

thanks for opening the issue @girodav

my preference would be to track the version number using git tags as the primary source. we can create a version.py file at deploy time (via the script), which can be used at runtime to populate the version number. if we try to deploy a version that already exists, the deploy script should fail - how can we track this part? is there a way to query the existing version in SAR?

we also have to remove the manual tracking of the version number in the changelog file. one way to do this would be to utillize something like the elastic-agent-changelog-tool, but we could just as easily roll some simple automation triggered off new git tags, which does something like this and then commits the new file before writing the tag.

changelog="./CHANGELOG.md"
version=$(git describe --tags --match="v[0-9]*" --abbrev=0)
today=$(date -u '+%Y\/%m\/%d')
sed -i -e "s/<version.next>/$version - $today/g" $changelog
echo "### <version.next>\n\n$(cat $changelog)" > $changelog

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants