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

Publish release artifacts with manifests #1722

Open
lentzi90 opened this issue May 8, 2024 · 16 comments
Open

Publish release artifacts with manifests #1722

lentzi90 opened this issue May 8, 2024 · 16 comments
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/accepted Indicates an issue is ready to be actively worked on.

Comments

@lentzi90
Copy link
Member

lentzi90 commented May 8, 2024

What steps did you take and what happened:

As seen in metal3-io/metal3-docs#414 we are not setting the image tag in the manifests. This is fine for the main branch, but it is not ideal for release branches and tags.
I think we should set the image tag always on release branches to the same as the release branch and for tags to the exact tag.
Otherwise a user trying to apply manifests from release-0.6 for example, will end up with the latest container image from main.

We should publishing release artifacts where the correct image tag is used. Currently we have a default config mixed in with the manifests. This does not make sense to include in the release artifacts IMO. We should handle it the same as the secrets. I.e. the manifests expect the configmap to exist but it is up to the user to create/add it in some way.

With that fixed I think we can do release artifacts and set the image there.

What did you expect to happen:

When using manifests from a specific branch or tag, the corresponding container image should be used.
We should probably include this in the release process.

/kind bug

@metal3-io-bot metal3-io-bot added kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue lacks a `triage/foo` label and requires one. labels May 8, 2024
@Rozzii
Copy link
Member

Rozzii commented May 15, 2024

/triage accepted

@metal3-io-bot metal3-io-bot added triage/accepted Indicates an issue is ready to be actively worked on. and removed needs-triage Indicates an issue lacks a `triage/foo` label and requires one. labels May 15, 2024
@Rozzii
Copy link
Member

Rozzii commented May 15, 2024

/help

@metal3-io-bot metal3-io-bot added the help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. label May 15, 2024
@Rozzii Rozzii added good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. and removed help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels May 15, 2024
@7h3-3mp7y-m4n
Copy link

hey I would like to contribute to it if someone has not picked it up yet

@lentzi90
Copy link
Member Author

lentzi90 commented Jun 3, 2024

Go for it!
/assign @7h3-3mp7y-m4n

@babugeet
Copy link
Contributor

babugeet commented Jun 5, 2024

/assign

@babugeet
Copy link
Contributor

babugeet commented Jun 5, 2024

@lentzi90 : should we do it for previous release branches as well , or current one only?
Also if we hardcode the value lets say for next release, we take it as v0.6.1, would this need to be updated in every release.
Isnt there a way to automate this one ?

@lentzi90
Copy link
Member Author

lentzi90 commented Jun 5, 2024

@babugeet are you working together with @7h3-3mp7y-m4n ? If not, please let @7h3-3mp7y-m4n get a chance to work on this first.

@metal3-io-bot
Copy link
Contributor

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@metal3-io-bot metal3-io-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 3, 2024
@tuminoid
Copy link
Member

tuminoid commented Sep 3, 2024

/remove-lifecycle stale

@metal3-io-bot metal3-io-bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 3, 2024
@metal3-io-bot
Copy link
Contributor

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@metal3-io-bot metal3-io-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 2, 2024
@tuminoid
Copy link
Member

tuminoid commented Dec 2, 2024

Should we close this issue or #2089 as both of them are the same, if we ignore the first proposed solution here, which we declined?

Which one to close? This one is older but also more confusing, the latter is clearer as it only has the one accepted solution detailed.

@lentzi90

@Rozzii
Copy link
Member

Rozzii commented Dec 2, 2024

As I have commented for #2089 I would keep the older issue.
I would update this issue and add your description @tuminoid here to extend the old issue .

@Rozzii Rozzii added the priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. label Dec 2, 2024
@Rozzii
Copy link
Member

Rozzii commented Dec 2, 2024

/remove-lifecycle stale

@metal3-io-bot metal3-io-bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 2, 2024
@lentzi90
Copy link
Member Author

lentzi90 commented Dec 2, 2024

Ok if we are going to do this with release artifacts we will need to do some more changes. The tricky part is that we cannot include configuration in the release artifacts. Currently we have a default config mixed in with the manifests. This does not make sense to include in the release artifacts IMO. We should handle it the same as the secrets I think. I.e. the manifests expect the configmap to exist but it is up to the user to create/add it in some way.

With that fixed I think we can do release artifacts and set the image there. (Side note: we should then use those release artifacts in CAPM3 e2e also.)

Edit: I realize I didn't explain why it may be tricky to do this. It is because of metal3-dev-env. It directly modifies the default config here: https://github.com/metal3-io/metal3-dev-env/blob/0b07f57d8bc1fe9596c748b58ac01c75f6eb93d6/03_launch_mgmt_cluster.sh#L64-L70
Perhaps not "hard" to do it differently, but this affects a lot of things.

@tuminoid
Copy link
Member

tuminoid commented Dec 2, 2024

As I have commented for #2089 I would keep the older issue. I would update this issue and add your description @tuminoid here to extend the old issue .

Let's just make it absolutely clear what this ticket is about. So remove the other option and put in the Lennarts comment etc. It also does not sound that it is good first issue anymore, so adjust the labels accordingly.

@lentzi90 lentzi90 changed the title Set image tag for release branches and tags Publish release artifacts with manifests Dec 2, 2024
@lentzi90
Copy link
Member Author

lentzi90 commented Dec 2, 2024

/remove-help

@metal3-io-bot metal3-io-bot removed help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. labels Dec 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/accepted Indicates an issue is ready to be actively worked on.
Projects
Status: BMO WIP
Development

Successfully merging a pull request may close this issue.

6 participants