Skip to content

Conversation

addaleax
Copy link
Collaborator

Adjust the build configuration, and the package build steps,
to account for different package names being used in package
creation.

Extend the packaging and package test matrices to cover
shared-openssl artifacts. This does not include publishing
them as part of the release steps.

This also addresses MONGOSH-1213 (Linux arm64 smoke tests
are done inside docker now, just like x64) since it proves
convenient for testing rpm/deb packages that come with
extra dependencies (such as specific OpenSSL versions).

Additionally, as a drive-by fix, add Linux x64 and arm64
package smoke testing for the regular (static-OpenSSL)
.tgz tarballs.

Adjust the build configuration, and the package build steps,
to account for different package names being used in package
creation.

Extend the packaging and package test matrices to cover
shared-openssl artifacts. This does *not* include publishing
them as part of the release steps.

This also addresses MONGOSH-1213 (Linux arm64 smoke tests
are done inside docker now, just like x64) since it proves
convenient for testing rpm/deb packages that come with
extra dependencies (such as specific OpenSSL versions).

Additionally, as a drive-by fix, add Linux x64 and arm64
package smoke testing for the regular (static-OpenSSL)
.tgz tarballs.
run_on: rhel83-fips
tasks:
- name: e2e_tests_linux_x64
- name: e2e_tests_linux_x64_openssl11
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This doesn’t (shouldn’t?) yet test mongosh in FIPS mode, it’s only that the OS itself is set up to support FIPS.

sourceFilePath: path.resolve(TMP_DIR, 'manpage', MANPAGE_NAME),
packagedFilePath: MANPAGE_NAME,
},
metadata: {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This may need to be restructured a bit for actually releasing these artifacts, but for now this works.

ADD ${artifact_url} /tmp
ADD node_modules /usr/share/mongodb-csfle-library-version/node_modules
RUN dnf update -y
# epel-release so that openssl3 is installable
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I considered just adding this to the regular Rocky Linux 8 Dockerfile, but decided against it since it’s nice to actually know that no special packages are required for install the static-openssl mongosh on the base system.

RUN yum install -y /tmp/*mongosh-*.x86_64.rpm
RUN dnf repolist
RUN dnf install -y man
RUN dnf install -y /tmp/*mongosh*.rpm
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Just to align with the other Dockerfiles for distros that have dnf

Copy link
Collaborator

Choose a reason for hiding this comment

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

nice, had no idea this was happening

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

me neither :)

- name: pkg_test_docker_debian11_deb
- name: pkg_test_docker_ubuntu18_04_deb
- name: pkg_test_docker_ubuntu20_04_deb
<% for (const { distributionBuildVariants, executableOsId } of EXECUTABLE_PKG_INFO) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I was wondering, is there a way to move this heavy logic outside of yaml? Seems hard to understand the code here and also a bit intimidating to change.

If we are using something like lodash.template or similar I'd prefer something like this with more helpers:

<% for ( const dockerfile of getSmokeTestDockerfiles(EXECUTABLE_PKG_INFO)) { %>
  - name: pkg_test_<%= asTaskName('pkg_test', dockerfile) %>
<% } %>

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Mh yeah, we could look into using lodash.template at some point, and we can also add helper functions for simplifying this.

It’s definitely easier not to outsource everything from the YAML here though; it has been very helpful to have a single source of truth for how our CI jobs are defined.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah, that's a good point, I mainly find it hard to parse, probably just having helpers to make the code "lighter" would be enough.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It absolutely is hard to parse! I don’t want to act like it isn’t :)

I’ll definitely think about it, for now my main goal here is getting everything to work tbh

Copy link
Collaborator

@mcasimir mcasimir left a comment

Choose a reason for hiding this comment

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

Awesome! If you have some time and give a thought on whether we could simplify the yaml generation that would be cool, but if not looks good to go!

@addaleax addaleax merged commit 7b341f5 into main May 25, 2022
@addaleax addaleax deleted the 1224-dev branch May 25, 2022 15:16
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.

2 participants