Feature: Build idpbuilder binaries and publish them (main, PR)

cmoulliard commented 3 weeks ago

Have you searched for this feature request?

[X] I searched but did not find similar requests

Problem Statement

To test the code of idpbuilder, when not yet released or part of a PR, it is needed to clone the project, checkout the branch/PR and build it. This is not an issue for the developers as they have installed go and needed tools on their machine but this is not the case, when you want to test it part of a github workflow or equivalent.

This is why I propose that part of a PR merged on main, we generate the idpbuilder binaries + compressed files and publish them on the github project repository to let a user to get them

Possible Solution

Example: https://trstringer.com/github-actions-create-release-upload-artifacts/

Alternatives Considered

N/A

omrishiv commented 2 weeks ago

I think the repo already does this or is there something missing? https://github.com/cnoe-io/idpbuilder/blob/main/.github/workflows/release.yaml

https://github.com/cnoe-io/idpbuilder/releases

cmoulliard commented 2 weeks ago

No as only the official releases are pushed here: https://github.com/cnoe-io/idpbuilder/releases but not snapshots

omrishiv commented 2 weeks ago

I think I understand: are you asking for a workflow to run on commits so that you can test those?

cmoulliard commented 2 weeks ago

I think I understand: are you asking for a workflow to run on commits so that you can test those?

Yes ;-)

omrishiv commented 1 week ago

@nimakaviani @nabuskey I'm happy to add this feature, do we want it stored as artifacts tagged by githashes? @cmoulliard do you see any issues with this adding to the list of tags/releases?

nabuskey commented 1 week ago

I am fine with this as long as they don't show up in the releases page. I think we should do a nightly build instead.

omrishiv commented 1 week ago

A nightly wouldn't allow testing of a PR though. I suggest: 1) We allow uploading artifacts on commits. This will allow build automation to build/upload the artifact and attach the link to the action. We can also comment on the issue with the artifact location if that's helpful and if it's part of a PR 2) Create a nightly build regardless. We can publish that artifact and it would show up as a release.

Thoughts?

nimakaviani commented 1 week ago

+1 on not having these show up in the release pages and also we will have to have a way to garbage collect these. Other than the official releases, I suppose only the latest nighly is going to be useful to people.

Nightlies are easier to reason about. I dont think there is huge value in having releases off of specific PRs except for when one is waiting for the next nightly and that appears to be an edge case too.

my vote would be on keeping only one nightly release that builds off of the latest HEAD and garbage collecting everything else.

omrishiv commented 1 week ago

I think we're still left with the question of automating builds for unmerged work. A nightly wouldn't build branches. I think the heart of the issue is the value of building the in-process work: If it's for your own testing, is it possible to build on your machine? Also, since you'd be forking the repo and working off the fork, it wouldn't build the commit anyways.

nabuskey commented 1 week ago

I think we're still left with the question of automating builds for unmerged work. A nightly wouldn't build branches. I think the heart of the issue is the value of building the in-process work: If it's for your own testing, is it possible to build on your machine? Also, since you'd be forking the repo and working off the fork, it wouldn't build the commit anyways.

I think we should build off of main only. If someone creates a PR to our repo, it's reasonable for us to expect that they have built it on their machine and ran it.

If someone wants to use a binary off of main, we should enable them to do so. They maybe wanting to work around a bug that's fixed in main but not yet included in the latest release. This is why I am suggesting a nightly build. Sorry I don't think I was clear enough.

GC on nightly build is a good one too. We probably shouldn't keep too many of these. Maybe we can start with keeping just one like Nima mentioned. If there are demands for more nightly builds for some reason, we can increase it.

omrishiv commented 1 week ago

Yes, that's what I'm getting at with the questions. I guess my assumption is that if you're writing code, you should be able to build it too unless there's a use case we're missing here.

This is a nice action for automatically doing nightlies and rotating them: https://github.com/WebFreak001/deploy-nightly

cmoulliard commented 1 week ago

This is a nice action for automatically doing nightlies and rotating them: https://github.com/WebFreak001/deploy-nightly

Another interesting blog post about this point to generate nightly build: https://dev.to/derlin/how-to-create-nightly-releases-with-github-actions-fpp

omrishiv commented 1 week ago

This is a nice action for automatically doing nightlies and rotating them: https://github.com/WebFreak001/deploy-nightly

Another interesting blog post about this point to generate nightly build: https://dev.to/derlin/how-to-create-nightly-releases-with-github-actions-fpp

Thanks for sharing! What do you think then? Does it make sense to just do nightlies? Do you have a use case we missed by not building commits?

cmoulliard commented 1 week ago

Thanks for sharing! What do you think then? Does it make sense to just do nightlies? Do you have a use case we missed by not building commits?

Let's start first with a nightly build. I dont think that this is really easy to create a PR release build available for a PR and deleted when PR is merged

omrishiv commented 1 week ago

👍 I'll take this one

cmoulliard commented 1 week ago

Here is what I suggest to do:

When a new idpbuilder is released (example: v0.5.0 -> v0.6.0)
We create a new release v0.7.0-next
New commits pushed on the main branch will launch the job responsible to build the binaries and to push them under the release v0.7.0-next. Here is by example what backstage release : https://github.com/backstage/backstage/releases/tag/v1.28.0-next.2

nabuskey commented 1 week ago

I do like the -next naming. I still think we should start with a nightly build instead of each commit to main. I think we should build nightly with -next naming convention and GC.

cmoulliard commented 1 week ago

I do like the -next naming. I still think we should start with a nightly build instead of each commit to main. I think we should build nightly with -next naming convention and GC.

For nightly build, then we should use -nightly as the word is self-explanatory

omrishiv commented 1 week ago

I've been working on this this morning; I should have a PR open soon for us to discuss

omrishiv commented 1 week ago

I've hit a bit of a limitation and need a @cnoe-io/core-team maintainer to generate a GH token for the org that I can use in my action. I need an action to tag a build as nightly, and to use the commit event to create a release. I can't do this using the repository secret: https://github.com/orgs/community/discussions/27028#discussioncomment-3254360. So I'd need a PAT generated for the org and added as a secret to the idpbuilder repo. If you could share the name, I can finish the PR

You can see what I'm trying to do here: https://github.com/cnoe-io/idpbuilder/compare/main...omrishiv:idpbuilder:281-add-nightly-builds

cnoe-io / idpbuilder