I have a directory /experiments in my repo which contains - surprise! - experiments. Those usually come with their own package.json which includes dependencies that were up to date at the time I made the experiment but might be outdated by now. I have no intent to keep them up to date as the experiments are just proofs of concepts - concepts I might want to use later in the project but I would then implement anew in the main project.
Unfortunately Dependapot sends me a lot of PRs that are about those dependencies in /experiments. Many of them require manual efforts on my end. So I would like to tell Dependabot to not send any notifications or create PRs for everything that is in the /experiments directory (but keep creating PRs for dependencies in the main project).
I didn't really find much docs about how to configure Dependabot on GitHub, but I came up with this:
/.github/dependabot.yml:
version: 2
updates:
# Ignore experiments:
- package-ecosystem: "npm"
directory: "/experiments"
schedule:
interval: "daily"
ignore:
- dependency-name: "*"
It doesn't seem to work though. Today I received another PR from Dependabot that bumped one of the dependencies in /experiments. It was automatically merged, so no effort on my end, but still a bit annoying.
How can I do this right?
This doesn't seem possible as of February 2022: https://github.com/dependabot/dependabot-core/issues/4364
Related
I use a combination of GitHub Actions and GitHub Pages to generate and host a number of "semi-static" sites. That is sites that are updated regularly during the day using scheduled GitHub Actions. Here's one example.
The repos contain the HTML pages which make up the site, but those pages are all generated by GitHub Actions. There's no point in updating those files in a pull request as the changes will be overwritten the next time the site is regenerated.
I mention this in the README for the repos, but I still get PRs from people that change the output files, rather than the templates that are used to build the files.
To make my life that little easier, I'm wondering if there's a way to mark these files so that any PR that changes these files is automatically rejected with a polite comment explaining the problem. Alternatively, is there a way to mark these files so that GitHub knows they shouldn't be included in PRs?
It's an interesting idea so I tried and it worked!
I had to use pull_request_target as the event for forked repositories. More information can be found at https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/.
I've picked opened and reopened for the activity types, however please find more from here if you need it: https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#pull_request
For now, this github action is triggered when the file untouchable_file is included as a change in a pull request, but if you need more complex path filter matching, see here: https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet
name: Test workflow
on:
pull_request_target:
types: [opened, reopened]
paths:
- 'untouchable_file'
jobs:
test:
runs-on: "ubuntu-latest"
steps:
- uses: superbrothers/close-pull-request#v3
with:
comment: "hi. please do not touch 'untouchable_file'."
We've recently switched from greenkeeper to dependabot for our dependencies checks and we noticed that dependabot is opening PRs changing only package-lock.json leaving package.json as it was.
On the other hand, greenkeeper, was committing changes to both files.
What is going on? Is it normal or we missed something in the settings?
This is a very late reply. We had this working in production for a long time now, but I see there's still interest prompting me that maybe people need some help. So, here it is:
When using GitHub dependabot (not dependabot-preview, although the conf file might be the same, actually):
create a dependabot.yml file in your repo's .github directory.
specify a versioning-strategy of increase.
It will look something like this (e.g. npm):
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
# Always increase the version requirement
# to match the new version.
versioning-strategy: increase
That's it. Now, package.json and package-lock.json are both written to with a version increase.
Something similar happened to me, it can be for two things:
In the dependendabot configurations you only have to accept updates for package-lock.json
(This was the one that worked for me) in the package.json in the key Name you may have written with incorrect symbols in my case I had web-app the symbol - caused me not to update it and now I have it as webapp.
The goal of the file package-lock.json is to keep track of the exact version of every package that is installed so that a product is 100% reproducible in the same way even if packages are updated by their maintainers.
reference link is here
So package.json and package-lock.json have different purposes.
There is no error on dependabot trying to push just a modified package-lock.json.
We have over 100 build configurations in Team City, and I've come to realize over the past few months that these assets are just as important (if not more so) than the actual project assets (code, config, etc) we are delivering.
To that end, I know TC provides it's own build configuration version control but to me that seems a bit low on features - for example if a build stops working it would be really good to be able to diff the actual XML build configurations in my favorite diff tool rather than rely on TC's built in one, or to be able to view differences across a longer time frame than simply against the previous state.
Obviously this can be handled manually by extracting the build definition and committing, and then applying self disciple to always do this when you change the definition. Can anyone suggest a more joined up approach? We're using TeamCity Enterprise v8.0.5
Can you upgrade to TeamCity 9? TeamCity now has built in support to sync the build configurations to Git or Mercurial.
https://www.jetbrains.com/teamcity/whatsnew/
https://www.youtube.com/watch?v=zTLeCrdxGIw
As an interim solution before you upgrade to TeamCity 9, you could write a scheduled job to run every 10mins (or even every minute) and automatically commit the changes to a new repository. I'd use a new repository so TeamCity doesn't ever try and trigger off the commits.
I don't know what OS or VCS you are using, but you'd just need to commit all XML files so you get project-config.xml, build type XML, and plugin config, you don't want .properties files as the build number files will change after every build.
<TeamCityData>/config/projects/**/*.xml
If you are using Git you could easily just init a repo in the projects directory, add a .gitignore for anything other than *.xml, and run git add . and git commit -m "Build configuration settings were edited" as a scheduled job.
I want to store a project in Mercurial that contains external code (which can be modified by me) coming from Git and SVN repositories. In SVN I would solve this with vendor branches and copy the code around, but I understood that in Mercurial it's better to have different repositories for different projects, and pull between them when needed.
The project layout will be like this:
- externalLibraryA [comes from a SVN repo]
- ...with some extra files from me
- externalLibraryB [comes from a SVN repo]
- ...with some extra files from me
- externalPluginForExternalLibraryB [comes from a Git repo]
In Subversion I would create vendor dir and a trunk dir, copy all external libraries first in vendor, and then in the right place in trunk. (I think) I can do this in Mercurial too, with subrepositories, but is this the best way to do this?
I tried setting up different repositories for the external libraries, but then it seems I can't pull the externalLibraryARepo into the externalLibraryA directory of my main repository? It goes in the main directory, which is not what I want. I can also create a Mercurial mirror repository and include it as a subrepo in my main repository, but then the changes in this subdirectory go to the mirror repository, while I want them to stay in the main repository.
I'd probably just store this in one repository - note that in the link you give they are using their build system in the end to bring together the binary output from the different repos. I'm not clear on their rationale there.
If the underlying problem you're trying to solve is how to update the externals in a clean way, I'd probably use anonymous branching for that.
I.e. add the external lib to your project, and your modifications. Make sure it works. Tag with ExternalA-v1.0. Hack away on your actual project. Now ExternalA, Inc. has a new version of their stuff. Update your repo to ExternalA-v1.0 tag. Import their new version and apply your modifications on top. Commit. Now you have two heads: one with the latest version of your code (that works with ExternalA-v1.0) and one with the latest version of ExternalA (that does not work with your code, maybe). So then you merge and reconcile the two. Tag again, now with ExternalA-v2.0. Repeat as needed.
You can still keep your externals in separate repositories, but I assume that the project that is using those does not need to be up to date with changes there all the time - looks like the whole point of vendor branches is to have some point of isolation between dependee and dependants. Of course, moving the changes from the externalA project to the project that is using that will then be a manual affair (well, a copy, much like in SVN really).
It depends on whether your vendor code is going to be customized by your team or not. Our teams have had a great deal of success maintaining a named "vendor" branch on repositories with our own customizations on branches named by project name. This vendor code is then easily included in a project as a subrepository.
A caveat to this approach: if active development is going on in the subrepository, best keep it to directly editing the subrepository as a separate clone, otherwise it becomes necessary to pay close attention to the top-level repository so you don't inadvertantly bump your .hgsubstate forward to the wrong revision and break your build.
Watch out for merges of the top-level repository (your project) between versions which point to different named branches of your subrepository, as this can result in a merge between the "vendor" and "project" branches in the subrepository as it recurses, which may not be desirable.
Note that this functionality may change in the future as well, as some "warm" discussions have been taking place in recent months on the mercurial-devel mailing lists about the future of subrepository recursion.
edit:
I just saw this discussion in the related links as well, which seems relevant: https://stackoverflow.com/a/3998791/1186771
I've just started using subversion, and have read the official documentation (svn book), cheat sheet and a couple of guides. I know how to install subversion (in linux), create a repository (svnadmin create), and import my Eclipse project into the repository (SVN import), view the repository files (using svn list).
But I am unable to understand some of the other terminologies. For example, after importing my Eclipse project into the newly created repository I have made changes to my Eclipse project (more than 1 file). Now, how should I update the repository with this added files/changes made to my Eclipse project?
The svn update command brings the changes from the repository into your working copy - which is the opposite of what I want i.e. bring the changes I made in my Eclipse project into the previously imported project in repository. If I am correct, you update the repository more often (as you keep extending your project implementation) than your current project (with update).
Also, I do not understand when would you use svn merge. The svn book states it applies the differences between 2 sources to a working copy. Is there a scenario which would explain this?
Finally, can I have more than 1 project checked into the repository? Or is it better to create a new repository for each project?
The term you are looking for is "commit".
Subversion does not exclusively lock a file for editing (though there is a command to do this if you really, really want to). So it is possible that you will need to merge two different users' sets of edits on a file, or even edits from two different working copies in two different locations on your machine.
Multiple projects is fine. Best approach IMHO is repository/project/trunk etc rather than repository/trunk/project.
Three things about SVN you should know:
Trunk - The main version of your code
Tags - 'Tagged' Versions of your code (i.e. v1.2.5-release)
Branches - Forks of the code for divergent development paths. We typically fork new branches to work on different versions, so if the current version is 1.2.4, you'd branch for 1.3's development. So if emergency changes to 1.2 need to be made (i.e. 1.2.5) you can work on it without worrying about what you broke by refactoring / feature adding in your 1.3 branch. The merge operation is designed so you can merge 1.3's branch back into trunk when you're ready to release 1.3, or a similar operation. You can also merge individual files (if two or more developers edited the same file at the same time and now you need to 'merge' the changes into the same file.
Each project in your repository should have 3 folders in it:
/trunk
/branches
/tags
These house the three points above. You don't have to have these folders, but you should. Other more mature VCS like Mericual/Git have the concepts of tags and branches baked into the system. In SVN these are more of a convention/reccomendation.
Terminology
Working Copy - The copy on your hard-drive, that contains all your edits, etc...
Add - Registers a file for tracking in version control
Update - Updates the working copy with changes from the server repository
Commit - Updates the server repository with changes from the working copy
Switch - Replaces the working copy with another folder within the server repository
Diff - Does a differential analysis of two files / versions of a file to see the changes between them.
Merge - Attempts to apply the changes from one or more files into another, highlighting conflicts.
Patch - A set of differences that can be used to update a file.
You commit changes to the repository
Merge is useful when you need to maintain two branches of a repository. For examples v1.x with most recent security fixes and the alpha version 2. That allows you to make the fixes in the 1.x code, whith the resulting binary for existing customers, and you can merge the changes into version 2 so fixing the bugs that weren't already caught.
I suggest you look around for 'typical svn workflows'. They will give you the big picture of the 'most common tasks'.
What you want to do is 'commit' the changes made to your files to the repository.
You need to merge in case of a conflict (when 2 or more people are working on a project and commit to the same repo. conflicts might arise).
Check the available articles on SVN kai remember to read about the sample/typical workflows or working scenarios with SVN.
Fully agree with David, but as far as question 3 is concerned, personally, I would distinguish between use cases:
Production: One project per repository. And do get warm with the mentioned tag/trunk/branch concept, it really helps a lot
Testing: I have one single repository where I have put virtually all my experimental codes (approx. 10 languages with x codes per language). Reason is: One experimental code takes me 1-2 minutes, creating a repository on a remote host, using ssh-security sometimes takes longer ;-)
Cheers
EL