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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish Vanilla AMI in EC2 #399

Merged
merged 2 commits into from
Jul 13, 2021
Merged

Publish Vanilla AMI in EC2 #399

merged 2 commits into from
Jul 13, 2021

Conversation

davidcassany
Copy link
Contributor

This commit adds a makefile target to publish the cOS Vanilla image
that might be later on used on Packer templates.

It also adds an additional CI job to publish it as part of the CI
workflow.

Related to #378

Signed-off-by: David Cassany [email protected]

@davidcassany davidcassany marked this pull request as draft July 12, 2021 11:10
@davidcassany davidcassany force-pushed the publish_vanilla_ami branch 5 times, most recently from e98c89c to 2a19734 Compare July 12, 2021 14:14
@davidcassany davidcassany marked this pull request as ready for review July 13, 2021 10:31
@davidcassany
Copy link
Contributor Author

@mudler @Itxaka JFYI I tested the publish-vanilla-ami-opensuse in this job in fork of mine

@@ -187,7 +187,7 @@ jobs:
yq w -i $MANIFEST.remote 'luet.repositories[0].type' 'docker'
yq w -i $MANIFEST.remote 'luet.repositories[0].urls[0]' $FINAL_REPO
sudo -E MANIFEST=$MANIFEST.remote make local-iso
COS_VERSION=$(yq r packages/cos/collection.yaml 'version')
COS_VERSION=$(yq r packages/cos/collection.yaml 'packages.[0].version')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was pretty sure I changed this already, was it lost on some commit?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was also surprised by that... I thought it was also solved already... 🤷‍♂️


{{{ if $config.publishing_pipeline }}}

publish-vanilla-ami-{{{ $flavor }}}:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we really need to push the raw image per flavor? AFAIK we only use the recovery part of it, are the recoveries different between flavors?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I say this, because we should push ubuntu/fedora images so we should remove the skip_images_flavor: ["fedora","ubuntu"] but that would make the vanilla upload 3 times

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See this is only active for $config.publishing_pipeline which is only active for master.yaml and master.yaml also includes

skip_tests_flavor: ["fedora","ubuntu"]                                          
skip_images_flavor: ["fedora","ubuntu"] 

which causes it only to be computed per opensuse

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, but we would need to publish ami images for both systems, which means it will trigger the vanilla image upload 3 times

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I see, you suggest to name it without a flavor

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about now, it is statically forced for opensuse, it is named without a flavor and it only applies for master workflow.

run: |
make aws_vanilla_ami

ami-publish-{{{ $flavor }}}:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently this will only upload the suse image.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct

images/aws_upload.sh Outdated Show resolved Hide resolved
images/aws_upload.sh Outdated Show resolved Hide resolved
@@ -1,13 +1,16 @@
name: "Default deployment"
stages:
rootfs.after:
- name: "Repart image"
- if: '[ -f "/run/cos/recovery_mode" ]'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 👍 👍

This commit adds a makefile target to publish the cOS Vanilla image
that might be later on used on Packer templates.

It also adds an additional CI job to publish it as part of the CI
workflow.

Related to #378

Signed-off-by: David Cassany <[email protected]>

echo "Tagging Snapshot"
aws ec2 create-tags --resources "${snap_id}" \
--tags Key=Name,Value=${disk_name} Key=Project,Value=cOS Key=GITHUB_SHA,Value=$github_sha
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more interesting is the Key=Flavor,Value=$FLAVOR here, as it will allow us to create deletion policies based on the flavor images

Copy link
Contributor

@Itxaka Itxaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is green, no point in blocking it, I can add the extra tags afterwards

@davidcassany davidcassany merged commit 3db5cd7 into master Jul 13, 2021
@davidcassany davidcassany deleted the publish_vanilla_ami branch July 13, 2021 13:32
@davidcassany
Copy link
Contributor Author

Right, merged, now lets see if the master build behaves good, changes on the master workflow are always tricky 🤞

frelon pushed a commit to frelon/elemental-toolkit that referenced this pull request May 12, 2023
This commit adds post-* hooks where the after hooks were originally
defined. After hooks are moved to happen straight in sequence after the
after-*-chroot hooks.

The main motivation for such a change is having a hook that includes the
partition, the running system and the deployed image all mounted and
easily accessible.

Signed-off-by: David Cassany <[email protected]>
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

Successfully merging this pull request may close these issues.

3 participants