Hey so I see I have a main repo and then a development fork of the repo. I work of the dev and submit pull request for code review to the main, if it gets accepted my boss will merge my pull request with the main repo. We want to set up an even hook similar to "Post-Recieve URLs" that will send a post to my main web app once a pull request is accepted to do a git pull. If I have this right "Post-Recieve URLs" only works for if I commit directly to the repository is that correct? So it wont work if I merge a pull request.
If I have this right "Post-Recieve URLs" only works for if I commit directly to the repository is that correct?
Yes, so not activated in case of merge done directly within the repo.
And this thread mentions that a "hook on merge" (ie on the auto-commit done by a merge) might not work.
A background job in charge of monitoring any new commits (and check if that commit is the result of a merge, by looking at its parent: more than one parent means "merge") is more appropriate.
Related
I am using github actions workflow for code deployment. One of the flow is manual using workflow_dispatch. I am able to select main or any feature branch but when i select tags - most of them are disabled and gives you below error message:
"Workflow does not exist or does not have a workflow_dispatch trigger in this tag.
Learn more about manual workflows"
If I create a new git tag, i am able to deploy. Please help me by sharing the logic and reasoning. Thanks,
If workflow didn't exist when the tag was created, it's not available. The same goes for branches.
The way to fix it is to either cherry-pick workflow there and move a tag or re-base the tag on top of the master branch.
Also keep in mind if you modify workflow on your master branch, but you have a different version in branches - it will use the branch / tag version.
If you want to keep 1 version across all tags - you should pass a tag as an input variable and run it on master branch instead of running workflow on this tag. Then you just have to modify your checkout-action to checkout the passed tag, not leaving it with defaults.
When a collaborator creates/updates a pull request against my repository's default branch I want two things to happen in a specific order:
Automatic code formatting + commit formatting changes to the PR branch
Run code quality tests and unit tests
If tests complete without errors the default branch's branch protection rules should allow merging.
The problem is that when step 1 completes, the current workflows are now invalid since there is a new commit on the PR branch. Because of this, the results of the tests can not validate the PR, rendering the PR impossible to merge.
Step no. 1 does not trigger another round of Actions since it was committed and pushed by an Action itself and that behavior would just create an endless loop of Actions anyways.
What I want is a way to run step no. 1 automatically before anything else happens so that simple warnings get squashed without developers having to do anything manually.
I am trying to avoid doing this through pre-commit hooks since that would require developers to manually set up their environments the same way.
How can I create the flow I am describing by using GitHub Actions?
Since we don't have the actual action script I can only assume what steps it performs, and in what order (see the details under TL;DR).
The true issue is that your action is failing the separation of concerns principle, i.e. it is doing validation (code quality analysis, read-only) as it should, but it is also doing modification (code formatting correction).
Code formatting is, in general, a task more suited for a pre-commit or pre-push hook instead. If badly formatted code does get pushed, code formatting check should fail the build instead of auto-correcting it.
TL;DR
A simplified example... The origin repository is github.com/example/app, the pull request is for the branch new-feature, and the action looks something like this:
steps:
- name: Checkout repository (1)
uses: actions/checkout
- name: Check code formatting (2)
run: run-lint -autofix && git add . && git commit "formatted"
- name: Run tests and check code quality (3)
run: run-tests && run-sonar
- name: Merge it (4)
...
When a contributor pushes changes to the new-feature branch a build will be triggered, and it will be done by e.g. GitHub's build-bot-42.
The build-bot-42 will go through the action's steps in order:
(1) get a copy of the code in question onto itself - build-bot-42 is not the same computer as the one storing GitHub's git repository. The checkout action will basically do the following:
cd ${unique-temp-dir}
git init
git fetch --all
git checkout origin/new-feature
(2) run a lint tool in auto-correct mode, and then apply the changes in a git commit.
(3) run tests and the static code analysis.
If all checks pass we have a local git repository ready to be merged and pushed to origin (in that order).
Of course, if the tests and/code quality don't pass the pull request still has the badly formatted code because the action didn't push the code formatting changes.
I have a few different CI/CD flows, one of them automatically creates GitLab merge requests for specific branches. Each merge request has a generated description and title, with links to resolved issues, etc. After merge request is merged, GitLab creates a merge commit with default schema, and it looks like this:
Merge branch '<my branch>' into '<my other branch>'
<Title of merge request>
See merge request <number of merge request>
I'd like this merge commit to be diffferent, and contain merge request description only, since CD should use it to generate changelogs for each build. I've tried to find an option to change it in GitLab API, but I can't find any parameter or request that would allow me to set merge commit message when it's created, or change it afterwards.
Is there any way to copy merge request description to merge commit body automatically? Maybe some API fields, or templates that can be used?
Based on this issue that’s been open for three years, that functionality isn’t even in the UI so an API operation for it most likely wouldn’t exist until that does. https://gitlab.com/gitlab-org/gitlab/-/issues/2551
Your best option until then is to use git:
Clone the repo
Rebase and reword the commit message
Push it back to the remote
My employer uses an on-prem bitbucket server, and it echoes back a pull request URL after I do a git push. Is there a way to have a global hook which lets me open this URL directly in my browser every time I git push from anywhere, be it a terminal or an IDE?
Not really: there is no post-push client-side hook.
So, as mentioned in here, you could need to make a Git wrapper script in order to:
detect the push
parse its stderr output
extract the URL
call a brwoser with it.
I have a Python Scrapy spider that I want to run at regular intervals on Heroku or similar.
It produces a JSON file that I would like to commit to a Github repo.
Given Heroku or other similar platform, how can I set it up to automatically commit, post-run?
You could write an item pipeline that keeps a static list of items.
Give this pipeline a function called spider_closed and use the dispatcher to attach that function as a signal handler for spider_closed signal.
In spider_closed use json.loads to serialize your data. Save it to a file. And commit it to github.
This repo has good code examples:
https://github.com/dm03514/CraigslistGigs/blob/master/craigslist_gigs/pipelines.py
This seems to be a good library to use for the git part:
https://pypi.python.org/pypi/GitPython/
HTH - if you need anymore help I'd be happy to update this response.