rust/neon

mirror of https://github.com/neondatabase/neon.git synced 2026-01-03 19:42:55 +00:00

Files

Abhijeet Patil 61b6c4cf30 Build dockerfile from neon repo (#6195 )

## Fixing GitHub workflow issue related to build and push images

## Summary of changes
Followup of PR#608[move docker file from build repo to neon to solve
issue some issues

The build started failing because it missed a validation in logic that
determines changes in the docker file
Also, all the dependent jobs were skipped because of the build and push
of the image job.
To address the above issue following changes were made

- we are adding validation to generate image tag even if it's a merge to
repo.
- All the dependent jobs won't skip even if the build and push image job
is skipped.
- We have moved the logic to generate a tag in the sub-workflow. As the
tag name was necessary to be passed to the sub-workflow it made sense to
abstract that away where it was needed and then store it as an output
variable so that downward dependent jobs could access the value.
- This made the dependency logic easy and we don't need complex
expressions to check the condition on which it will run
- An earlier PR was closed that tried solving a similar problem that has
some feedback and context before creating this PR
https://github.com/neondatabase/neon/pull/6175

## Checklist before requesting a review

- [x] Move the tag generation logic from the main workflow to the
sub-workflow of build and push the image
- [x] Add a condition to generate an image tag for a non-PR-related run 
- [x] remove complex if the condition from the job if conditions

---------

Co-authored-by: Alexander Bayandin <alexander@neon.tech>
Co-authored-by: Abhijeet Patil <abhijeet@neon.tech>

2023-12-21 12:46:51 +00:00

3.5 KiB

Raw Blame History

How to contribute

Howdy! Usual good software engineering practices apply. Write tests. Write comments. Follow standard Rust coding practices where possible. Use cargo fmt and cargo clippy to tidy up formatting.

There are soft spots in the code, which could use cleanup, refactoring, additional comments, and so forth. Let's try to raise the bar, and clean things up as we go. Try to leave code in a better shape than it was before.

Pre-commit hook

We have a sample pre-commit hook in pre-commit.py. To set it up, run:

ln -s ../../pre-commit.py .git/hooks/pre-commit

This will run following checks on staged files before each commit:

rustfmt
checks for python files, see obligatory checks.

There is also a separate script ./run_clippy.sh that runs cargo clippy on the whole project and ./scripts/reformat that runs all formatting tools to ensure the project is up to date.

If you want to skip the hook, run git commit with --no-verify option.

Submitting changes

Get at least one +1 on your PR before you push.

For simple patches, it will only take a minute for someone to review it.
Don't force push small changes after making the PR ready for review. Doing so will force readers to re-read your entire PR, which will delay the review process.
Always keep the CI green.

Do not push, if the CI failed on your PR. Even if you think it's not your patch's fault. Help to fix the root cause if something else has broken the CI, before pushing.

Happy Hacking!

How to run a CI pipeline on Pull Requests from external contributors

An instruction for maintainers

TL;DR:

Review the PR
If and only if it looks safe (i.e. it doesn't contain any malicious code which could expose secrets or harm the CI), then:
- Press the "Approve and run" button in GitHub UI
- Add the approved-for-ci-run label to the PR

Repeat all steps after any change to the PR.

When the changes are ready to get merged — merge the original PR (not the internal one)

Longer version:

GitHub Actions triggered by the pull_request event don't share repository secrets with the forks (for security reasons). So, passing the CI pipeline on Pull Requests from external contributors is impossible.

We're using the following approach to make it work:

After the review, assign the approved-for-ci-run label to the PR if changes look safe
A GitHub Action will create an internal branch and a new PR with the same changes (for example, for a PR #1234, it'll be a branch ci-run/pr-1234)
Because the PR is created from the internal branch, it is able to access repository secrets (that's why it's crucial to make sure that the PR doesn't contain any malicious code that could expose our secrets or intentionally harm the CI)
The label gets removed automatically, so to run CI again with new changes, the label should be added again (after the review)

For details see approved-for-ci-run.yml

How do I add the "pinned" tag to an buildtools image?

We use the pinned tag for Dockerfile.buildtools build images in our CI/CD setup, currently adding the pinned tag is a manual operation.

You can call it from GitHub UI: https://github.com/neondatabase/neon/actions/workflows/update_build_tools_image.yml, or using GitHub CLI:

gh workflow -R neondatabase/neon run update_build_tools_image.yml \
            -f from-tag=6254913013 \
            -f to-tag=pinned \

# Default `-f to-tag` is `pinned`, so the parameter can be omitted.

3.5 KiB Raw Blame History