Jump to content

How to build a specific release?


Go to solution Solved by Werner,

Recommended Posts

Hi!

 

I'm sorry if the answer to my question is already documented somewhere, but I couldn't find it.

 

I am trying to figure out how to build a specific release.

My understanding is that you checkout the desired tag of the armbian/build repo and just build it.

However, when I do this with v24.2.1 the image that comes out is named 24.5.0-trunk.
Changing the version in the VERSION file (by default set to 24.5.0-trunk) changes the name of the output image, but it is not clear to me if that affects other things than just this.


So basically, now I am confused which scenario is correct:

  • Is using the armbian/build tag the correct way to build a specific release and is the VERSION file just cosmetic?
  • Is setting the version in the VERSION file the correct way and should any commit in armbian/build be able to generate the same image, provided the commit is new enough?
  • A 3rd more correct way that I'm not aware of?

 

Can anyone help me out here?

Regards
Stan

Link to comment
Share on other sites

  • Solution
8 hours ago, Stannieman said:

that you checkout the desired tag of the armbian/build repo and just build it.

Hi,

 

Unfortunately this is not the case (yet). Tags are more or less just for archiving the state of the build framework at a certain point of time (usually at release). Due to its design we are not there yet to have working tags that could reproduce older images.

It is our goal to have this working at some point but things are processing very slow.

 

VERSION doesn't do anything and is pure cosmetics.

Link to comment
Share on other sites

5 часов назад, Werner сказал:

VERSION doesn't do anything and is pure cosmetics.

The entry in this file is used as the package version.

 

13 часов назад, Stannieman сказал:

Changing the version in the VERSION file (by default set to 24.5.0-trunk) changes

If you want the packages you have collected to be installed and then they are not updated to packages from the Armbian repository,

then the version in your build should be higher than the current one for today. I.e. 24.5.1-trunk.

Link to comment
Share on other sites

Ok so RE the builds:
That means that if you want to build an image that corresponds to one of versions listed here (https://docs.armbian.com/Release_Changelog/) you pretty much need to build on release day. Otherwise it is possible that some commits for the next version are already merged in and will be part of the build, right?

What kind of work is needed for specific version builds to work? I guess the build scripts need to also checkout that version from other repos and today it just takes the latest of everything?

 

And RE the version file:

What do you mean with "If you want the packages you have collected to be installed..."? Is that for the OFFLINE_WORK=yes option so that the current online version appears older than the local build?

Link to comment
Share on other sites

54 минуты назад, Stannieman сказал:

What do you mean with "If you want the packages you have collected to be installed..."?

Ambiguity of the translation

 

Unfortunately, it is not possible to build a specific version or, in other words, repeat the build.

 

Let's assume that I'm building all the packages and installing them in a future image.

I have made my custom changes in the kernel package and in two other packages.
And I don't want these packages of mine to be updated when the OS is updated.
In this case, I install a version larger than the latest version in the Armbian repository.
Another case.

I've put together three packages and just want to install them into an already running OS on the device.

I'm doing the same thing with the version.
That's what I meant.

Link to comment
Share on other sites

1 час назад, Stannieman сказал:

OFFLINE_WORK=yes

This option can only be used when you have already done the build once.
The sources in the cache folder have been updated or created.
By applying this parameter, the build system should not update local sources and their state should not change.
In this case, it is possible to achieve repeatability of the assembly. But this is only local.
It is not possible to re-build a package that exists in a remote repository.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines