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

Create AWX Operator version file #24

Closed
wants to merge 3 commits into from

Conversation

oraNod
Copy link
Contributor

@oraNod oraNod commented Oct 21, 2024

Resolves #22

  • Adds awx-operator-version.txt that captures the version of the AWX Operator (repo tag).
  • Updates the makefile to set the AWX Operator version from the txt file.
  • Updates the clone script to use the txt file when grafting relevant parts of the AWX Operator repo.

@miles-w-3
Copy link
Collaborator

@oraNod I think it makes sense to use the helm-starter Chart.yaml here as the source of truth for versioning. Annoyingly, the helm init command using a starter does not inherit those version fields, but we could use yq to copy them in from the starter chart.yaml into the main one. Under this system, appVersion would be the version of AWX Operator as the app being installed by the chart, and then version would be our separately maintainable field that we can increment for our other proposals like adding labels, annotations, controller field overrides, etc.

I'm happy to create a PR proposal if that's easier

@oraNod
Copy link
Contributor Author

oraNod commented Oct 22, 2024

@oraNod I think it makes sense to use the helm-starter Chart.yaml here as the source of truth for versioning. Annoyingly, the helm init command using a starter does not inherit those version fields, but we could use yq to copy them in from the starter chart.yaml into the main one. Under this system, appVersion would be the version of AWX Operator as the app being installed by the chart, and then version would be our separately maintainable field that we can increment for our other proposals like adding labels, annotations, controller field overrides, etc.

I'm happy to create a PR proposal if that's easier

@miles-w-3 Thanks for this suggestion! It does seem like the right place for a source of truth. I was honestly thinking that the solution I've put together in this PR might be a bit hack-y so I really appreciate you pointing this out and steering towards something less clunky. This could also remove the need to create tags.

I certainly don't mind you creating a PR proposal. I'm happy to do that too but will step back and let you go for it. Cheers.

@miles-w-3
Copy link
Collaborator

@oraNod Sorry for the delay, please see #25

This may also be out of scope for this PR, but there's an opportunity for us to do a lot less work around the releases with chart-releaser. We couldn't use it before fully since it was part of the larger repo but it might help, there's a comment on it here:

# The actual release happens in ansible/helm-release.yml, which calls this targer

@oraNod
Copy link
Contributor Author

oraNod commented Nov 5, 2024

@miles-w-3 No worries at all about the delay. I was out last week doing family stuff. I'll go ahead and close this PR as your alternative is much better (and less hacky).

That also sounds good about using chart-releaser. Seems like a better way to do things (but, yeah, as a follow on). Thanks for pointing that out!

@oraNod oraNod closed this Nov 5, 2024
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

Successfully merging this pull request may close these issues.

Helm chart versioning
2 participants