I have a GitHub workflow that is triggered when files according to the
pattern **/abc** are modified / created.
As far as I understand it, this means that whenever a:
File that is in some subfolder of a folder that starts with abc or
Any file that starts with abc
is modified, the GH action should be triggered.
However, the workflow is even triggered when I e.g. create a file repository/aaa/test_abc
However, to my understanding, the file repository/aaa/test_abc does not correspond to the pattern **/abc**
Do I
Misunderstand GH actions syntax or is it
A Bug in GH actions?
You need to escape the / with a \ for the pattern to work.
Using '**\/abc**' will resolve the problem.
Most of the time, the filter pattern cheat sheet for the Github Documentation helps to configure the paths, but in that specific case it wasn't detailed.
Related
I am trying to set up a GitLab ci pipeline to delete packages, the pipeline will trigger only after the merge request is approved, and the package name is captured from the $CI_COMMIT_MESSAGE and pass it to the delete command to delete the package.
But the $CI_COMMIT_MESSAGE which I have given during push (decomm-xxx) is been added with a few extra lines (Merge branch 'ipl1' into 'Condition'
decomm-zzz
See Merge request lkjdscjnjsdcdsnjkjkj") after the MR is approved and merged.
How exactly can I capture the package name from the $CI_COMMIT_MESSAGE which I originally gave (decomm-xxx), I need to print only the text after "decomm-" but I am not able to print it.
Any help on this would be much appreciated, thank you.
Below is the screenshot's which I tried.
There's maybe a couple ways to do this:
Stop gitlab from adding the extra text
Write a script to accommodate the extra text added when merging an MR
Change the commit message
To stop GitLab from adding the extra text, expand the dropdown under the merge button. This will let you edit the merge commit message:
Write a more reliable script
Alternatively, you can write a script to reliably extract the text you need. Using regex is probably the most reasonable way to do this.
script:
- pattern='decomm-([A-z]+)' # adjust this pattern to suit your needs
- '[[ "$CI_COMMIT_MESSAGE" =~ $pattern ]]'
- CIMessage="${BASH_REMATCH[1]}"
- echo "$CIMessage" # zzz
In one of my repositories nearly all of my code is Python and some HTML.
However, Github thinks otherwise:
What causes that?
You were creating files through a script, with an unintended extension. That is, your script was inserting a dot in the file name.
Simply rename your file my_file_0.5ms to my_file_05ms.txt and it will display the correct languages:
What you could do to fix similar problems in the future is use a script to detect extensions and the total lines of code for each extension.
Solution
GitHub Linguist is the culprit in this situation, but luckily, it can be easily resolved in a number of ways.
Create a .gitattributes file and list patterns that match the files you want to ignore, and then append either linguist-vendored or linguist-documentation.
specific-file.5ms
*.5ms
specific-folder/*
This will remove the files from your GitHub repositories statistics on the next run of Linguist (it may take some time).
Notes
If you'd like to attribute these files to a specific language, you can do that using linguist-language={name}. Full documentation on overriding Linguist can be found here.
You can also run Linguist on your own computer, but note that any changes to .gitattributes will not take effect until you commit to your repository. Linguist will not see changes that exist only in the index.
I'm hoping this is a really simple answer I've overlooked, but I have a repo on GitHub using CODEOWNERS and would like to do the following:
# Default reviewers except for the subsequently listed things:
* #global-owner1 #global-owner2
# Some other owners
/packages/something/ #octocat
/packages/another/ #doctocat
# PRs _only_ affecting the "Some other owners" paths will
# also include a change to the CHANGELOG.md, but I don't want
# #global-owner1 or #global-owner2 to be added on those PRs.
CHANGELOG.md
Is there a way to "ignore" the CHANGELOG.md file in this way?
The file is read backwards, and the first match ends the search. So it seems like you don't need that last line, as the "some other owners paths" will get hit first.
I want to view all the commits for a given "directory" and after a given date, in Github. I have read Github API documentation and "path" and "since" parameters do the job. https://developer.github.com/v3/repos/commits/#list-commits-on-a-repository
However, I am not able to view them on Github. "Since" parameter seems not to work on Github. Example: https://github.com/torvalds/linux/commits?path=Documentation&since=2016-04-04T16:00:49Z
Any idea how can I achieve this?
Thanks,
Leticia
Command line:
Use git log --since option.
git log --since="2015-12-01"
This will tell all commits/actions since December 01 2015. Checkout link
Git commit history
EDIT:
Git hub:
As per my research, there is no trivial solution to view github commits "after" a particular day. You can however use compare option to compare repo/branches between two time periods, this will give you a view of commits "after" particular day.
E.g: The following compares branches between two time periods, thereby listing all commits between this period.
https://github.com/torvalds/linux/compare/master#{2016-04-14}...master#{2016-04-25}
Hope, this helps!
Note: I would recommend command line when possible as it definitely gives you more flexibility.
You could use either this:
git log -- path/ --since="date"
Or this to check a file history
git log -- path/myfile.txt --since="date"
In github you would have to do this:
https://github.com/torvalds/linux/commits/master#{date}/Documentation
for your particular example:
https://github.com/torvalds/linux/commits/master#{2016-04-04T16:00:49Z}/Documentation
I'm in the process of building a Lemonstand site, which I'm managing via git. As such, I'm using the following .gitignore rules:
# Lemonstand
.htaccess
php.ini
boot.php
index.php
install.php
/config/*
/controllers/*
/init/*
/logs/*
/phproad/*
/temp/*
/uploaded/*
/installer_files/*
/modules/backend/*
/modules/blog/*
/modules/cms/*
/modules/core/*
/modules/session/*
/modules/shop/*
/modules/system/*
/modules/users/*
# add content_*.php if you don't want erase client changes to content
/modules/gallery/*
/modules/lddevel/*
/modules/tweak/*
(The top block I got from github, with the second block being some additional rules I added myself to avoid issues with Lemonstands updating system).
My problem is that I'm adding a custom invoice to Lemonstand, which (to cut a long story short) requires the addition of a folder and some files within /modules/shop/invoice_templates/, which I've named cm_standard.
Because this is extra to the default Lemonstand, I want to get this tracked with git, so I'm trying to use the following rule to the bottom of my gitignore file:
!/modules/shop/invoice_templates/cm_standard/*
But when I do a git add -A, it isn't picking up the files within that directory. Even if I do a git add modules/shop/invoice_templates/cm_standard/* it tells me:
The following paths are ignored by one of your .gitignore files:
modules/shop/invoice_templates
Use -f if you really want to add them.
fatal: no files added
Which further suggests I've not written the rule correctly - can anyone help? Thank you.
Ignore patterns with fewer path segments can take precedence over patterns with more path segments, so in your case /modules/shop/* is taking precedence over !/modules/shop/invoice_templates/cm_standard/*, effectively pruning the whole of /modules/shop/invoice_templates/ from the directory traversal even before it looks at the contents of !/modules/shop/invoice_templates/cm_standard. Having said that, ordering can matter too, and when it does, somewhat counter-intuitively later rules within a file take precedence over earlier ones.
This question is very similar to How do gitignore exclusion rules actually work? so I suggest you read that. Also you may find the check-ignore subcommand useful when debugging rules - I added it to git over the last few months and it just appeared in version 1.8.2 which was released a few days ago.