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.

Sign up for GitHub

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

Jump to bottom

Enable release image building #104

Closed
wants to merge 5 commits into from
Closed

Enable release image building #104

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
dd138f6
Enable release image building
yzhang-23 May 11, 2023
bea7115
Update image-c-cpp_tmpl.yaml
yzhang-23 May 11, 2023
9ef7cb0
Add options for package installation and image building/pushing
May 18, 2023
771f4f4
Add options for package installation and image building/pushing
yzhang-23 May 18, 2023
65f9760
Add options for package installation and image building/pushing
yzhang-23 May 18, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 33 additions & 2 deletions .github/workflows/image-c-cpp_tmpl.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,11 +22,21 @@ on:
required: true

jobs:
Repo_name_lowcase:
runs-on: ubuntu-latest
outputs:
lowcase_repo_name: ${{ steps.output-repo-name.outputs.repo_name }}
steps:
- name: Output repo name in lowcase
id: output-repo-name
run: |
name=${{ inputs.repo }}
echo "repo_name=${name,,}" >> "$GITHUB_OUTPUT"
Build:
runs-on: ubuntu-latest
needs: Repo_name_lowcase
container:
# will make the image choosing automatical later. Now it is hardwired
image: ghcr.io/nwchemex-project/build_parallelzone:v1
image: ghcr.io/nwchemex-project/build_${{needs.Repo_name_lowcase.outputs.lowcase_repo_name}}:v1
credentials:
username: ${{ github.actor }}
password: ${{ secrets.CONTAINER_REPO_TOKEN }}
Expand Down Expand Up @@ -57,3 +67,24 @@ jobs:
uses: NWChemEx-Project/.github/actions/image-test@master
with:
CMAIZE_GITHUB_TOKEN: ${{ secrets.CMAIZE_GITHUB_TOKEN }}
- name: Login to GitHub Container Registry
if: ${{inputs.gcc-build == true}}
uses: docker/login-action@v1
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.CONTAINER_REPO_TOKEN }}
- name: Extract metadata (tags, labels) for Docker
if: ${{inputs.gcc-build == true}}
id: meta
uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7
with:
images: ghcr.io/nwchemex-project/release_${{needs.Repo_name_lowcase.outputs.lowcase_repo_name}}
- name: Build the image and push
if: ${{inputs.gcc-build == true}}
uses: docker/build-push-action@v4
Copy link
Member

Choose a reason for hiding this comment

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

Isn't this going to push every time this workflow is run? Isn't this also the workflow used for testing the PRs? We don't want those to be the same workflow as the deployment is different than the testing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Isn't this going to push every time this workflow is run? Isn't this also the workflow used for testing the PRs? We don't want those to be the same workflow as the deployment is different than the testing.

So you mean a separated workflow simply to deploy the code, right? What would be the event to trigger this workflow, say a successful testing?

Copy link
Member

Choose a reason for hiding this comment

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

image

Here's some sketches meant to depict how I'm thinking about the various use cases. The sketch shows the DockerFiles living in the respective repos. If you're able to create a single DockerFile which can be used to build each repo's base image (presumably by using variables for the the base image's base image and the dependencies to build) and/or a single DockerFile for building the release images (presumably by using variables for the base image) then those common DockerFiles can live here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Isn't this going to push every time this workflow is run? Isn't this also the workflow used for testing the PRs? We don't want those to be the same workflow as the deployment is different than the testing.

Added options to install the package, build and push the release docker image only when necessary. Different calls would come from different workflow in the corresponding repo invoked by different events, e. g., PR or push to master.

with:
context: .
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
9 changes: 6 additions & 3 deletions actions/image-build/build.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -54,12 +54,15 @@ else
fi

#Step 2: Configure

export INSTALL_PATH=install
keceli marked this conversation as resolved.
Show resolved Hide resolved
if [ "${ninja_build}" = true ] ; then
${cmake_command} -GNinja -H. -Bbuild -DCMAKE_TOOLCHAIN_FILE="${toolchain_file}"
${cmake_command} -GNinja -H. -Bbuild -DCMAKE_TOOLCHAIN_FILE="${toolchain_file}" -DCMAKE_INSTALL_PREFIX=${INSTALL_PATH}
else
${cmake_command} -H. -Bbuild -DCMAKE_TOOLCHAIN_FILE="${toolchain_file}"
${cmake_command} -H. -Bbuild -DCMAKE_TOOLCHAIN_FILE="${toolchain_file}" -DCMAKE_INSTALL_PREFIX=${INSTALL_PATH}
fi

#Step 3: Compile
${cmake_command} --build build

#Step 4: Install
${cmake_command} --build build --target install