How to download a zipfile from a Github repository

I’m trying to download a zipfile from a Github repository with this command:

wget --no-check-certificate https://github.com/brendenlake/omniglot/blob/master/python/images_evaluation.zip -O /tmp/images_evaluation.zip

But it doesn’t download a valid zip file. I suppose that it downloads the HTML file that the browser shows if you click on the url.

How can I download a zip file from a public Github repository using wget?

Go to Source
Author: VansFannel

GitHub Actions: build outside vs inside container?

Let’s say we’re using GitHub Actions to build and publish a container image of our app. I’m gonna pick ASP.NET Core as the app’s tech stack here, although that shouldn’t matter much.

There are two different approaches I’d like to discuss:

1. “Build outside”: build/compile app in GitHub Actions runner, copy output into container image

For example, our GitHub Actions workflow file could look like this…

name: build-outside
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout repo
      uses: actions/checkout@v2
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v1
    - name: .NET Publish
      run: dotnet publish --configuration Release --nologo -p:CI=true -o $GITHUB_WORKSPACE/buildOutput src
    - name: Build and push Docker image
      uses: docker/build-push-action@v1
      with:
        username: ${{ secrets.DOCKERHUB_USERNAME }}
        password: ${{ secrets.DOCKERHUB_ACCESS_TOKEN }}
        repository: ${{ format('{0}/build-outside-test', secrets.DOCKERHUB_USERNAME) }}
        tags: latest

… and there’s a simple Dockerfile like this:

FROM mcr.microsoft.com/dotnet/core/aspnet:latest
WORKDIR /app
COPY buildOutput /app
ENTRYPOINT ["dotnet", "MyTestApp.dll"]

2. “Build inside”: build in one container, copy output to another container image

In this case, the workflow file is shorter…

name: build-inside
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout repo
      uses: actions/checkout@v2
    - name: Build and push Docker image
      uses: docker/build-push-action@v1
      with:
        dockerfile: Dockerfile_build_inside
        username: ${{ secrets.DOCKERHUB_USERNAME }}
        password: ${{ secrets.DOCKERHUB_ACCESS_TOKEN }}
        repository: ${{ format('{0}/build-inside-test', secrets.DOCKERHUB_USERNAME) }}
        tags: latest

… whereas the Dockerfile is longer, as this is now where we’re building the app itself and the final container image:

FROM mcr.microsoft.com/dotnet/core/sdk:latest AS build
WORKDIR /src
COPY src /src
RUN dotnet publish --configuration Release --nologo -p:CI=true -o ./buildOutput

FROM mcr.microsoft.com/dotnet/core/aspnet:latest AS runtime
WORKDIR /app
COPY --from=build /src/buildOutput ./
ENTRYPOINT ["dotnet", "MyTestApp.dll"]

Aside: in case you’re not familiar with multi-stage
builds
,
note the two FROM statements in that second Dockerfile. We’re
building in a first, temporary container, and then copying only the
build output into the final (runtime-optimized) container image.

Note that this second approach is explicitly recommended in the official ASP.NET Core documentation.

Trade-offs

I’ve confirmed that both approaches work and produce a working container image. Notably, build checks on pull requests “just work”™ with both approaches:

enter image description here

Now stepping away from this concrete example, here’s my current thinking on the advantages of each approach in general:

  1. Build outside:
  • Build can leverage Marketplace Actions
  • If build is complex and consists of several steps, it might be beneficial to set it up using GitHub Actions primitives – i.e. a series of jobs/tasks. That way, we can leave it to GH to optimize the build, allocate additional resources as needed, run jobs in parallel etc.
  • A little easier to inspect build failures (UI will show exactly which step failed)
  • No need to download 2nd container image during build, hence maybe saving a little bit of network bandwidth
  1. Build inside:
  • Exact, deterministic build output
  • Full control over build environment; independent of build runner
  • Container build can also run on local dev machines, producing same exact output

Questions

  1. Am I accurately describing the advantages of the two approaches?

  2. Are there any other aspects of building inside vs outside a container, specifically in GitHub Actions, which are worth mentioning?

Go to Source
Author: Max

GitHub Actions Runner execute commands with sudo GitHub Actions

I have a GitHub action set on self hosted Ubuntu VPS on Linode.
I ran sudo ./svc.sh install and then ./svc.sh start. The runner is up and working but I have a command in my yaml file that needs to run as sudo. I have this command in sudoers file to run without sudo
%sudo ALL= NOPASSWD: /bin/systemctl restart twentydb.service
But still when I push on the server the following error occurs.
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper

name: restart the service
run: |
sudo systemctl restart twentydb

I also need to set up 2 more runners on the same server and same setup.

Go to Source
Author: Takasur

GitHub: Is it possible to view a list of all the projects a member has contributed to?

In the GitHub web-app user interface, is it possible to view a list of all the projects to which you have contributed?

What about a list of all the projects to which another user has contributed?

Go to Source
Author: RockPaperLizard

How to protect secrets whilst enabling the ability to amend a pipeline

I’m writing a CI pipeline using GitHub Actions.

The pipeline will build a Docker image, which it will then push to our Docker repository (AWS ECR).

In order to talk to ECR, we’ll need to provide a secret (and some other details).

That secret we’ll be pulling from Hashicorp Vault… though that itself requires a secret in order to access it, so to some extent we’re just offsetting the problem.

The pipeline’s code is in the same repository as the code for which it is run (to which our developers have access); though we can hold some actions called by this code in a separate repository (to which only our DevOps team have access) if needed.

Whilst we trust our developers, it’s generally good practice to keep things locked down where possible. As such, is there any way we can set things up such that developers can amend the pipeline without being able to (deliberately or otherwise) expose these secrets? Are there any best practices around this sort of thing?

Go to Source
Author: JohnLBevan