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

Release using github actions #294

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Release using github actions #294

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
49b7c16
add backend as a release
lassemand Nov 6, 2024
47263e7
release ccdscan backend using github actions
lassemand Nov 6, 2024
1c298ad
use context
lassemand Nov 8, 2024
9f910ff
use v1
lassemand Nov 8, 2024
3cbda4e
Merge branch 'main' of github.com:Concordium/concordium-scan into lma…
lassemand Nov 8, 2024
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
14 changes: 14 additions & 0 deletions .github/workflows/release-backend.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
on:
push:
tags:
- ccdscan/*
Copy link
Contributor

Choose a reason for hiding this comment

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

So far we have tagged backend releases using backend/*.
But I see the consistency in tags being named the same as the tag on the image.


jobs:
release-base-image:
uses: concordium/.github/.github/workflows/docker-release-workflow.yaml@main
Copy link
Contributor

@limemloh limemloh Nov 6, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

I would prefer not to have this sort of abstraction, since it is moving logic somewhere else, and it now adds requirements on how secrets are named.
Sometimes copying and pasting is just easier to maintain, since we now have to update another repo and ensure we don't break stuff elsewhere and the logic in .github become more and more complex as we try to fit it to everything. It already contains logic for cargo which is not relevant for this project, making it harder to maintain.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We do not have to fix the entire organisations release flow using this generalisation.

We have certain release flow, they seem much alike, lets ensure consistency. I do want us to come into a repository and know how we release in this repository. We have not been consistent in the past.

Furthermore such generalisation would ease the use of shared components in the future such as smoke test etc.

Copy link
Contributor Author

@lassemand lassemand Nov 6, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

If you want the content which differ:
prefix or not, version format (semantic or build version extended), version validation (file based validation or not), service name conventions (what should be the name of the service in dockerhub)

And yes fixing secrets namings helps us. The next thing I am going to do is to automate this secrets generation from within terraform. Then it helps that we have fixed docker secrets so I do not have to guess on the name. https://github.com/Concordium/concordium-infra-terraform/blob/main/iam/ghactions.tf

We can extend the repository with the docker repositories that we need access to from within a git repository.

Copy link
Contributor

@limemloh limemloh Nov 6, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

I would much rather have the release flow in this repo rather than code golfing.
Consistency is not generalizing things, and this is introducing a new approach yet again, which makes this inconsistent with what we already have.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Based on the talk we had we came to the conclusion that the already migrated jobs would be reusable workflows and the new ones would be copy pasting.

That means that this should be fine for now.

with:
SERVICE_NAME: "ccdscan"
BUILD_ARGS: |
DOTNET_VERSION=6.0
DOCKER_FILE_PATH: backend/Dockerfile
secrets: inherit
8 changes: 5 additions & 3 deletions backend/Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,20 +1,22 @@
FROM mcr.microsoft.com/dotnet/aspnet:6.0-bookworm-slim AS base
ARG DOTNET_VERSION
FROM mcr.microsoft.com/dotnet/aspnet:${DOTNET_VERSION}-bookworm-slim AS base
WORKDIR /app
EXPOSE 5000

FROM mcr.microsoft.com/dotnet/sdk:6.0-bookworm-slim AS publish
FROM mcr.microsoft.com/dotnet/sdk:${DOTNET_VERSION}-bookworm-slim AS publish
RUN apt-get update && apt-get install -y build-essential
# Installing Rust to build Concordium.Sdk.
RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- --default-toolchain 1.80 --profile minimal -y
ENV PATH="/root/.cargo/bin:${PATH}"
WORKDIR /src
COPY . .
COPY ./backend .
RUN dotnet publish Application -c Release -o /app/publish

FROM base AS final
# Install 'ca-certificates' for supporting HTTPS.
RUN apt-get update && apt-get install ca-certificates && rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY --from=publish /app/publish .
LABEL dotnet_version=${DOTNET_VERSION}
ENV ASPNETCORE_URLS=http://+:5000
ENTRYPOINT ["dotnet", "Application.dll"]
Loading