This naming scheme seemed weird to me so I went looking around at other
Go projects. None of the projects that I found that had multi-arch
release binaries used this scheme, instead they just append the variant
to arch. Appending the variant to the arch also makes a lot of sense if
you think of the naming schme as $binary-$os-$cpu and
$cpu=$arch$variant. Keeping arch and variant together as $cpu is also
more consistent, and consitency is great :D.
Signed-off-by: Manuel Mendez <mmendez@equinix.com>
## Description
Documentation
## Why is this needed
This statement is confusing, I needed to log into the community slack to get clarification.
Fixes: #
## How Has This Been Tested?
This is a documentation change and thus will not impact any software in this project.
## How are existing users impacted? What migration steps/scripts do we need?
They are not, newer users may find this a little easier to digest.
## Checklist:
I have:
- [ ] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
The go program we use to get binaries from a docker image was unpacking
only the last layer. This is not required and in order to have a more
generic approach and fewest requirement the program now unpack all the
image
The go program we use to get binaries from a docker image was unpacking
only the last layer. This is not required and it order to have a more
generic approach and fewest requirement the program now unpack all the
image
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
The main reason for this bump is because we fixed multi arch support for
boots binaries. Before docker images were multi arch but boots was
always x86. This issue is not fixed.
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
script/release-binaries.sh
When writing the release-binary bash script I didn't use the right
variables in current_versions.sh but I fixed those values as part of the
script itself.
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
have a look at the README.md to see how it works.
Bootstrap a CLI program to copy binaries from multi arch images
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
Tinkerbell is made of different components as we all know at this point.
Sandbox had those versions all over the places. This PR moves them as
part of the `envrc` file.
As it is today this PR requires an additional flag for the `docker-compose` command as described here #6
* Change ENV var check to only validate the existence of the
var in the local env
* Add VAGRANT_WORKER_SCALE env variable override to control
GUI scaling for virtualbox
Signed-off-by: James W. Brinkerhoff <jwb@paravolve.net>
Tinkerbell is made of different components as we all know at this point.
Sandbox had those versions all over the places. This PR moves them as
part of the `envrc` file.
Signed-off-by: Gianluca Arbezzano <gianarb92@gmail.com>
