We just published new release 3.8.366. I have added tag release-3.8.366 as well as GitHub release.

Best regards,
Victor

Hey Victor,

Thanks so much this, it makes my job handling automated releases much easier. I am currently in the process of scoping out the most efficient method of handling release automation. Currently the short list contains

• GitHub Bot
• GitHub Action Scheduled
• GitLab CI Job Scheduled

I am leaning towards the GitHub action, I suspect it will end up that the action runs in the context of Matthew-Beckett/netxms-dockerfiles and will need a webhook from netxms/netxms to trigger the pipeline on creation of a Release.

Best regards,
Victor

Yes, from now on we will put lightweight tags on each release. We will also experiment with GitHub releases, will see how it will work.

Regarding maintenance and documentation - we are ok to include Docker based installation into installation guide. Do you mind moving source files for Docker deployment into separate repository under netxms project on GitHub?

Best regards,
Victor

Yes, there is potential to bring Matthew-Beckett/netxms-dockerfiles into netxms/dockerfiles. Though I would prefer we look into this once the images are more mature and stable, currently I depend on GitLab CI for building and publishing the images, if we were to bring the Dockerfiles into a repository under NetXMS I would like to move this to GitHub Actions.

Regarding maintenance and documentation - we are ok to include Docker based installation into installation guide. Do you mind moving source files for Docker deployment into separate repository under netxms project on GitHub?

Best regards,
Victor

We decide that we do official packaging when planned features and fixes are ready. As third number in version is generated automatically from git commits it cannot be predicted. i think that lightweight tags is a way to go, we will just put lightweight tag whenever we do deb publishing. We can agree on certain format for those tags so you will be able to distinguish between deb releases and other tags.

Best regards,
Victor

Hi Victor,

Brilliant! This is perfect, does that mean starting with the next 3.8.XXX release I can expect to find a tag at netxms/netxms with that new version as it's name?

Best regards,
Victor

Hello,

I think we can use lightweight tags for marking release versions. Also, you can use this simple script to switch to specific X.Y.Z version within source tree: https://github.com/netxms/netxms/blob/master/tools/switch_to_version.sh

Best regards,
Victor

Hi Victor,

My source of truth for packages is APT, I am not building from source inside the container. Currently I am struggling with finding a reliable mechanism to detect new releases from yourselves, unfortunately benig able to switch to a specific build within git doesn't help and also depends on me knowing what version number to switch to.

In my pipeline I have no context, I have to be able to pull a list of versions (that are available in apt) and compare that with my existing releases.

UPDATE:

I've checked out and tested your script and I can understand how versions numbers are now generated. How do you decide to cut a release? Is it not possible to increase the tagging to include releases present in apt?

I don't even need the commit associated with it, just basically an API I can query and get back a list of available NetXMS releases.

I think we can use lightweight tags for marking release versions. Also, you can use this simple script to switch to specific X.Y.Z version within source tree: https://github.com/netxms/netxms/blob/master/tools/switch_to_version.sh

Best regards,
Victor

Hello.

You can parse https://github.com/netxms/changelog/blob/master/ChangeLog. It's updated before the official release is announced, but once X.Y-CURRENT is changed to full version X.Y.Z - it's frozen.

Hey,

I am working on this at the moment, and parsing the changelog file is going to be unreliable due to a few inconsistencies in formatting throughout the file. We've managed to workaround the majority of the formatting issues, however some will require a PR to fix.

I will send this over when I have finished the parser. However, looking to the future, it would be really helpful if we could look at one of the following improvements:

• Tagging the netxms/netxms repository as specific at minor version
    Currently it's 3.8, I would need 3.8.314 to be an available tag in order to target it in apt
• Creating GitHub releases for all versions available in apt
    Basically the same reason as above, however you can setup a webhook in this case to trigger my bot (for now it will be on a schedule)

Let me know what you think

You can parse https://github.com/netxms/changelog/blob/master/ChangeLog. It's updated before the official release is announced, but once X.Y-CURRENT is changed to full version X.Y.Z - it's frozen.