It will run on every Monday and will try to update packages listed in
the package listing. This can be used to gradually add more and more
packages under the automation.
This failed when used from ( secret_to_file ... VAR ; cat $VAR )
because ( ) starts a new subshell PID and secret_to_file's returned
/proc/PID/fd/X path was then using the wrong PID.
the JSON object is passed from the Groovy script to the release script,
we just need to extract the correct AWS Marketplace product ID based on
the "<channel>-<arch>".
Exception for the stable-amd64 where we also need to get the stable-pro
product ID.
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
The mantle plume tool has two steps, pre-release is the mere upload and
release is the publication. In the past this was used to run the tests
inbetween but we don't do this anymore.
Run plume pre-release and release in a single job. Since plume can't
push to GCS in our case, we upload the files to bincache. Also do the
cloudformation update which was previously done in
flatcar-build-scripts but could only be run after the sync to Origin.
It requires the "aws" tool in the mantle container until we implement
this in plume directly.
For the main branch (so for nightly builds) the group in
`/usr/share/flatcar/update.conf` is not "main", but "developer". This
needs a small translation when turning it into a channel
information. Without that, we are trying to checkout a nonexistent tag
named `developer-3363.0.0-…` instead of `main-3363.0.0-…`, which
fails.
In developer builds version string contains version numbers and a
build ID with plus symbol sitting between them. Git tags are formatted
in similar way, but with a dash, instead of plus. Thus the plus needs
to be replaced to obtain a proper git tag.
I made a mistake and wrote a version like main-3363-0.0-stuff (note a
dash instead of a dot after the first number). Surprisingly the build
chugged along just fine almost until the end of the image job - it
detected invalid version string when the job wanted to create a
version.txt file:
ERROR build_image: script called: build_image '--board=amd64-usr' '--group=developer' '--output_root=/home/sdk/build/images' '--only_store_compressed' '--torcx_root=/home/sdk/build/torcx' 'prodtar' 'container'
ERROR build_image: Backtrace: (most recent call is last)
ERROR build_image: file build_image, line 196, called: split_ver '3363' 'SPLIT'
ERROR build_image: file common.sh, line 192, called: die 'Invalid version string '3363''
ERROR build_image:
ERROR build_image: Error was:
ERROR build_image: Invalid version string '3363'
Let's have a stricter version check in the beginning of the build
process, so the process fails sooner rather than later.
Upstream lags a bit with packaging vim, which is understandable seeing
how vim is developed (every commit is a tag). Since we need to address
some CVEs, move the packages to overlay and update it there.
Put them into targets/generic profile instead of duplicating them in
amd64/generic and arm64/generic profiles. There's isn't anything
arch-specific in those USE flags.
These are not Flatcar specific modifications per se. We just bump the
version from 9.0.0099 to 9.0.0469 and drop a patch that was already
applied upstream.
These are not Flatcar specific modifications per se. We just bump the
version from 9.0.0099 to 9.0.0469 and drop a patch that was already
applied upstream.
If git show-ref returns an error, i.e. the branch already exists,
then we should not create a pull request, but simply return error.
Otherwise, the Github Actions would always try to create pull
requests even when the branch still exists.
