-
Notifications
You must be signed in to change notification settings - Fork 10
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
[Feature Add]: Auto-snap-versioning #516
Conversation
@sergio-costas , could you kindly review this pull request and advise on any necessary changes? |
@rudra-iitm I'll check it this monday. |
@sergio-costas, any updates ?? |
Exactly what does this do? Take the current version number and try to automagically extract the version format, thus avoiding to manually set the "format" token in the "version-format" field? |
@sergio-costas, I've segregated the manageYAML and Snapcraft classes into distinct files. Please review the modifications. |
@rudra-iitm I assume that what happens here is that every 24 hours, when the Snap repo's workflow triggers this GitHub action, it is checked for new commits and if there actually are new commits, the Snap's version is updated. This leads to an extra commit for the version number update. In my original version, individually added to each Snap, there are no extra commits. If version bump with every commit is desired one could use this GitHub action by simply adding to the trigger methods in the Snap repo's workflow that it should be also done on every commit. Then each commit would be followed by a version bump commit (attention, needs a guard against infinite recursion). The every-24-hours trigger method needs to stay, so that new upstream versions are detected also on days without commits. |
@tillkamppeter, You are right at the point that this script checks for any commit in snapping repository when the github-workflow is triggered. Allow me to elaborate further on the script's functionality:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another question: how is the version number incremented? I mean: is just the same number than in the git tag, or does it add something extra?
The primary idea behind allowing the version-schema to be user-input lies in affording users a degree of customization regarding the version number. For instance, consider the ghostscript-printer-app. While the git tag may be labeled as 'ghostpdl-10.02.1', the version listed on the snap store appears as '10.02.1-2'. In such instances, users can specify a version schema such as '^ghostpdl-(\d+.\d+.\d+)' to isolate '10.02.1', with the package release appended as previously outlined. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a little nitpick.
Ok. Thanks! |
Auto Snap Versioning Feature:
Version Schema Specification:
Optional Feature:
Prerequisites for Usage: