How to change branch selected?
Closed this issue · 9 comments
When I initially configured the project I used BRANCH=equuleus. Now that it is working, I would like to build sagitta too. The readme doesn't explain how to change this option and if any scripts need to be re-ran, some clarification would be really appreciated!
Try just to reset that variable to an empty value, and re-run the scripts.
Which scripts should I be re-running? Do I need to do anything to make sure Jenkins or the cron jobs don't conflict with me running the scripts?
Empty value as stated in the readme means all. Thus export BRANCH=. You need to define the variable, undefined variable means use the cached value.
You can generally re-run all scripts as is implied in the readme. In this case you really need 5-6-7 (since only those use BRANCH) but generally you run all of them since it doesn't hurt and doesn't take long time. The 5-6-7 does take long time but that's what you need to run anyway. The scripts do check and skip if steps were completed.
Got it, will give that a try and report back!
Hmm, build-iso seems to be failing after doing that (I waited quite a few hours):
P: Begin installing packages (install pass)...
Reading package lists...
Building dependency tree...
Reading state information...
debconf is already the newest version (1.5.82).
gpgv is already the newest version (2.2.40-1.1).
gnupg is already the newest version (2.2.40-1.1).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
vyos-1x : Depends: fuse-overlayfs but it is not going to be installed
Depends: podman (>= 4.9.5) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
E: An unexpected failure occurred, exiting...
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists...
Building dependency tree...
Reading state information...
Traceback (most recent call last):
File "/vyos/./build-vyos-image", line 621, in <module>
I: Checking if packages required for VyOS image build are installed
I: using build flavors directory data/build-flavors
I: Cleaning the build workspace
I: Setting up additional APT entries
I: Configuring live-build
I: Starting image build
cmd("lb build 2>&1")
File "/vyos/scripts/image-build/utils.py", line 84, in cmd
raise OSError(f"Command '{command}' failed")
OSError: Command 'lb build 2>&1' failed
ISO build failed
Edit: Ahh I see #44. So I just deleted /opt/vyos-jenkins and instead of downloading it as a TAR I just git clone'd your repo to that folder, so I can git pull new changes as-needed
Yep, always check if scripts weren't updated before you do anything else. The sagitta is still very much moving target so breaking changes happen regularly.
BTW: There is good reason why we don't use git for the scripts - since the 1-prereqs.sh installs the git :).
Yep I've learned my lesson! My build was successful now.
Will that moving target slow down once 1.4.0 stable is released do you think?
BTW: There is good reason why we don't use git for the scripts - since the 1-prereqs.sh installs the git :).
Ahh I see. Maybe it would make sense to have the install instructions tell the user to install git and clone your repo, so that updating is easier
Will that moving target slow down once 1.4.0 stable is released do you think?
The 1.4.0 release already happened 2 months ago. The VyOS has different stable/LTS policy where on the beginning the new stable/LTS branch isn't really stable and the stability is question of time - there is no hard point when the development switches to maintenance mode. The sagitta is very close to the current/circinus and thus it gets many of the improvements that go into current/circinus as well and this breaks the build often. There is no general package freeze as for example Debian has, the VyOS has API freeze instead - thus the CLI shouldn't change anymore, well in backward-incompatible sense but the underlying OS and packages can and do change a lot as we see with 1.4.0 release.
Ahh I see. Maybe it would make sense to have the install instructions tell the user to install git and clone your repo, so that updating is easier
I did think of that when I did decide to use what is already installed. We already handle apt (including apt update) in the 1-prereqs then it seems redundant to redo these steps just for git.
You really don't need the repository anyway, you can just create update-vyos-jenkins.sh:
#!/usr/bin/env bash
rm -rf /opt/vyos-jenkins
wget https://github.com/dd010101/vyos-jenkins/archive/refs/heads/master.tar.gz -O /tmp/vyos-jenkins.tar.gz
tar -xf /tmp/vyos-jenkins.tar.gz -C /tmp
mv /tmp/vyos-jenkins-master /opt/vyos-jenkins
cd /opt/vyos-jenkins
Then you basically get the same thing... The git pull has weakness that it's git, so if someone force-pushes then it may break your tree, then you need do extra steps to reset to origin and then it's not so friendly anymore, mainly for people who don't use git on regular basis - that's why the tarball is more straightforward.
Ahh ok, I just went back and saw the 1.4.0 GA blog post. For some reason I thought this was more of a RC type build. I understand better now, thank you!