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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build containers are not representative for the release processs #125

Open
mpkorstanje opened this issue Dec 17, 2022 · 5 comments
Open

Comments

@mpkorstanje
Copy link
Contributor

馃憮 What did you see?

This release failed because the combination of ubuntu-latest, the otp verison and elixir version stopped working. We didn't see this earlier because the Build containers use a different process.

https://github.com/cucumber/messages/actions/runs/3719910333/jobs/6309058962

@ciaranmcnulty
Copy link
Contributor

Hm I've not looked at the release side and don't feel I understand it that well. How can we combine it with the build steps?

@mpkorstanje
Copy link
Contributor Author

mpkorstanje commented Jan 5, 2023

It depends on the language used. For some it's just a matter of tagging the repo, for some it's the build step + an additional the release, for some it is a completely different and independent step.

In this particular case I don't know the specifics. However it appears that the same toolset is used by both test and release. However because they're installed with different versions in different places the tests aren't representative anymore.

In this case GitHub upgraded Ubuntu, but it could any dependency.

@ciaranmcnulty
Copy link
Contributor

I wonder whether the tests need to run as part of release, or whether we can chain the existing test workflow 'before' the release workflow?

@mpkorstanje
Copy link
Contributor Author

Ideally not. The closer we are to the "native" process the better. Each bit of customization makes the system as a whole more complicated.

I think thats currently also my biggest concern about the build kit. We appear to be on the path of essentially rebuilding the complexity of the Makefile.

@mpkorstanje
Copy link
Contributor Author

Looking back I think this got merged prematurely, I would be okay with reverting until we can put more time into this and see where exactly we will end.

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

No branches or pull requests

2 participants